EVPN で変わる・変えられるデータセンターネットワーク③

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

今回は、EVPNの特徴として当初より目標に掲げられていたFast Convergenceに関する検証結果を紹介したいと思います。（前編）

EVPN Fast Convergence

EVPNの要求事項に関するRFCでは、図1の様な可用性に関する文言が確認できます。かなりシビアなことが書かれている様にも思えますが、どういった算段で実現するのでしょうか。

EVPNでは高可用性を実現する手段としてMass Withdrawと呼ばれる仕組みが導入されています。これは収容するホストに面したインタフェースのダウンを検出した際、ただちに対向へそれを通知し切り替えを促すものです。VPLSでも類する機能は存在していたのですが、実装としてメーカーの依存性があったことやインタフェースが複数関連づけられていた場合個々の状態を考慮できなかったことなどが課題でした。EVPNでは収容ネットワーク側のリンク障害が発生した場合、標準準拠且つインタフェース単位で通知する仕組みを備えています。また、冗長化されたリモートのVPNエッジから代替となるパスをBGP経由で事前に保持することによって、障害を検出した後に迂回路を用意するプロセスはカットされます。

留意すべき事項として、代替パスを保持し素早く障害を検出できた場合も、スケールしたレイヤ2 VPNにおいては、サービス停止時間はMAC数やVLAN数の影響を受けて変化する傾向にあります。これは、トポロジの変化に応じ、レイヤ2の転送テーブル（L2FIB）の更新を必要とすることが大きな要因です。FIBには収容ホストやネットワークの情報が反映され、規模が大きくなるほど更新対象となるFIBのサイズも増大します。高い可用性の要求を満たすためにはFIB更新の所要時間を極小化することが必要となりますが、この点について詳細はEVPNのRFCなどでは触れられていません。BGP/MPLSのレイヤ3 VPNではBGP PIC Edgeと呼ばれる機能が規模の依存性を排除する有効な手段として活用されており、EVPNにおいてもこのような機構を実装としてカバーするかが前述の要求を満たす上でのポイントとなります。

今回紹介するデータは、Cisco Systems社のASR9000シリーズのPBB-EVPNを対象に、VPLSと比較した障害試験を行った結果になります。試験で利用するトポロジは図2で示される構成に固定し、機器の設定を変更することによって、VPLSとPBB-EVPNの2パターンに対してサービス停止時間（以下、断時間と呼びます）を測定しました。VPLSではMC-LAGでアクティブ/スタンバイの冗長化を行い、ホスト収容側に用意したレイヤ2機器（以下、便宜的にCEと呼ぶことがあります）はVPNエッジ（以下、便宜的にPEと呼ぶことがあります）の両側に跨るLAGによって接続されています。PBB-EVPNでは、CEは同様にLAGを利用して両PEに接続し、All-Active Redundancy Modeで負荷分散を兼ねた冗長化を行っています。参考として、この時の設定情報の抜粋は表1の様になります。

表1：ASR9000における設定の抜粋（VPN関連）

機器の準備が完了した後、MAC数およびVLAN数を可変要素として、2つのサイトそれぞれに接続したテスター計2ポートから双方向でトラフィックを印加します。この状態で「1. ホスト収容側のリンク障害が発生した場合」「2. VPNエッジ自体のノード障害が発生した場合」の2通りを想定し、それぞれ中継機器側のインタフェースをシャットダウンすることによって障害を模擬しました。図3は比較対象となるVPLSの断時間、図4はPBB-EVPNの断時間となります。断時間は、観測された損失パケット数に対しPPSで除算した値をベースとして、各方向それぞれに算出しています（サイト1からサイト2へ向かうトラフィックおよびその逆。単位：ミリ秒）。

VPLSの試験結果を見ると、全体を通してMAC数およびVLAN数の増加に応じ断時間の値が大きくなる傾向にありました。中でもノード復旧時の値は特に規模の影響を受けやすく、また1 VLAN / 2 MACのケースでも値は1秒未満となりませんでした。このイベントで断時間が発生するタイミングを観察すると、ICCPのセッション再確立に伴っている様子が伺えました。この現象は今回の試験環境に依存して発生している可能性も考えられますが、条件を問わず瞬断を保証することは難しい点がVPLSの傾向として挙げられます。

