要点

  • RFC 9784はvESごとにvESIを与え、EVCを個別監視する。物理ポートが同じでも、故障まで同一とは限らない。
  • 単一EVCの障害は関連するvESまたはサービスインスタンスに閉じる。ENNI自体の障害なら、事前に記録した集合をgrouping routeで一括処理できる。
  • withdrawalは制御面の通知にすぎず、故障判定、集合の鮮度、DF選出、MAC更新、顧客通信の回復をまとめて証明しない。

一本のEVCだけが途切れ、物理インターフェースはupのまま、同じポートを通る他社サービスも正常――この場面でポート単位の古い復旧処理を動かせば、健全なC-MACまで消去し、本来なかった障害を作り出す。

RFC 9784が扱うVirtual Ethernet Segmentは、その誤作動を避けるための識別構造である。規格名はEVPNの拡張だが、運用上の論点は権限の境界にある。小さな観測が、同じ筐体に入っているという理由だけで大きな破壊権限を得てはならない。

一方、ENNIそのものが落ちれば事情は逆になる。そこに属する多数のEVCとvESが同じ物理経路を失う。何千本もの個別withdrawを待つより、一つの集合イベントを先に伝える方が合理的だ。二つの場面を区別するのは、速度と安全を両立する前提である。

仮想化は識別単位を減らさない

従来のEVPNでは、Ethernet Segmentは顧客サイトをPEに接続する物理リンクの集合だった。RFC 9784はEVC、複数EVC、PW、LSPにもその概念を適用し、vESとして扱う。同じENNIにsingle-homed、Single-Active、All-Activeの異なるvESを多数収容できる。

集約は設備効率を上げるが、顧客、broadcast domain、冗長構成、障害履歴は別々である。物理的な共通原因が存在することと、常に共通原因であることは違う。

そこで各vESには固有のvESIが必要になる。DF electionは(vESI, Ethernet Tag)単位で行われ、Ethernet TagはEVPNならVID、PBB-EVPNならI-SIDに対応する。この粒度が、どの冗長グループがどのサービスについて転送役を選び直せるかを限定する。

観測対象と復旧対象を接続する

RFC 9784は各EVCの運用状態を独立に監視するよう求める。共有ENNI上の一EVCが失敗した場合、そのEVCに関連するvESについてDF electionを起動する。

必要なのは単なるalarmではない。検出器が何を見たか、その時点でEVCがどのvESIに属したか、どのservice instanceとredundancy groupにつながったかを保存しなければならない。物理portのupはEVCの健全性を証明せず、EVCのdownはport全体のdownを証明しない。

復旧にも同じ境界がある。single-homedまたはAll-Active vESのEVC障害・回復は他EVCへ影響してはならない。Single-Activeなら影響は該当service instanceに限られ、C-MAC flushも当該I-SIDとmultihomed customer/networkに限定される。

これは「何を変えたか」だけでなく「何を変えなかったか」を検証する設計である。同一ENNI上の健全なサービスは、blast radiusが漏れていないことを示す重要なcanaryになる。

物理ポート用の処理を流用すると広すぎる

PBB-EVPNでは、一つのB-MACが物理ポート上の多数サービスを代表し得る。従来の物理ES向けMAC Mobility処理を一EVCの故障にそのまま使うと、遠隔PEが同じポート上の無関係なEVCのC-MACまでflushする。アドレス再学習が健全な通信を揺らし、復旧信号が障害源になる。

RFC 9784はRFC 9541のB-MAC/I-SID routeを使い、flushをservice instanceに閉じ込める。受信側は指定B-MACのうち、広告されたI-SIDに属するC-MACだけを対象にする。EVCが複数VLAN・I-SIDを運べば複数routeが必要になる場合があり、数が大きければvESごとのB-MACをwithdrawする方が適する。

「論理だから一つ」「物理だから全部」という短縮は成立しない。EVCとbroadcast domain、vESとportの実在する対応表が、許容される処理範囲を決める。

ENNI障害は集合として表せる

本当にENNIが失敗すると、そのportに結び付いた全EVCが影響を受ける。RFC 9784のroute coloringは、vES固有routeに物理portとの関連を記録する。既定ではportのMAC addressをcolorとし、RFC 9135のEVPN Router's MAC Extended Communityで伝える。受信PEはcolorごとのvES集合を構築する。

送信PEは、その集合を代表するGrouping Ethernet A-D per ES route、PBB-EVPNならGrouping B-MAC routeも広告できる。port failure時にこのgrouping routeを先にwithdrawすれば、他のPEは関連集合についてDF electionとfailoverを始められる。個々のvES route withdrawalは後からBGP tableを整理する。

ただし、colorはセンサーではない。「このvESがこのportに関連すると広告された」という記録である。grouping routeも集合を表すだけで、集合が現在も完全とは保証しない。withdrawalは送信者の制御面発言であって、物理故障の独立証明ではない。

最小の共有仕様は、将来の判断を各PEに残す。受信側は自分が保持する集合を参照し、選挙を行い、forwardingを変更する。その後の結果までgrouping tokenに代弁させないことが重要だ。

同じwithdrawalでも役割が違う

grouping withdrawalは、事前に組み立てた集合を用いて速い行動を始める。per-vES withdrawalは個々のBGP stateを削除する。前者ですでにDF electionを起動したなら、後者で同じ選挙を再度起動しない。

最終的なrouting tableだけを見る監査では、この順序が失われる。集合による高速切替が働いたのか、二重起動したのか、古いmembershipが無関係なvESを巻き込んだのかを説明できない。

サービス回復の証明はさらに後段にある。route advertisementはpath eligibility、DF resultはforwarder role、MAC updateはreachability stateを示す。customer frameが通ったか、正しいpathだったか、同居サービスが無傷だったかはdata planeで確認する必要がある。

実務では、検出器と対象、観測時刻、EVC–vESI–service–color対応、各受信PEのgroup membership、個別・集合処理の選択理由、BGP受信順、DFとMACの適用結果、代表traffic、非対象サービスの状態を別々に残すべきだ。「EVPN converged」という一行では責任を検証できない。

共有設備ほど権限を細くする

一つの物理設備に多くの約束を載せるほど、誤った物理単位の判断は高くつく。仮想化は観測粒度を省略する理由ではなく、粒度を守る理由になる。

running-code primacyで確認すれば層は明瞭だ。RFC公開は手順の存在、configは採用意思、BGP traceはmessage交換、device stateはlocal action、traffic recordはservice outcomeを示す。どの記録も次の層の権限を借りられない。

RFC 9784の成果は、単なるfast convergenceではない。速い処理が正しい範囲を壊さないための構造である。一回線が故障したなら一回線として扱う。portが故障したなら集合として扱う。そして集合信号を、回復済みという証明にはしない。

出典

  1. RFC 9784：EVPNおよびPBB-EVPNのVirtual Ethernet Segment
  2. RFC 7432：BGP MPLS-Based Ethernet VPN
  3. RFC 7623：Provider Backbone BridgingとEVPN
  4. RFC 8214：EVPNにおけるVPWS
  5. RFC 8584：EVPN DF Election Extensibility
  6. RFC 7023：Ethernet Connectivity Fault Management
  7. RFC 9135：EVPN Integrated Routing and Bridging
  8. RFC 9541：PBB-EVPNのB-MAC/I-SID route
  9. Lu Heng：Running-Code Primacy
  10. Lu Heng：Minimum Initial Specificationとローカルな将来判断
  11. Lu Heng：Reality Layersと象徴的権力