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

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

今回取り上げるEVPNの用途はマルチテナントに対応したレイヤ3のVPNに関するものです。RFC2544 / 4364という十分に成熟し今も利用されている実現方式が存在する用途において、どのような内容がメリットになり得るかという視点で紹介していきたいと思います。

連載インデックス

 

L3VPNにおけるEVPNの活用:MPLSを排したIPトランスポートの実現

レイヤ3用途のEVPNとRFC2544/4364形式のIP VPN(以下、RFC2544)を比較した際の最も解りやすい相違点が、主にEVPN-VXLANを利用した、IPトランスポートの選択です(図1)。


図1:LSPを完全に排したIPトランスポート上でIP-VPNを実現

 
提案された仕様という観点ではEVPN Overlayの登場前からIPネットワーク上でRFC2544の実現を目指したものはいくつもありましたが、実際に利用される機会はあまりなかった様に思います。理由としては、ルータ製品に実装される場合は機能上の制約や成熟度の観点でMPLS実装の後追いとなりがちであったことや、TE/FRRの併用が背景にあったことなどが挙げられます。また、部分的にIP ネットワークを通過したいだけであればIP トンネルの上にLSPを通す形でも実現することが可能です。

またIPトンネリングが多用されるエンタープライズのWANにおいては、例えば部門やグループに合わせてテナント分離が必要になった際にも、それに沿う位のVRF数であればVRF単位で個別にルーティングを行うことでも十分に対処することが可能です。要求される可用性やスケーラビリティの観点からも、多くのケースでは集約されたルーティングを実現することよりはMPLSやBGPを導入しないことの方が利点に映っていた分野と言えます。

取り巻く状況の変化から大きく影響を受けた分野はデータセンターのネットワークおよびスイッチ製品です。サービス / 利用形態の変化から一つのサイト内に多数のテナントを収容する環境が生まれ、またスイッチチップの進化によって安価な製品でもVPNの構築に対応することが可能となりました。チップの対応状況だけで言えばMPLSへの対応も整備されている状態となりますが、概してデータセンタースイッチの機能実装はVXLANの方が先行しており、これをレイヤ 3 VPNの用途に転用するのであればIPトランスポートを選択することは自然な流れと言えます。
 

L3VPNにおけるEVPNの活用:エッジ機器の冗長化

ネットワークのFirst HopがVPNの外部に存在するケースにおいては、PE-CE間はレイヤ3で接続され、ユーザのIP RouteがPEの転送テーブルに追加されます。IP-VPNでマルチホーム構成を取る場合、冗長PEはそれぞれ個別にCEとBGP等で接続を行い、経路選択を通じて複数のPE間でActive/Standby関係を構築する(もしくは負荷分散構成を取る)という形で実現されます(図2)。


図2:経路選択による経由PEの決定

 
言い換えるとCEはBGPピアとして複数のPEを認識するため、回線の冗長化を伴わないエッジ機器冗長の用途ではその点がハードルとなる形態です。EVPNではこの点に対応可能な技術として、レイヤ2のアクセスネットワークを介し、CEから冗長PE群に対し単一アドレス宛のBGP接続を実現するための仕様が提言されていました()。この構成では冗長グループ内の各PEはユーザ向けのBGP終端に利用可能な同一のIPアドレスを共有します。平常時は選出されたDesignated Forwarder(以下、DF)がユーザ向けのBGP処理を担い、障害時はDFの再選出を通じて無事なPEにその役割が引き継がれます。この中でEVPNは冗長グループ内におけるActive PEの選出やエントリ同期などの役割を果たします。

