EVPN タイプ2 とタイプ5：一つの IP アドレスが二つのルートを意味する理由

同じ装置上の二つのルートが 198.51.100.77 を指していても、答えている問いは違うことがあります。一方は MAC アドレスがどこから到達できるか、そして任意でどの IP が結び付いているかを記述します。もう一方は、次ホップを経由して解決されるプレフィックスを記述し、そのプレフィックスが単一ホストであっても変わりません。両者を取り違えると、ルーティングの不具合に見えて実はルート種別の読み違いにすぎないチケットが生まれます。

見分ける最短の方法は、NLRI が何を中心に組み立てられているかというキーを読むことであり、末尾のマスクではありません。

ルートのキーは、そのルートが何を主張するかを示す

タイプ2 は RFC 7432 の MAC/IP アドバタイズルートであり、そのキーは NLRI 内部の 48 ビット MAC アドレスです。そのキーの後ろには IP アドレスフィールドがあり、長さフィールドは 0、32、128 ビットのいずれかになり得ます。したがって MAC のみのアドバタイズは完全なルートであり、部品が欠けたホストエントリではありません。続くラベルスタックは、その MAC が存在するブリッジングコンテキストを指します。

IP フィールドが埋まっているかどうかは、ルートが何を述べるかを変えるのであって、ルートの種類を変えるのではありません。長さが 32 ビットまたは 128 ビットの場合、送信者はこの IP が一つの EVPN インスタンス内でその MAC に属すると主張もします。長さがゼロの場合、送信者は IP について一切主張しません。どちらの版も、プレフィックスがルータ経由で到達可能だとは述べていません。

タイプ5 は RFC 9136 の IP プレフィックスルートであり、そのキーは長さとそのビット数として書かれたプレフィックスです。長さは IPv4 では 0 から 32、IPv6 では 0 から 128 の範囲です。

その範囲の両端はどちらも正当であり、どちらも MAC を意味しません。長さゼロのプレフィックスはホストを名指しせずに到達性を主張し、/32 はちょうど一つのアドレスを名指しします。NLRI は、出口側がオーバーレイインデックスを構築するために使うゲートウェイ IP アドレスと、転送コンテキスト用のラベルも運びます。切り替える MAC フィールドは存在しないため、受信側はタイプ5 をルーティングされた宛先として扱います。

/32 プレフィックスルートは名前を変えたタイプ2 ではない

ホストサイズのプレフィックスは通常のタイプ5 ルートです。/32 プレフィックスルートと同じアドレスのタイプ2 は一つの EVPN インスタンス内に共存でき、異なる転送情報を持ちます。

VNI 10100 を使う EVPN インスタンスで 198.51.100.77 を考えます。タイプ2 はそれを MAC 02:00:00:00:00:77 と、その MAC を学習したブリッジドメインを識別するラベルと組み合わせることがあります。タイプ5 はサブネット全体に対して 198.51.100.0/24 を、あるいはそのアドレスだけに対して 198.51.100.77/32 を、出口 VTEP を指すゲートウェイアドレスとともにアドバタイズすることがあります。ルートが異なる問いに答えているため、アドレスは意図的に重なります。

一方のルートは、エンドポイントのバインディングが存在し、特定のブリッジを通じて到達できると述べます。もう一方は、その内部のエンドポイントが一度も学習されていなくても、プレフィックスが特定のルータを通じて到達できると述べます。

この違いが、トラフィック障害時に最初にどこを見るかを決めます。単一ホストに到達できないのにそのサブネットルートが正常に見えるなら、タイプ5 はそもそもそのホストを運ぶ想定ではありません。欠けているタイプ2 を探してください。ホストルートはあるのにサブネット全体に到達できないなら、タイプ5 がそもそも生成されたかを確認してください。フィールドを順に読むことは、マスク長から推測するより優れています。

推測せずに両方のルートを読む

NX-OS では、show bgp l2vpn evpn route type 2とshow bgp l2vpn evpn route type 5がこの線に沿ってテーブルを分割し、show l2route evpn mac ipはタイプ2 ルートの背後のローカルな MAC から IP へのバインディングを表示します。Junos では、show evpn databaseが学習された MAC と IP のバインディングを一覧し、show route table bgp.evpn.0がアドバタイズされ受信された内容を表示します。

結論を出す前に、route distinguisher と Ethernet タグで絞り込んでください。同じ MAC やプレフィックスが複数の EVPN インスタンスに現れることがあります。あるインスタンスで誤って見えるルートが、別のインスタンスでは正しいこともあります。

次に NLRI を順に読んでください。ルート種別、キー、ゲートウェイまたはラベルのフィールド、そして属性の route target です。ゼロ以外の ESI を持つタイプ2 は、その MAC がマルチホームであることを示し、異なる PE ルータからのアドバタイズを結び付けるのはまさにその値です。ゲートウェイアドレスを持つタイプ5 は、どの出口 VTEP がトラフィックを受け取るべきかを示します。

ルートが見つからない場合は、エンコードの前に生成を確認してください。送信元がバインディングまたはプレフィックスをローカルに持つことを確認し、次にそれに付いた route target がこの装置でインポートされていることを確認します。壊れたタイプ5 の報告の多くは、NLRI の形式ではなくインポートポリシーで終わります。

ルート種別だけでなく、コンテキストを記録する

ルート種別、EVPN インスタンス、route distinguisher、インポートおよびエクスポートされた route target、解決された次ホップをまとめて書き留めてください。インスタンスのないタイプ2 は曖昧であり、ルートファミリーのない次ホップは誤った結論を招きます。

ペイロードが IPv4 アドレスであっても、どちらも EVPN ルートです。NLRI 内部のアドレスファミリーとルート自体のアドレスファミリーは別の性質であり、タイプ5 は IPv4 プレフィックスを運ぶというだけで IPv4-unicast や VPN-IPv4 のルートになるわけではありません。

この区別は EVPN コントロールプレーンと IP-VRF の境界に現れます。route target はどの VRF がプレフィックスをインポートするかを決め、ゲートウェイアドレスとラベルはパケットが出口に向けてどうカプセル化されるかを決めます。これらを合わせて読めば、転送の判断は恣意的に見えなくなります。

次に EVPN テーブルに /32 が現れたら、マスクより先にキーを確認してください。任意の IP を伴う MAC キーはタイプ2 のバインディングであり、プレフィックスキーは長さにかかわらずタイプ5 ルートです。route target と次ホップをその横に書けば、次のエンジニアは物語全体を再導出せずに済みます。