Underlay を疑う前に EVPN のルーター MAC を確認する
Type 5 ルートは内側フレーム用の L3 VNI とルーター MAC を運ぶ。問題ではなかった underlay の MAC を変える前に、そこを確認する。
同じ VXLAN パケットに二つの MAC アドレスが現れるが、宛先ホストのものはそのうち一つだけだ。EVPN VXLAN の IP-VRF 間設計では、内側の宛先 MAC は出口ルーターが広告するルーター MAC であり、外側の宛先 MAC は次の underlay リンクでパケットを届ける側のものだ。この二つを取り違えると、存在しない障害を underlay に探しに行くことになる。確認は順番どおりに進める。
各手順は一つの問いに答える。最初の答えが、後の手順が関係あるかどうかを決める。
1. プレフィックスルートとそのコミュニティを読む
パケットキャプチャではなくルートから始める。
show bgp l2vpn evpn route type prefix 10.20.0.0/24Type 5 ルートは IP プレフィックスを広告する。インターフェースレスな IP-VRF モデルでは、L3 VNI とルーター MAC 拡張コミュニティも運び、このコミュニティが出口のルーティング端点を特定する。MAC がプレフィックス NLRI に埋め込まれていると決めつけず、コミュニティを読む。実際には埋め込まれていないからだ。ルートが存在しコミュニティが付いていれば、コントロールプレーンはすでに役割を果たしている。
2. どの転送モデルを使っているかを確認する
インターフェースレスモデルと overlay インデックス再帰は、どちらもサポートされる別の構成だ。インターフェースレスモデルはパケットをルーティングし、遠隔のルーティング端点向けに内側フレームを組み立て、出口 VTEP に向けてカプセル化する。
overlay インデックス再帰では、入口ルーターは転送する前にネクストホップを解決するための追加ルックアップを必要とする。どちらのモデルも有効で、適用する手順はファブリックがどちらを使うかで決まる。直接ネクストホップの考え方を別の作り方のファブリックに当てはめると、キャプチャでは正しく見え、設計レビューでは誤って見える結論になる。
3. MAC には二つの異なる役割があると想定する
内側の宛先 MAC は出口ルーターが広告するルーター MAC だ。外側の宛先 MAC はローカル配送のネクストホップで、underlay ルーターであることもあり、ホップごとに変わりうる。両者が異なるのは正常であり、同じなのは要件ではなく偶然だ。内側にシャーシらしいアドレス、外側に物理的なネクストホップのアドレスが写ったキャプチャは、まさに意図したカプセル化を表している。
4. シャーシ由来の値は実装上の選択として扱う
プラットフォームは広告するルーター MAC をシステムやシャーシの識別子から導出することがあり、それはプロトコルの規則ではなく実装の判断だ。アドレス形式から何かを読み取る前に、ベンダーの割り当てと冗長化のモデルを確認する。
両方とも準拠している二つの実装が、見た目の異なるルーター MAC を広告することはある。だからベンダー間で比べても分かることはほとんどない。
5. 状態が食い違うまで何も変えない
レビューでは、選択されたプレフィックスルート、その拡張コミュニティ、BGP のネクストホップ、L3 VNI、そして結果としての転送状態を突き合わせる。そのうえでキャプチャの内側と外側のヘッダーに印を付ける。
この五つが一致していれば、奇妙に見える MAC は役割を果たしており、変更すればアドレス指定の誤りを直すどころかルーティング端点を壊す。一致していなければ、どのフィールドが誤りかが分かるので、変更は推測ではなく的を絞ったものになる。EVPN の IP プレフィックス仕様 は、その議論で引用すべき参考文献だ。モデルと、値を運ぶコミュニティの両方を説明している。