イーサネットのVPNだけじゃない？ EVPN活用の可能性①

ビジネス推進本部 応用技術部
コアネットワークチーム
平河内 竜樹

EVPNのユースケースは実現可能な構成という観点で見渡すと「EVPNでないと難しい」ものから「EVPNでも出来る」ものまで多岐にわたります。本コラムではEVPNにおいて露出が少ないと思われる用途に焦点を当て、その利点を紹介します。

Aggregation LayerにおけるEVPNの活用

まずレイヤ2の冗長化を実現する既存技術として、ICCP (Inter-Chassis Communication Protocol)について触れたいと思います（□ □）。VPWS/VPLSにPE Redundancyを提供することを目的として登場したICCPは、LDPセッションを経由して冗長グループを形成し、Attachment Circuit（以下、AC）やPseudowire（以下、PW）に対しActive/Standby関係を構築することによってループフリーなPE冗長トポロジの実現を可能にします（図1）。一方ICCPの実装としては必ずしもVPNと連携させることを前提としておらず、AC間をブリッジする様なトポロジに適用することも可能になっていました（図2）。

EVPNは標準でPEの冗長化機構を備えているため、図2の様なICCPのケースと同様にVPNを必要としない環境においても、AC間を接続する機器に対し冗長性を提供する手段として利用できることが想定されます（図3）。冗長PEの発見やその間のMACアドレス同期などはBGPを経由して行われ、BGPトラフィックの伝送路となるIP/MPLSコアがInter-Chassis Linkの役割を果たす格好です。この構成に関してはEVPNのユースケースとしてメーカーより明確な情報発信が行われている例もあります（□）。

なお、広域にわたるレイヤ2接続をサービスとして提供する際にはコアをIP/MPLSとしてVPNを展開するか、イーサネットベースで組む際にはリングプロトコル等の冗長化機構を利用すれば図2の様な構成にはなりません。また、インフラとして局所的なレイヤ2の冗長化を必要とする際にはスタックに代表される様な先行技術がよく利用されています。Active/Active構成を実現可能なICCPの実装も存在するものの、冗長化構成における実現の選択肢やICCPを適用できる場面が製品によって異なるという背景もあり、図2のトポロジを主眼にICCPが利用される機会は相対的には少なかった様に思います。

一方、図3の様なEVPNを利用して同一機器上の異なるEthernet Segment/Ethernet Tag間をブリッジさせる構成では、集約機器における3台以上の並列配置が仕様として明確に実現可能であることに加え、オープンな仕様で実現できる・専用のケーブルを必要としない等の特徴を併せ持ちます。また集約機器間のトポロジに制約は無く、各機器で独立したコントロールプレーンの間をフルメッシュのピアリングが省略された状態で接続することが可能です。

こういった特徴を踏まえると、サーバや加入者を束ねるネットワークインフラなど、広帯域のレイヤ2ネットワークが必要とされ、とりわけ構成要素は標準に準拠したものが望ましい環境には適合する技術となり得ます。

例えば、データセンターネットワークにおいて技術要件となるレイヤ2マルチパスは、スパイン機器に対してAll-Active redundancy modeのEVPNを適用し、Multi-homed Deviceとして各リーフ機器をLAGで収容する形でも実現することが可能です。なおEVPNをリーフ機器まで含めて適用した方がOAMの面では優位ですし、ARP/ND Proxyなどの機能をよりホストに近い位置で提供することができます。このように有用性はケースによって異なりますが、EVPNをスパイン機器のみに適用した構成では、リーフ機器に対する接続上の機能要求をLAGに限定することができます。この場合、トランスポートネットワークの設計・設定に起因した複雑さを排除できる他、結果として相互接続性や導入コストの面でもメリットを享受できるかもしれません。

またレイヤ3のゲートウェイとして外部と接続する機能をスパイン機器に設ける構成においても、レイヤ2の接続性を提供していた場合と同様に、スパイン機器を3台以上横に並べたトポロジでリーフ機器を収容することが可能です（図4）。この場合VRRPやHSRPといったゲートウェイ側での冗長用プロトコルは不要となり、これらをボトルネックの要素として排除できます。加えて障害発生時の切り替わりは、LAGの縮退で完結するため、高速に行われることが期待されます。

補足として、同じ階層で異なるEthernet Segment間を接続する場合、必ずしも同一機器上でブリッジされる必要はありません。例えば図4のトポロジにおいてVLAN 2のサブネット内通信に着目すると、Leaf-2とLeaf-3の間で通信が行われる場合・Leaf-1からLeaf-2への通信で送出先にSpine-3が選択された場合・もしくはSpine-3とLeaf-1を結ぶリンクが喪失した際にLeaf-3からLeaf-1への通信が発生した場合には、最初に到達するスパイン機器から宛先ホストを収容するリーフ機器へ直接到達できない状態となります。この状態では、宛先に関する情報がBGP経由で認識されており、スパイン機器間を接続するIP/MPLSのリンクを経由して転送されます。

このように異なる機器に収容されたEthernet Segment間の通信が混在するケースやEthernet Segmentの障害によって同一の機器から到達できなくなった際には、部分的/一時的にVPNを経由して転送することが可能です。逆に宛先となるホストが同一の機器に収容されていれば、VPNを経由して到達可能であったとしても、MACテーブルの構築においてローカル方向のエントリが優先されることにより、常に同一機器上でブリッジされます。

