タグなしアクセスポートを正しい EVPN VNI に対応付ける

タグなしのホストフレームはアクセスポートで分類され、VTEP によって VNI として運ばれます。イングレス、イグレス、サービスモデルを別々に確認してください。

通常のイーサネットホストはタグなしフレームを送信し、EVPN ファブリックはそれを正しいテナントサービスで運ぶ必要があります。アクセスポートはフレームをローカルセグメントに分類し、VTEP はそのセグメントを VNI に対応付け、遠端の接続点はホストが期待する形でフレームを提示します。VLAN と VNI はこの経路の異なる部分を識別するもので、同じ番号である必要はありません。以下の runbook を順番に実行してください。どの段階の誤りも同じ症状、つまり送信しているのに何も受信できないホストを生みます。

一つのフレームをファブリック全体で追う

単純な VLAN ベースのサービスでは、例示的な経路は次のようになります。

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

VLAN と VNI の番号はあくまで例であり、規則ではありません。ローカル VLAN は一台のスイッチに存在するイングレス分類です。L2VNI は両方の VTEP が理解するオーバーレイのサービス識別子です。オーバーレイ仕様 RFC 8365 はサービス識別子をホストの接続方法から切り離し、VLAN ベース、バンドル、VLAN 対応という三つの形態を挙げています。

イングレス分類を設定する

ホストにはアドレスがあるのに何にも到達できず、ポート自体は見えています。ポートが実際にどちらの接続モードにあるのか——タグなしフレームを運ぶアクセスポートか、native VLAN を持つ trunk か——を判断し、その一方を明示的に設定します。タグなしフレームはそれでも名前付きのローカルセグメントの内側でポートを離れます。そのセグメントはプラットフォームの副作用ではなく、意思決定です。ポートの実行中コンフィギュレーションを開き、実際に持っている分類を読み取ってください。設定したことのないベンダーの既定値を信じてはいけません。

一般的なスイッチでは、モード変更とアクセス VLAN の割り当て、続いてポートが実際に up でその状態にあることの確認、という順序になります。ポートが trunk ならタグなしフレームは native VLAN が扱い、それは別の設定であり、失敗の仕方も異なります。先に進む前にモードと VLAN の両方を記録してください。

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

VTEP と VNI の対応付けを設定する

VTEP が VXLAN カプセル化と VNI を付加します。ホストはそのヘッダーを生成せず、サービスが存在することを知る必要もありません。

プラットフォームがサポートするコマンド形式でローカル VLAN を L2VNI に対応付け、その対応付けをサービスの両端で一貫させます。テナントの L2VNI と、サブネット間ルーティングに使う L3VNI は別のオブジェクトであり、番号を混ぜると L2 経路に触れないままルーティングが壊れます。また、遠端の VTEP への有効なアンダーレイ経路は構成のさらに別の層に属することも覚えておいてください。

対応付けが誤っていると、フレームはそのままファブリックに入り、単に誤ったサービスに落ちます。だからこそこの確認はリンクの確認ではなく、サービスの確認なのです。

イグレスでの提示を設定する

遠端では、受け取ったサービスをホストが期待する形に戻す必要があります。アクセスポート上の生のイーサネット、管理下の trunk 上の特定のタグ、そして選んだサービスモデルに合う内側タグの扱いです。オーバーレイを責める前に trunk の許可 VLAN リストを確認してください。イグレス側の trunk が許可しないタグは、オーバーレイがすでに仕事を終えた後に破棄されます。遠端のホストが期待しているのは、図で仮定した提示ではなく、実際に受け取る提示であることを確認します。

内側タグが残るかどうかは選んだサービスモデルの性質であり、一般に剥離や保持を約束できる記事はありません。ある挙動を前提にした設計と、もう一方を実装したプラットフォームは、リンクテストを通ってもアプリケーションで失敗します。

ローカル MAC 学習、EVPN のサービスルート、遠端の接続対応付けをまとめて読み、ping だけでなくアプリケーションが必要とする近隣探索を動かしてください。別のブリッジドメインで学習された MAC アドレスはそこで完全に有効でありながら、誤ったサービスを指していることがあります。

一組のホストで検証する

まず一組のホストを立ち上げ、二組目を追加する前に経路全体を証明します。そのうえで両方の VTEP の状態を読み、同じサービス識別子が両端に現れることを確認してください。

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

各端について四つの値を書き留めます。ポートの提示、ローカルセグメント、L2VNI、そしてイグレス側の逆方向の提示です。この記録があれば、次のエンジニアはホストが単純なタグなし接続なのにファブリックがテナントサービスを運んでいる理由を理解できます。変更が失敗したらポートを元の VLAN に戻し、同じ組で再テストしてください。ロールバックが推測ではなく既知の状態になります。

関連記事