ひとつの EVPN テナントで複数の route distinguisher が表示される理由
ひとつのテナントにふたつの RD があっても競合ではありません。CLI 出力からルートを生成した MAC-VRF または IP-VRF までたどり、次に RT インポートと VNI を確認します。
ひとつのテナントについて EVPN テーブルを絞り込むと、ルートはふたつの異なる route distinguisher を持っています。最初の直感は設定の競合ですが、その直感はたいてい間違っています。テナント名はビジネス上のラベルであり、コントロールプレーンの単一のオブジェクトではないため、その内部のブリッジングコンテキストとルーティングコンテキストは別々の識別子で正当に広告できます。ルートを一本ずつ出力から、それを生成したローカルなサービスオブジェクトまでたどると、ふたつ目の RD は誤りのようには見えなくなります。
混乱した出力から始める
テーブル全体ではなく、ルートを一本選びます。そのルートタイプ、RD、エクスポートされた route target、ネクストホップを記録します。この四つのフィールドだけで、どのローカルオブジェクトが広告したのか、どのリモートポリシーがインポートすべきかが特定できます。
NX-OS スタイルの機器では、詳細表示は次のコマンドで得られます:show bgp l2vpn evpn route-type 2 detail、またはshow bgp l2vpn evpn route-type 5 detail。Junos では同じ情報が次にあります:show route table bgp.evpn.0 detail。構文は違っても、フィールドは同じです。
表示された数値をすべて同じにすることから始めてはいけません。RD を揃えることは、稼働中の fabric でインポートポリシーを壊す変更です。
それぞれの識別子に役割を与える
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF はブリッジングサービス向けの MAC 転送情報を保持します。IP-VRF はルーテッドサービス向けの IP ルーティングコンテキストを提供します。テナントは両方を含められるため、設定の誤りがなくてもひとつのテナントが複数の RD を生成できます。
RFC 7432 は広告する MAC-VRF の RD をその EVPN NLRI に割り当て、同じ PE 上の MAC-VRF 間で異なる RD を要求します。route-target の手続きは別です。ひとつ以上の RT 属性を許容し、メンバーシップはインポートポリシーに依存します。共通のメンバーシップを生むのは RD の一致ではなく、そう扱うことがこの混乱の根です。
広告からインポートまでルートを一本たどる
ルートを一方向にたどります。ルートタイプ、生成したサービス、RD、エクスポートされた RT、そして受信側 PE のインポートポリシーを確認します。各段階は異なる問いに答えており、どの段階での失敗も、反対側で同じプレフィックスが欠けているように見えます。
ルートが存在したら、インストールされた転送コンテキストと VNI マッピングを調べます。両端で VNI が一致することはデータプレーンが合意していることを示しますが、コントロールプレーンが意図したポリシーでルートをインポートしたことは示しません。
ルートがリモート PE に現れてもトラフィックが流れないなら、問題は EVPN の外に移っています。route target を再び編集する前に、VNI と VLAN の対応、または VNI と VRF の対応、そして underlay の経路を確認します。まずマッピング、次に underlay、そのあとでようやくコントロールプレーンです。データプレーンの障害を追いかけて route-target の変更を巻き戻すのは、稼働中のインポートを壊す確実な方法です。
レイヤー3 のプレフィックスも EVPN ルートです
EVPN テーブルの IP プレフィックスは通常の IPv4-unicast BGP ではありません。 というルートは独自のルートタイプです。また MAC/IP と IP プレフィックスの広告は EVPN アドレスファミリーを流れ、RFC 7432 はこれを AFI 25 と SAFI 70 として識別します。
この区別は、EVPN テーブルのルートをユニキャストテーブルのルートと比べるときに重要です。同じ宛先を表していても、別々のポリシーで生成・フィルタ・インポートされます。一方を他方の証拠として読むと、正しい fabric が移行中に壊れて見えます。
数値を比べる前にベンダーの導出を確認する
RFC 9136 は EVPN を IP Prefix ルートで拡張し、該当する RD が MAC-VRF と IP-VRF のどちらのコンテキストから来るかを規定します。だから同じ出力の L2 サービスラベルとルーテッドサービスラベルは、属するオブジェクトに対して読むべきで、テナントごとにひとつの RD へ還元すべきではありません。
RD と RT の自動導出はベンダー固有です。使用中の計算式については導入したベンダーのリファレンスを読んでください。ひとつのスイッチで見た自動生成値は普遍的な符号化ではなく、ふたつのベンダーの数値を比べてもほとんど何も証明できません。
最初に扱ったルートについて書面の追跡で締めます。タイプ、生成元オブジェクト、RD、エクスポートされた RT、インポートポリシー、インストールされた VNI です。六つのフィールドがあれば、次にチケットを読む人に広告を説明でき、そのどれもテナントの数値を一致させることを要求しません。