要約

  • RFC 9786 は EVPN の選出単位を Ethernet Tag から ES の物理ポートへ広げるが、選ばれたポート上の全サービスを検査するものではない。
  • 全 PE の DF algorithm と capability bitmap が一致しなければ Port Mode は成立せず、一台の不一致でも既定選出への fallback が ES 全体に及ぶ。
  • LACP、ARP/ND/MAC/VRF の同期、per-ES の P/B、FIB、パケット観測、顧客確認は、それぞれ独立した受領記録として残す必要がある。

タグを消すと責任はポートに集まる

RFC 9786 の Port-Active は、RFC 7432 の All-Active と Single-Active に第三の運用形態を加える。通常の DF 選出が [ES, Ethernet Tag] ごとに行われるのに対し、Port-Active は Tag を計算から外す。ひとつの ES につき一台の PE がポートを active に保ち、ほかの PE は同じアクセス側ポートを standby にする。

狙いは明確である。MC-LAG の CE は一つの LAG を使い続け、事業者はインターフェース単位で予測可能な経路を得る。フローごとの分散では不安定になり得る QoS も、一つの active ポートに集約できる。MPLS、VXLAN、SRv6 のいずれにも依存せず、L2 EVPN、VPWS、L3 VPN、グローバルルーティング、IRB を同じアクセス冗長化の下に置ける。

ただし、簡潔な制御は小さな障害範囲を意味しない。一つの物理ポートが多くの VLAN と L2/L3 サービスの容器になるため、誤った active 判定はその容器全体へ伝わる。RFC は DF がポートを up and forwarding に保つよう求め、non-DF には全 VLAN の双方向 blocking を推奨する。non-DF はリンクを down にしても、LACP Out of Sync にしてもよい。選出結果だけでは、そのいずれが正しく実装されたかは分からない。

Capability bit は合意書であって検査票ではない

IANA の登録表では bit 5 が Port Mode Designated Forwarder Election である。P=1 のとき Modulo は ESI だけを使い、HRW も Ethernet Tag を除いて ES の重みを計算する。RFC 9785 の Highest/Lowest Preference と Don't Preempt もポート単位で利用できる。

しかし RFC 8584 は、広告される bitmap を「望む手順」の信号として扱う。PE がその手順に従う条件は、ES の全 Route Type 4 が同じ algorithm と capability bitmap を示すことである。一つでも異なる広告があり、community が欠け、あるいは同一路由に複数存在すれば、既定の Algorithm 0 と capability なしに戻る。

RFC 9786 の security considerations は、この unanimity を攻撃面としても読む。設定権限を得た者が一台の PE だけを変えれば、全 PE を fallback させ、不公平な負荷配分、サービス断、loss、duplicate traffic を引き起こし得る。したがって「全員が P=1」も「PE1 が DF」も時間のある一点の制御面事実にすぎない。

ここで RFC 9785 との境界が重要になる。Preference は候補の順序を決め、Don't Preempt は復旧した高優先 PE が直ちに現職を奪わないようにできる。RFC 9786 はそれをポートに適用するが、順序をサービス準備へ変換しない。選ばれたポートに正しい CE 側 LACP partner が見えるか、リンクエラーが収束したか、必要な VRF が存在するかは別の問いである。

Warm standby の温度は一つしか測らない

standby ポートが down なら、active への移行時に物理リンクを上げ、ネットワーク状態を安定させる時間が要る。このため RFC 9786 は事前同期を挙げる。IRB/L3 では ARP と Neighbor Discovery cache、関連 VRF、L2 では MAC table が対象になる。

LACP Out of Sync を保つ warm standby はリンク起動の一部を前倒しできる。だが「warm」は包括的な readiness ではない。LACP の actor/partner、Sync、collecting、distributing が正しくても、MAC、ARP/ND、VRF、FIB や remote path は古い可能性がある。逆に状態同期が完了しても、CE がその member を選ばなければ顧客パケットは流れない。

P/B bit にも同じ限界がある。RFC 8214 の L2-Attr Extended Community を Ethernet A-D per-ES に載せ、Primary または Backup だけを示すと、遠隔 PE は早く path を切り替えられる。per-ES の parent P/B は per-EVI の値を上書きする。しかし広告の受信は経路選択の入力であって、転送完了の観測ではない。

さらに古い RFC 7432/RFC 8214 実装は per-ES の L2-Attr を無視する。それでも ESI Label の Single-Active signal と従来の MAC/per-EVI 手順は動く。つまり同じ ES 内でも、ある装置は新しい parent P/B を使い、別の装置は古い情報だけで path resolution を行い得る。能力在庫と実際の受信情報を保存しなければ、同じ DF 表示から異なる現実が生じる。

サブインターフェースの失敗は選出を動かさない

Port Mode では AC-DF bit A を 0 にし、受信した A=1 も無視する。AC が down になって Ethernet A-D per-EVI が withdrawn されても、ポートの DF 選出には影響しない。これは設計上の隔離である。同時に、ポート DF が変わらないことが EVI の健全性を意味しない理由でもある。

運用表示は二段に分けるべきだ。ポート段には ESI、参加 PE、algorithm、bitmap、timer、DF/BDF、LACP、per-ES P/B を置く。サービス段には VLAN/EVI/VPWS/VRF ごとの MAC、neighbor、FIB、remote reachability、counter、packet probe、顧客確認を置く。一方は共有制御の責任者を示し、もう一方は実際の提供結果を示す。

RFC 9722 の時刻同期は activation window を合わせ、瞬間的な二重 DF を抑える。それでもアプリケーション到達を測定しない。RFC 9784 は一 EVC と物理 ENNI の障害を分け、vES と grouped withdrawal を扱う。RFC 9786 は別の問い、すなわち物理ポートを意図的に一括制御するときの証拠責任を扱う。

RFC Editor の情報、Datatracker と errata search は規格記録を示す。2026 年 9 月 11 日の取得時に matching errata はなかったが、実装や性能を証明するものではない。