QFX の MAC が EVPN に現れるのに転送テーブルに現れない理由

EVPN データベースで MAC を見つけられるのは、それがルートとして広告または受信されたという証明であり、それ以上のものではない。転送テーブルは別の構造で、後からプログラムされるため、同じ MAC が一方に現れ、もう一方に欠けていても、各プロトコルは正しく動作していることがある。これら二つの出力を互いの写しとして扱うと、実際の隙間がインポートポリシーや未解決のネクストホップであるのに、エンジニアは BGP の障害を追いかけることになる。問うべきは、ファブリックが MAC を知っているかどうかではなく、 どの段階で受け渡しが止まったのか。

異なる問いに答える二つのテーブル

Junos EVPN では、データベースはインスタンスごとに MAC アドレスを、アクセスポートから学習したか、Type 2 ルートで受信したか、マルチホーミンググループの一部として印を付けたかとともに一覧する。Juniper の show evpn database のリファレンス は、表示を読みやすくする MAC 単位とインスタンス単位のフィルターを扱っている。これはインスタンスと MAC をキーにしたコントロールプレーンの要約であり、ハードウェアがフレームをスイッチングするテーブルではない。

スイッチングテーブルはまさにその転送状態である。どちらの出力も VLAN や VNI のコンテキストの隣に MAC を並べるからこそ行ごとに比較され、その比較は誤解を招く。データベースのエントリはルートが存在しインスタンスに受け入れられたことを示すが、プラットフォームがそれを転送用にインストールしたかどうかは何も語らない。

Type 2 ルートは MAC、任意の IP、ラベルまたは VNI、ルート識別子、そしてリモート VTEP を名指すネクストホップを運ぶ。ケーブルとそのルートの間では四つのことが壊れうる：ホストが学習されない、ルートが広告されない、インポートで拒否される、ネクストホップが解決しない、のいずれかだ。それぞれの失敗は異なるテーブルの組を埋めたまま残すからこそ、この順序は診断できるのである。

ローカル学習は依然として最初に起きる

よくある前提は、EVPN が MAC 学習を引き継ぐので、データベースが空ならオーバーレイの問題だというものだ。ローカル学習は今もアクセス側で動いており、VXLAN が存在する前とまったく同じで、スイッチは許可されたフレームの送信元 MAC を正しい VLAN とサービスで学習し、その後にだけ Type 2 を生成する。 関連するフレームを送っていないホストには広告するものがない。VLAN メンバーシップ、フィルター、またはアグリゲートのダウンしたメンバーによってフレームが捨てられるホストは、オーバーレイから見れば同じに見える。

アタッチメントから始め、読み取り専用のコマンドで前に進む。目的は、決して届かなかったフレームを下流の何かが補うことはないため、ホストからのフレームが意図したサービスを通ったことを証明することだ。

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

バンドルが上がっていることより選択された LACP メンバーのほうが重要で、アグリゲートは一つのメンバーで上がっていてもホストのトラフィックがダウンまたはブロックされたリンクにハッシュされることがあるからだ。インターフェースカウンターは、決して送信しないホストと分類でフレームを捨てられるホストが同じ空のテーブルを残すため、沈黙するホストとドロップするホストを区別する。

リモート MAC が失われる場所

リモート MAC は逆方向で、しかも静かに失敗する。Type 2 ルートは届くが、そのルートターゲットと VNI がローカル設定と一致したときにだけインスタンスに入り、ネクストホップが到達可能な VTEP に解決したときにだけ使えるようになる。ルートターゲットの不一致は、どのインスタンスも要求しない有効なルートを BGP テーブルに残す。

ルートの存在、データベースのエントリ、転送のエントリという三つのビューを順に読む。以下のコマンドは各段階で同じ MAC を問い合わせ、サンプルアドレスが出力を比較可能に保つ。

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

これらの出力は三つの別々の問いに答える。bgp.evpn.0 にルートがあってもデータベースのエントリがなければ、インポートポリシー、ルートターゲット、インスタンス設定を指す。データベースのエントリがあっても転送のエントリがなければ、プラットフォームのプログラミングを指し、これは別のエスカレーション経路に属する。ネクストホップが解決しないアクティブなルートはトランスポートかラベルの問題であり、どれだけ MAC をデバッグしても直らない。

それを直した再起動はほとんど何も証明しない

再起動で症状が消えると、設定は健全に違いないという結論に傾きがちだ。再起動はすべてのテーブルをゼロからプログラムし直すので、古いエントリがポリシーの誤りを覆い隠していたケースも隠してしまうが、障害は次の変更、リンクフラップ、ルート撤回で戻ってくる傾向がある。

メンテナンスウィンドウの前に、再起動が何を消すのかを記録する。この三つのコマンドで前後を比較でき、機器上の何も変えない。

show evpn database instance blue
show route table bgp.evpn.0
show version

それらの出力を日付とソフトウェアビルドとともに保管する。同じ再起動が以前も効いたという後日の報告は証拠ではなく手がかりであり、違いは以前の出力を残した人だけに見える。

ほとんどのケースを決着させる四つの観察

四つの観察でほぼすべてのケースを覆える：アタッチメントとそのサービス、サンプル値としての MAC、ルートとデータベースの状態、使用中のビルドだ。明らかにサンプルだと分かる MAC を選び、誰も本番アドレスと勘違いしないようにする：最初のオクテット 02 はローカル管理のユニキャストアドレスを示し、残りのオクテットは自由であり、したがって 02:00:00:00:00:5c は安全なプレースホルダーである。

あとは答えが失敗した段階を指し示すに任せる。アタッチメントで学習がなければアクセス側、データベースのエントリのないルートはインポート、転送状態のないデータベースのエントリはプログラミングだ。どれであれ、収集した出力をホスト、インターフェース、サービス、ビルドとともに渡せば、次のエンジニアは問い合わせを繰り返さずに経路を再現できる。