レイヤ3の接続となるエッジ機器の冗長化は、CE収容のルールとして、回線冗長や複数のPEとのピアリングを前提とする形で実現することも可能です。前述のEVPNを利用する方式も、状態維持のためにはCE側にGraceful Restartの対応が要求されます。この実装が登場したとしても、図1の様な構成を組む場合、少なくともしばらくの間は「筐体間冗長には頼らない」「プロトコル同期に対応した独自の筐体冗長技術を利用する」「ポリシーとして冗長化構成の実現はCE込みの制御を前提とする」といった形式が優先的な選択肢になると考えられます。一方でGraceful Restartは広く実装されている上に標準化も完了している技術であり、EVPNのアシストによって、シャーシを跨いだルーティングプロトコルの協調動作に関しても公開された仕様の範囲内で実現可能になるケースとして挙げさせて頂きました。

次いで、レイヤ3 VPNのエッジがFirst Hopを兼ねる際には、EVPN標準の冗長化機構が効果的に働きます。これまでのIP-VPN構成要素では、この部分の冗長化にはVRRP / HSRPなどを併用するか独自のシャーシ冗長技術を利用する必要があり、採用のハードル・スケーラビリティ・障害時のサービス停止時間など、各要素に相応の影響を及ぼしていました。EVPNの場合LAGやSTPなどレイヤ2の範囲でエッジ機器の冗長化が実現され、レイヤ3での対応は必要となりません。特にLAGで接続する構成はVRRP / HSRPの利用を省略しながら高い可用性を提供できることが期待されます。適用に向いた環境としては、クラウドサービスの基盤などでCE相当部のネットワーク構成を直接管理する場合などが挙げられます。また、レイヤ2スイッチ経由で一本足のCEやホストに対して冗長化されたレイヤ3のゲートウェイを提供することも可能です。この活用パターンは第1回で挙げた内容と共通しており、詳細はそちらをご覧いただければと思います。
 

L3VPNにおけるEVPNの活用:IP Prefixに対するMass Withdrawの実現

図3はIP-VPNにおける冗長化構成の一例を表したものです。マルチホーム環境において、高可用性を実現するためにいくつかの技術を利用しています。以降ではシングルホームサイトからマルチホームサイトへの片方向通信に着目して、各種の障害イベントに対して用いられている技術を掘り下げていきます。


図3:IP-VPNにおける冗長化構成例

 
図3の障害点[1]はPE間を接続するトランスポートネットワークに対する障害を示しており、切り替えの前後でBGP経路のNext Hopは維持されます。このケースでは主にMPLS FRRが対策となり、サービスを問わず高速迂回のための手法が確立している箇所とも言えます。

障害点[2]はアクティブなPEのノード全体に障害が発生したケースを想定しており、無事な方のエッジ機器への切り替えに伴い、障害発生箇所から見たリモートのエッジ機器(図3ではEdge-20)においてBGP経路に対するNext Hopの更新が発生します。多くのユーザを収容している等の理由でBGP経路が多数存在する場合は転送テーブル全体の更新に時間を要する可能性があり、この点に対してはBGP PIC Edgeが対策となります。この技術ではバックアップとなる経路情報が階層化された形で転送テーブルへ格納されます。各BGP経路ではパス(ここではBGP Next Hop)そのものではなくパスリスト()が参照され、障害時はパスリストから無効になったパスを削除するだけで更新作業が完了します。転送テーブルの更新に対し規模の依存性が排除されるため、無効となったBGP Next Hopの検出が高速に行われれば、MPLS FRRではカバーできないエッジ機器のノード障害においても速やかな迂回が可能となります。

障害点[3]はPE-CE間の接続性が失われたケースが該当し、BGP Next Hopの変更が発生するイベントです。前述のBGP PIC Edgeは、パスの識別をネクストホップの単位で行う技術であり、Egress PEのPE-CE間リンクで発生した障害イベントをIngress PEのパスリスト更新に対する直接のトリガとすることはできません。サービス停止時間を短縮するための対処の方向性としては、障害を検出したegress PE(図3ではEdge-10)にバックアップパスを持たせ、そこからPE-CE間接続が無事なegress PE(図3ではEdge-15)へ改めて迂回させることになります。このケースではegress PEにおけるBGP PIC Edgeの対応に加えてバックアップパスの保持に関しても注意が必要です。冗長PE間でActive / Standby関係を持たせるために、片側のプライマリPEでCEから受信したユーザ経路の優先度を上げた場合、リモートのPEだけでなく、同サイトにあるもう一方のセカンダリPEにおいてもベストパスはプライマリPEとなります。BGPでは原則ベストパスのみが広報されるため、結果としてプライマリPE(図3ではEdge-10)はセカンダリPE(図3ではEdge-15)に対するバックアップパスが保持できなくなります。対策の一つであるBest Externalを併用するなどして、全てのPEでバックアップパスを保持できればノード障害とPE-CE間リンク障害の双方に対応することができます。