一方PBB-EVPNの場合、200万のMACおよび4,000のVLANを収容する環境においても全ての障害・復旧パターンに対して1秒未満の値を達成することができました。現実的にここまでのスケーラビリティが必要とされるかは環境に依存しますが、とりわけルータ製品の場合複数のVLAN空間を束ねる・接合するといった用途で配置されることも多くあります。ネットワークが拡張した際にも将来にわたって高い可用性が提供可能な点に着目すると、EVPNは安心感の得られる技術と言えます。これは多数のユーザやサービスを重畳するデータセンター間の接続などにおいて利点に映りやすいと考えられます。

なお、PBB-EVPNにおいて規模の依存性に関しては「リンクおよびノード復旧時」の「冗長化されたサイト発の通信」に限り、VLAN数の影響を受けて、値が変動している様子が伺えました。なお該当の条件はCE側でLAGの再参加処理が行われるパターンであり、本現象はCEに依存して発生している可能性も考えられます。障害が発生したサイトの対向となるVPNエッジに着目すると、無効と判断したリモートエッジを切り離す際の断時間はMAC数およびVLAN数に因らずほぼ一定であり、また復旧したリモートエッジに再度通信をバランスする際に通信断は発生しませんでした。

全体をみるとPBB-EVPNにおける断時間は、各種の障害イベント・規模を通じて極めて短い値で安定しています。また、PE-CE間リンク・ノード双方の障害に対し一貫して高い耐障害性を提供できる点が特徴的であり、言い換えると筐体内冗長を必要とせずに可用性の要求を満たせる可能性は高くなると言えます。障害復旧の処理においてはハードウェアを含めた実装の依存性が存在するためEVPN実装の全てで今回と同等の結果が得られるとは限りませんが、EVPNの活用によって、可用性に関する要求への対応はより容易になることが期待されます。

合わせて、可用性に纏わる検証の過程で確認できた項目をいくつか紹介したいと思います。

ノード障害が発生した場合、その対向となるエッジではMass Withdrawに頼らず障害を検出することになります。通常であればIGP経由で対向の障害を検出できますが、1秒未満の断時間短縮においてはBGPに対するBFDの適用が効果を発揮しました。実装に因るところが大きい箇所かもしれませんが、断時間の短縮を追求する場合は、BGPにBFDを適用することも検討の選択肢として挙がると考えられます。

今回利用したAll-Active Redundancy Modeでは、CEにおけるLAGのメンバーとなるリンクは常にアクティブとなります。この時CEでは、LAGメンバーリンクに対する切り離し・再参加の処理が、障害・復旧に応じて即座に行われていました。この場合、PE側でBGPの折衝が完了する前にトラフィックが流れ込んでくる可能性があり、インタフェースレベルでのディレイ調整がその回避策として挙げられます。また、復旧時の切り戻しは手動で行いたいといった要件がある場合、対応が難しい動作となることが予想されます。

またEVPNにはSingle-Active Redundancy Modeも存在していますが、この場合CEの接続に複数のPE間を跨ぐLAGは利用されず、ブロックポイントが作成される構成となります。このため、VPNのトポロジ変更に応じてCEへのMAC Flushを必要とするパターンが発生します（図5）。

Single-Active Redundancy Modeを利用した別の試験では上記のパターンにおいて目立って長い断時間が発生し、今回対象としたASR9000 PBB-EVPNだけでなくMX EVPN-MPLSにおいても同様の結果が得られています。断時間の値はCEの仕様にも依存するかもしれませんが、仕組みとしてCEから見た接続インタフェースはLAGによって一本化されるAll-Active Redundancy Modeの方が全体として高い可用性を期待できると言えます。これより、透過的なVPNエッジの負荷分散を実現する場合だけでなく、高可用性に着目してEVPNを採用する場合には、All-Active Redundancy Modeが有用な選択肢になると考えられます。

（後編に続く）

執筆者プロフィール

平河内 竜樹
ネットワンシステムズ株式会社 ビジネス推進本部 第1応用技術部 コアネットワークチーム
所属
ルータ分野を核とした新旧技術の調査・検証と共に、エンタープライズ・パブリック・サービスプロバイダのネットワーク提案および導入を支援する業務に、10年以上にわたり従事

• CCIE RS
• CCIE SP

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