またBUMトラフィックの配送では、ある宛先のEthernet Segmentに対してパスが複数存在することにより伝送中は通信が複製される状態となるものの、DF filteringによって同一の通信が重複して到達することはありません。DF Filteringは、ローカルでブリッジされるパスも考慮されるため、宛先となるEthernet Segmentが送信元と同一の機器・送信元とは異なる機器の双方に存在する環境においても機能します（□）。例えば図4で、Leaf-3のVLAN2から送出されたBUMトラフィックに着目すると、Spine-3に到達した通信は同じセグメントを収容するSpine-1とSpine-2にVPN経由で転送され、ES-2宛の通信はES-2/VLAN2のDFとなる機器から送出されます。この時Spine-3がES-1/VLAN2のDFに選出されていればローカルに接続されたES-1に対しても転送を行い、関連してDFとならないSpine-1・Spine-2ではES-1に向けての転送は行われません。Spine-3がDFに選出されていない場合はローカルからの直接転送は行われず、Spine-1・Spine-2どちらか一方のDFとなる機器からES-1へBUMトラフィックが送出されます。

併せて、あるEthernet Segmentから送出されたBUMトラフィックのうち、送信元のEthernet Segmentへ戻ってくる通信はsplit-horizon filteringによってブロックされます。VPNの受信側で行われるsplit-horizon filteringは、送信元の入力側と共通のEthernet Segmentを宛先とする場合が対象となります。受信側で複数のEthernet Segmentが収容される環境において、送信元と異なるEthernet Segmentへの転送を妨げるものではありません（□）。同じく図4の例で、Leaf-1のVLAN2から送出されたBUMトラフィックで送出先にSpine-3が選択されたものに着目すると、ES-2への転送は常にVPNを経由して行われ、対向のSpine-1・Spine-2はどちらも送信元のEthernetSegmentであるES-1を収容しています。この時、実行されるsplit-horizonfilteringはES-1を宛先とする方向が対象となり、ES-2に対してはその処理が行われません。結果、ES-1宛への転送は行われず、Spine-1・Spine-2どちらか一方のDFとなる機器からES-2へBUMトラフィックが送出されます。

このように伝送路がVPNを経由するものとそうでないものが混在する環境においても、DF filteringと split-horizon filteringの適切な動作によって、BUMトラフィックは宛先セグメントを収容する各Ethernet Segmentに対して1回ずつ配送される結果となります。

なお、外部ネットワークとの接続点になるEVPN機器は、各IP-VRF単位で外部のレイヤ3機器と直接経路を交換できます。加えて、外部との境界にはならない機器に関しても、EVPN Route Type 5を経由して必要な経路を交換することが可能です。この場合、VPNを経由して接続点となる箇所まで転送されることによって、外部ネットワークとの通信が可能になります。図4の例ではLeaf-3からCoreに対して通信を行う場合は最寄りとなるSpine-3上のIP-VRFから直接外部へと転送され、Leaf-3からServiceに対して通信を行う場合は他のスパイン機器へVPN経由で転送された後に、外部へ送出されます。

EVPNによってマルチホームを構成した場合、リンクおよびノードに対する冗長化・負荷分散はVPNを経由せずローカルで折り返される通信に対しても有効であり、同時に配置上の階層を問わずリモートの機器を経由する宛先に対してはVPN経由で到達性が確保されます。言い換えると、収容するアクセス機器やホストに対してLAGで接続することができれば、宛先ホストの配置場所やサブネットの内外を問わずにネットワークの冗長性を提供することが可能になります。こういった観点から、EVPNは汎用的なレイヤ2/レイヤ3クラスタリングを提供可能なプロトコルと捉えることもできます。

利用上の留意点として、機器の冗長化をEVPNで実現する際には、Ethernet Segmentをいくつ収容できるか・冗長グループの中に機器を何台所属させることができるかといった要素は実装された製品の対応状況によって異なる可能性があります。場合によっては3台以上の並列構成に関してはサポートの範疇外といったことも考えられるため、対応状況が明確でない際には注意が必要です。

なおEVPNのマルチホーム構成で選出されるDFは、冗長グループ内全体でEthernet Segment/Ethernet Tag毎に一意になることを期待して、各PE/NVEが個別に算出します。デフォルトであるmoduloベースの算出においても計算方法や利用情報が1通りでない状況を鑑みると（□ □）、EVPN Route Type 4のインポートに問題は無く冗長グループ内のPE/NVEリストが正常に共有されたとしても、最終的に選出されたDFに重複や欠損が発生するという状況は可能性として起こり得ます。仮にこのような状態に陥った場合、BUMトラフィックが重複して配送される・宛先に到達しないといった形で、基本的な疎通性の確保に影響が出ることになります。現実的にはロケーション単位で利用するOSを揃えるなどの配置を行っていればまず表面化しない現象ですが、冗長グループ内で相互接続が発生する様な構成を取る場合には、この点も留意すべき事項となります。

今回のまとめ

EVPNの機能を活用することによって『レイヤ2のLocal Bridgingを行う機器の冗長化』『レイヤ3のゲートウェイとなる機器の冗長化』といったオーバーレイを伴わない要件にも対応することが可能になります。

EVPNを利用して集約機器の冗長化を実現した場合、以下の要素を包括して提供できることが利点として挙げられます。

• 利用するプロトコルおよびハードウェアに対するベンダー固有性の排除
• アクセス機器と集約機器との間および集約機器同士の接続に対するトポロジの自由度
• レイヤ3を統合可能なスケールアウト構成

執筆者プロフィール

平河内 竜樹

ネットワンシステムズ株式会社 ビジネス推進本部
応用技術部 コアネットワークチーム
所属

ルータ分野を核とした新旧技術の調査・検証と共に、エンタープライズ・パブリック・サービスプロバイダのネットワーク提案および導入を支援する業務に、10年以上にわたり従事

• CCIE RS
• CCIE SP

ナレッジセンターを検索する