上記の補足として、PE-CE間リンクの障害時、バックアップパスによる迂回と並行してEgress PEからIngress PEへのWithdrawおよびingress PEでのBGPネクストホップの更新は経路個別に行われます。BGP Next Hopが更新されれば、PE-CE間リンク障害の発生したPEを経由せずに迂回先のegress PEへ直行する様になります。一連の処理が完了する迄の間は余分なホップが発生するため、この構成では冗長PE間の接続性が重要になり、迂回用に冗長PE間で直結リンクを設けることも多いと考えられます。この点が構成上の制約になるかは環境次第となりますが、例えばClosの様なトポロジを取る場合は同階層を接続するリンクは作らないことになります。また迂回用のポート消費を減らせる技術があればそれを選択したいという場面があることも想定されます。

このような状況に対してEVPNを用いたレイヤ2 VPNの場合、egress PEで発生したPE-CE間リンクの障害も、ingress PEでの集約されたテーブル更新のトリガとすることが可能です(Mass Withdraw)。MACエントリに対するMass Withdrawでは、前提としてMAC情報がエンコーディングされるRoute Type 2(以下、RT-2)の中にEthernet Segment(以下、ES)を示すESI (Ethernet Segment Identifier) が含まれます。つまりEVPNにおけるMACエントリは、PE-CE間リンクに相当するESが識別された状態で転送テーブルに格納できる下地があります。このためパスリストの実装が整えば、ESIを含むRoute Type 1(以下、RT-1)のWithdrawに基づき、対象のESに到達不可となったPEを切り離すだけで更新作業を終えることが可能となります。

加えてEVPNでは、IP Prefixを交換するRoute Type 5(以下、RT-5)にもESIのフィールドが存在しており、IP Routeに関連付くESの情報を含めることが可能です。関連してこのES情報は、IP-VRF間の通信においても、IP Routeに対するMass Withdrawへの利用が想定されています()。この仕組みがIP-VPNの実現で利用可能になれば、レイヤ2 VPNにおけるMass Withdrawと同様に、IP Mass Withdrawとして活用することができます。これによって、冗長PE間の直結リンクを省いた状態で、Egress PEのPE-CE間接続リンクに対するプロテクションを提供することがIP-VPNにおいても可能となります。なおRT-5はESIフィールドを使わずに利用することもできるため、IP Prefixに対するMass Withdrawの実現可否は実装次第と言えます。

図4は、本コラムで取り上げた、レイヤ3 VPNの用途においてEVPNが提供できる要素を整理したものになります。


図4:EVPNを適用したレイヤ3 VPNの特徴

 
RFC2544も、十分に成熟した技術として、既にナレッジの蓄積された環境を中心に継続して活用されることが予想されます。加えて、上記の特徴が利点に映る環境などでは、今後は実装に応じてEVPNも実現の選択肢として価値のある技術となります。
 

今回のまとめ

EVPNの機能を活用することによってマルチテナントに対応可能なレイヤ3のVPNを実現することが可能です。この場合、以下の要素を提供できることが利点として挙げられます。

●IPのみで構成されたトランスポートネットワーク
●LAGによるゲートウェイ冗長
●Mass Withdrawを活用した冗長化構成
 

執筆者プロフィール

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

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

イベント/レポート

pagetop