要約
- RFC 9721が扱うのは、EVPN-IRBの結合MAC+IPルートに一つの移動シーケンスしかないというモデル上の限界である。IPだけが別MACへ移る、MACが別IPを持つ、all-activeのPEが異なる時点で学習する場合、番号だけでは双方の鮮度を表せない。
- 規格はフィールドを増やさず、親MACの番号、子MAC+IPへの継承、マルチホームpeer間同期、最大値による互換処理、ARP/NDP probe、範囲を分けた重複回復を組み合わせる。高い番号はルート版の証拠にすぎず、ホストの身元、物理位置、FIB収束、サービス復旧を証明しない。
同じEthernet Segmentに接続された二台のPEが、同じホストを同時に広告している。一台はシーケンス0、もう一台はN+1。監視画面は大きい方を新しいと表示する。しかし二台は異なるホストを見たのではない。古いリモートルートが消える前に学習したか、消えた後に学習したかが違うだけである。
数字の差は嘘ではなく、観測時代の差である。ここで最大値だけを採用しても、peer同期が成功したか、古いARPエントリが残るか、パケットがどこへ進むかは分からない。
RFC 9721は、この不一致を単なる収束速度の問題として扱わない。一つの番号がMACとIPという二つの対象を同時に版管理するとき、その番号の権限をどこから得るかを定義する。
一つのRT-2に入っても一つの身元ではない
RFC 7432のMAC Mobility Extended Communityは、MACが別Ethernet Segmentへ移ったとき、後の広告を高いシーケンスで選べるようにした。版管理の対象はMACルートであり、比較の意味は比較的明確だった。
IRBではRoute Type 2がMACとIPを一緒に運ぶ。RFC 9135が示すように、MACはbridge tableへ、IPとの対応はARP/NDやIP-VRFへ入る。同じNLRIにあることは、同じライフサイクルを持つことを意味しない。
VMはIPを維持したまま新しいMACで再生成される。再プロビジョニングでMACを残しIPだけ変わる場合もある。firewallの背後では多数のIPが一つのMACを共有する。固定一対一の前提は、仮想化環境で簡単に崩れる。
新しい組ごとに番号を0から始めると、現実では新しいIP-a/MAC-bが、古いIP-a/MAC-aの番号に負ける。別々のMAC用・IP用番号をwire formatに増やせば意味は明確になるが、互換性と実装の複雑さが増す。
RFC 9721はローカルな親子関係を採る。MACルートを親とし、それに結び付くMAC+IPルートは親のシーケンスを継承する。IPが別のリモートMACに付いていたなら、新しい親はそのMACの番号も上回る必要がある。親がpeer同期で引き上げられれば、全ての子も追従する。
BGP広告にこの計算過程は載らない。外部から見えるのは一つの値であり、比較対象、親の旧値、更新された兄弟、Peer-Sync-Localの入力、残存neighbor stateは見えない。したがってpacket captureは広告の存在を証明しても、値の来歴を証明しない。
監査記録は、学習したinterfaceとESI、MAC/IP、親の前後値、比較したリモート状態、継承した子、送信した広告・withdrawを結ぶ必要がある。数値が正しい形式であることと、正しい対象を版管理していることは別である。
all-activeが必要とするのは共通の世代
all-activeでは複数PEが同じESを代表する。frameやARP/NDP responseはhashによって片方へ先に届く。ローカル学習は非同期であり、物理接続が共通でもデータベースは同時に更新されない。
古いセグメントからhostが移る場面で、PE1は旧route消失後に学び0を付ける。PE2は消失前に学びN+1を付ける。remote PEは同じESIから異なる番号を受け、ECMP pathを組めないことがある。将来番号Nが戻れば、一台は古いと捨て、もう一台は新しいと選ぶ。
RFC 9721はlocalとPeer-Sync-LocalのMAC/MAC+IPシーケンスをpeer間で一致させる。同期値が親を上げれば全ての子も更新する。必要なのは「同期セッションあり」ではなく、同じESIを広告する全PEが同じepochを持つ証拠である。
peer membership、対象object、受信値、以前のlocal値、決定値、変更された子、各PEの適用acknowledgementを残すべきだ。ESIが一致しても、状態が一致したことにはならない。
最大値は後退を防ぐが、原因を測らない
異なる実装では、MAC-onlyと複数のMAC+IPで番号がずれることがある。RFC 9721は、同じMACに関係する値の最大をremote parentとして解釈し、withdrawのたびに再計算するよう求める。MAC-onlyがなければ、結合ルート群の最大から親を導く。
これは互換処理として合理的である。一度見た高い履歴を、小さい兄弟値で巻き戻さない。しかし最大値の原因は分からない。正当なmove、peer補正、race、古いbindingの往復、host-facing側の偽装が同じ上昇を作り得る。
現在のRFC 9721 errataにはRejectedのTechnical Erratum 9001がある。RFC 7432だけを実装するPEは、同じIPが別MACへ移ったとき、旧MAC側の値を超えるよう新MACを上げる義務を知らない、という混在例である。Area Directorは新しい挙動がlegacy PEにない限界を認めたが、後方互換性がないという訂正文は退けた。古い仕様はその拡張を定義せず、既存encodingと従来挙動は引き続き相互運用するからである。
運用上は二つを同時に守る。erratumを規範変更として引用しない。拡張moveを必要とするPEが実際にRFC 9721の挙動を持つかは必ず確認する。
probeは存在を問い、身元を保証しない
高い、またはtie-breakで勝つremote routeを受けたPEは、関連local bindingをprobeし削除する。RFC 826のARPとRFC 4861のNeighbor Discoveryが近隣確認の基礎となる。
応答は「local attachment上の何かがそのaddressへ答えた」というrunning evidenceである。意図したVMだとは証明しない。orchestratorの権限も、remote pathの動作も証明しない。無応答もmove、silence、filter、loss、誤ったcontextのどれか分からない。
共有MACのraceでは、二つのIPが反対方向にbindingを変え、古いARP/NDP/MAC stateが残る。新routeがPE間を跳ね、番号が増え続ける。正しいprobeで古い観測を消すまで、算術はraceを終わらせない。
probe target、interface、送信時刻、reply/timeout、削除entry、withdraw、代替FIB、後続packetを一連のreceiptにする必要がある。「より高いrouteを受信」は開始条件であって完了ではない。
duplicate freezeは安全側の停止である
RFC 9161はProxy ARP/NDのduplicate IP detectionを規定する。RFC 9721はduplicate MAC、別MACに結び付く同一IP、MACを広告しないrouted overlayのIPを分ける。RFC 9136はRoute Type 5の背景を与える。
設定回数のmoveが時間窓内に起きれば、addressをduplicateとしてfreezeできる。これは不確実性の下で被害を止める判断であり、attack attributionではない。migration loop、同期ずれ、重複provisioning、spoofingは似た観測を生む。
回復はhost側で誤った割当を解除することから始まる。agingを待つか、unfreezeやclearで早める。unfreezeはさらに高い番号を広告するため、競合hostが残っていれば争いを大きな数字で再開するだけである。一台だけ直してもpeer同期が争点のepochを戻す可能性がある。
終了判定には、hostのunprovision、範囲を限定したPE操作、全peerの収束、双方向packetとapplication成功が必要である。番号増加はどれの代わりにもならない。
数字の権限を説明できる台帳
実務では、orchestration intent、local learn event、親と子、peer同期、remote広告とwithdraw、実装version、maximumの導出、RIB/bridge/ARP-NDP/IP-VRF/FIB変更、probe、duplicate thresholdとfreeze、unfreeze権限、application outcomeを別々に保存する。
それぞれの所有者も分ける。platformは意図を、access PEは観測を、multihoming groupは共有epochを、BGPは伝達を、FIBは実行を、service ownerは結果を持つ。一つの「fabric converged」表示で全てを代用してはならない。
Lu HengのMinimum Initial Specificationは、共通fieldが協調を担いながらlocal decisionを奪わない設計を支える。Reality Layersは広告、選択、forwarding、serviceを別の現実として扱う。Running-Code Primacyは、整ったcounterより同期table、active probe、FIB readback、実packetを重く見る。
RFC 9721の核心は番号を万能にすることではない。番号が知らない関係を、実装と運用が証拠として保持することだ。最大値だけを見れば判断は速い。だが、なぜその値がそのMAC/IP家族を代表するのか説明できなければ、速い判断ほど危険になる。
情報源
- RFC 9721本文
- RFC 9721公開記録
- RFC 9721 IETF Datatracker
- RFC 9721文書履歴
- RFC 9721 errata
- RFC 7432: BGP MPLS-Based Ethernet VPN
- RFC 9135: Integrated Routing and Bridging in EVPN
- RFC 9161: Operational Aspects of Proxy ARP/ND in EVPN
- RFC 9136: IP Prefix Advertisement in EVPN
- RFC 826: Address Resolution Protocol
- RFC 4861: IPv6 Neighbor Discovery
- Lu Heng: Running-Code Primacy
- Lu Heng: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Lu Heng: On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
