EVPNは上がっているがサービスは上がっていない：4つのチェックポイント

リモートVTEPアドレスに到達できることは、アンダーレイがパケットを運んでいることを証明するだけで、それ以上のことは証明しない。テナントサービスには、正しいアドレスファミリを持つBGP EVPNセッション、接続されて稼働しているローカルVNI、生成された経路、そして遠端でのインポートが必要である。これらは四つの別々のチェックポイントであり、それぞれ修復方法が異なる。グリーンのアンダーレイをサービスの準備完了とみなすことが、EVPNの立ち上げが行き詰まる最も一般的な原因である。

順番に読み、設計が期待する状態と異なる最初のチェックポイントで止める。後続のチェックポイントは先行する障害を補えない。

チェックポイント 1：VTEPへのトランスポート

VTEPのソースとして使われるループバックアドレス間の到達性から始める。経路はアンダーレイに存在し、カプセル化の要件を含めて経路が許可され、戻り経路が機能している必要がある。経路が存在しても一方向でフィルタされていると、断続的に見える非対称な障害になる。先に進む前に両方向を確認する。

確認したソースアドレスと宛先アドレスを記録する。別のアドレスでネクストホップを解決する後続の手順は別のテストであり、これらを一つとして扱うことが、解決済みのネクストホップをトランスポート障害のせいにする原因になる。

チェックポイント 2：セッション数ではなくEVPNファミリ

BGPセッションが確立していても、EVPNアドレスファミリがネゴシエートされたとは限らない。ネイバーのファミリ固有の状態を見る：ファミリが有効か、ピアとネゴシエートされたか、セッションがそもそもそれを運んでいるか。IPv4ユニキャスト用に上がっていてEVPNを一度もネゴシエートしていないセッションは、一般的なネイバー概要では何も異常に見えない。そしてEVPNオーバーレイ仕様は、サービスと制御の手順をトランスポートとは別の関心事として扱っている。

セッションのソースアドレスも確認する。VTEPのソースではないアドレスで組んだピアリングは、転送障害の原因を説明するために待っている設計の不一致である。

チェックポイント 3：ローカルサービスが接続されている

ローカルVNIはテナントを表すブリッジまたはVRFに接続され、プラットフォームがそれを稼働中として報告する必要がある。レプリケーションモデルが使うメンバーシップ状態は、ホストMACを学習する前から重要になることがある。したがってエンドポイントテーブルが空であることは、サービスが停止している証拠ではない。

次に、デバイスが実際に何を生成しているかを確認する：設計が指定するルートターゲットを持つ、そのVNIのローカル経路である。接続されているが広告されていないVNIは、ローカルにだけ存在し他にはどこにもないサービスを生む。

チェックポイント 4：受信側でのインポート

受信側デバイスでは、数値のVNIではなくエクスポートされたルートターゲットとインポートされたルートターゲットを比較する。VNI番号が一致しても、受信側インスタンスが広告をインポートしている証拠にはならない。また、一致しないルートターゲットはVNI一覧では見えない。転送エントリを信頼する前に、広告されたネクストホップをアンダーレイ経由で解決する。その後、オーバーレイの転送状態をデバイス全体ではなくサービスについて読む。

ピアテーブルは実装固有のデータプレーンやメンバーシップ学習を反映していることもある。行数を証拠として扱うのではなく、その起源とサービスの文脈をEVPN経路と併せて読む。

経路をたどる一つの記録

サービスごとに一つの記録を保つ：ローカルVNIの状態、EVPNネイバーとファミリ、生成された経路、受信およびインポートされた結果である。その記録を生成からインストールまでたどる。何かが失敗したとき、どのコマンドを試すかではなく、四つのチェックポイントのどれを修復するかを記録が示す。

その作業をしながらタイムスタンプを付ける。広告の数分後に現れるインポートはポリシーかコンバージェンスの問題であり、決して現れないものは設定の問題である。その違いは、いつ確認したかを書き留めたときにだけ見える。

静的VXLANが正解となる場合

静的に構成されたVXLANデータパスは、EVPNテーブルが空のままでも手動で用意したピアと連携できる。それは壊れたEVPN展開ではなく、別の制御モデルである。空のテーブルを障害と診断する前に、設計がどちらを意図しているかを決める。

アンダーレイのIGPネイバーはトランスポートを提供するだけで、それ以上のことはしない。オーバーレイのサービス状態は、構築するのも検証するのも別のことである。