L2VPNへEVPNの適用した際の課題 (既存網の課題編)
twitterで面白い記事を見つけました。
昔お仕事でEVPNの技術調査に関わっていたことがあり、非常に懐かしい気持ちになりました。
当時検討した際は、EVPNの適用に関しては「課題あり」という感じだったので、忘れないうちにまとめておこうと思います。
この記事の中では、現在のVPNサービスが抱えている課題感を(いえる範囲で)明らかにし、次回の記事にて、この課題に対してEVPNがどの程度有用なのかをまとめます。
なお、細かな用語説明などは上リンクをご参照いただきたく。
灰色文字は私の心の声です。
既存のL2VPNサービスの課題
既存のL2VPNサービスは、主に以下2つの技術のどちらかで構成されています。
- IEEE802.1ad/ah(事業者指定VLANによるフラットなL2ネットワーク)
- VPLS(ラベルスイッチング)
それぞれ、もしくはどちらかが抱える課題感として、概ね以下のようなものがあります。(もちろん以下の内容以外にも、サービスごとに異なる課題感はあると思います。)
１．不要なBUMトラフィックの抑制
IEEE802.1adでは、受信したイーサネットフレームの宛先MACをもとに転送先を判断しています。フレームを受信したVPN網内の各SWは、FDBエントリに当該宛先MACを記録し、次回以降の転送に用います。
VPNユーザの使用方法によっては通信が長期間途切れることもあり、FDBエントリがフラッシュされることも多々あります。転送において、フレームの宛先MACがFDBエントリに存在しない場合は、そのフレームが属するVLANにフラッディングします。
フラッディングによって網内で不要な帯域消費が発生するため、可能な限り、不必要なBUMトラフィックは抑止する必要があります。
VPLSも同等の課題を持ちます。転送においてはPEルータで宛先MACとラベルの対応付けをおこなう必要がありますが、あて先が不明の場合、当該フレームが属するすべてのPEにフレームを送信します。
また、VPLSの場合は、VPN網内でLSPの通信を枝分かれさせることが難しく、基本的にはPEルータで宛先数分のコピーを行う(Ingress Replication)ため、IEEE802.1adと比較して、網内の帯域消費が大きくなります。
解決策としては、
が考えられます。
２．装置リソースの最適化
通信装置が学習/設定できるパラメータは有限であり、運用においては帯域だけではなく、装置リソースの上限を管理する必要があります。例えば、以下のようなものでしょうか。
- 設定可能なVLAN数、ラベル数
- ポリサ、シェーパ数
- FDB学習数
IEEE802.1adを採択している場合はVLAN数が辛く、VLAN-IDのフィールドが12bitしかないため、ユーザの収容状況に応じて、増設などの検討が必要になります。もちろん、ポリサ、シェーパ数、FDB学習数も収容ユーザ数に引っ張られるため、そちらが枯渇すると対応が必要です。
VPLSにおいては、PルータがMACアドレスを学習する必要がなく、PEルータ全台数の宛先を知っていれば事足りるので、宛先学習数がPEルータ数に収束します。また、ユーザ識別用のラベルを転送において用いないため、装置リソースが収容ユーザ数に依存しません。(このあたり、かなり曖昧ですね。。。)
PEルータはユーザごとに転送先を定める必要があるため、IEEE802.1adと同等の課題を持ちます。
収容ユーザが増えるとどうしてもリソース枯渇は避けられないため、基本的には、枯渇時の対応が容易なNWにしておくことが良いです。リソースが大きな装置に交換する、というのが解の一つではあるのでしょうが、高価ですし、交換のためのオペレーションコストも馬鹿にならないため、積極的に採用したくはありませんよね。
解決策としては、
- スケールアウト可能なNW
- 設定リソースの集中(リソースがネックになる装置を絞る。VPLSはPEルータに絞ることができていますね)による、増設対象装置の抑止
が考えられます。
設定リソースの集中は、網内でユーザ単位の制御ができなくなる、というトレードオフが発生します。この辺は非常に難しく、サービスとしてどうあるべきか、というところから考える必要があります。
３．高速かつ最適なコンバージェンス
VPNサービスは稼働率に関するSLAが定められており、事業者はこのSLAを守ることが可能なNWにする必要があります。
装置故障、回線故障などが発生した際に、SLAに応じた切り替え時間で通信を復旧させるため、一般的には冗長切り替えプロトコルを用います。
IEEE802.1adの場合は、ITU-T G.8032で定義されたERP(Ethernet Ring Protocol)がありますし、VPLSではFRR(Fast Reroute)と呼ばれる技術がありますので、適用によって高速なコンバージェンスを実現することは可能です。
ただ、FRRは各リンク/ノードごとに故障切り替え区間を明示的に設定する必要があるため、設定がかなり面倒です。また、各Pルータが持つプロテクションパスは、トポロジが変更されるたびに再設定となるため、NW増減設の負担となります。 FRRはまじめに検討すると本当に難しく・・・。実運用している人はどうしてるんでしょうか。
PEルータ(もしくは、IEEE802.1adにおける、事業者VLAN-IDを挿入するL2SW)のような、異なる転送方式とのNWの繋ぎ目の部分が故障した際は、上記プロトコルは使えませんので、ベンダ独自仕様などを用いて何とかする必要があります。
また、VPLSのような、PEで転送先を決定するような仕様であれば、転送先PEルータとCE間の故障状況を判断しないと、故障リンクに転送を継続してしまうという悲惨な状況に陥ります。そもそもVPLSってPEルータの装置冗長できるんでしたっけ？？
解決策としては、
- 簡易な冗長パスの設定(自動で最適な迂回パスを勝手に構築しといてくれれば・・・)
- PEルータ冗長の実現(冗長収容が可能、かつ、高速にコンバージェンス可能)
が考えられます。
４．自由な物理トポロジと、トラフィックエンジニアリング
設備設計をする際は、その土地の需要や見込みユーザ数などを予測して設備配備をおこないますが、必ずしも収容状況が検討通りにいくわけではなく、想定外にガラガラなリンクや、帯域ひっ迫が継続するリンクがどうしても発生してしまいます。
可能な限り収容効率を高めるために、ユーザに影響なく通信の経路を変更することができれば、(例えば、帯域に余裕があるリンクに収容替えすることができれば)、網内の帯域使用率が高まり、増設契機を抑止することができます。
当然、網内遅延や冗長経路などは考慮する必要があります。
IEEE802.1adを用いる場合は、通信経路をすべてFDB学習によって決めているため、運用者側での通信経路の変更は極めて難しいです。(VLANの張り直しになるので、通信がしっかり切れます)また、冗長構成はERPに依存するため、増設はリング単位に限定されます。不用意に装置間を接続するとループが発生するため、物理網の構成はしっかりと定めておく必要があります。
VPLSは網内トポロジがフリーであり、柔軟なトラフィックエンジニアリングが実現可能です。これがVPLSを採択する大きなメリットの一つかと考えます。
解決策としては、
- 自由な物理トポロジ構築が可能なNW(ループフリー)
- トラフィックエンジニアリングの実用化
が考えられます。
次回は、この課題に対して、EVPNがどれだけ対応できているのかを書こうとと思います。
書いててわかりましたが、相当忘れてますね・・・。書いてる内容も少し自信がない感じです。マサカリは大歓迎ですので・・・
ありがとうございました。
