同じ /24 を二つの顧客で使う？VPNv4 には RD とラベルが要る

二つのテナントが同じ 10.50.0.0/24 で拠点を採番しており、変更のあと一方のテナントのルートはプロバイダーエッジから消え、もう一方は動き続けています。そのチケットの背景にある単純化は、たいてい「ラベルがすでに顧客を識別している」という理由でルート識別子（RD）を落とすことです。そうではありません。RD とラベルは二つの別の問いに答えており、その差は重複アドレスが強いるまでは見えません。

二つあるべきところに一つしかないルート

通常の IPv4 ユニキャストは同じプレフィックスへの二つの経路を比較し、良い方をインストールします。テナント A の 10.50.0.0/24 とテナント B の 10.50.0.0/24 は一つのキーなので、片方が勝ち、もう片方はバックアップ経路としてしか残りません。プロトコルは言われたとおりに動きました。制御プレーンは二つの異なるルートを一つの識別子の下に保存するよう求められていたのです。

結果はエラーではなく、消えたルートのように見えます。競争に負けた PE は自分のテナントをローカルに転送し続けるため、サイト内の疎通確認は成功し、サイト間のテストは失敗します。ポリシーに触れる前に、VPNv4 テーブルでそのプレフィックスのエントリを数えてください。

RD は一つのキーを二つに変える

八バイトのルート識別子が IPv4 プレフィックスの前に付加され、BGP が運ぶオブジェクトは IPv4 プレフィックスではなく VPN-IPv4 アドレスになります。二つのテナントが同じ 32 ビットを持てるのは、前の 64 ビットが異なるからです。AS ベースの RD とアドレスベースの RD には形式タイプがあり、選択は発信側 PE に属します。PE が同じ AS を共有する場合は AS ベースの RD が一般的で、共有しない場合はアドレスベースになります。

RD をメンバーシップタグとして読まない。ルートターゲットはインポートとエクスポートを制御し、どの VRF がルートをインストールできるかを決めます。RD はルートが固有の識別を持つことだけを保証します。各 VRF に固有の RD を与えるのは一般的な慣行で、その対応関係をルートビューアーで読みやすく保ちます。

ラベルはローカルの転送指示である

各広告は MPLS ラベルも運び、その意味はそれを割り当てたルーターに限定されます。別の PE が無関係な宛先に同じ番号を割り当てることもあります。まさにそのため、ラベルは顧客の識別の代わりにはなりません。番号は次ホップとそれをインストールした転送状態の隣でのみ正しいのです。

割り当ての粒度は実装と設計によって変わります。VRF ごとに一つのラベルを割り当てるプラットフォームもあれば、プレフィックスごとのものもあり、ラベルは顧客ではなく転送アクションを識別することがあります。同じ宛先に届く二つの異なるラベルは矛盾ではなく、二つの PE で同じラベル番号であっても矛盾ではありません。

一方が他方を置き換えられない理由

広告を読むとは、四つのものを同時に見ることです。RD で修飾されたプレフィックス、ルートターゲット、次ホップ、そしてラベルです。ユーザーパケットを読むとは、その情報からインストールされたスタックを見ることです。健全な設計では両側が一致し、壊れた設計では通常、片側が正しくもう片側が古くなっています。その比較が、識別の問題と転送の問題を切り分けます。

制御プレーンとデータプレーンの整った対比は教材であって、符号化の記述ではありません。 RFC 8277ラベルをラベル付き NLRI の内側に置くため、広告自体がバインディングを運びます。それを転送に使うのは後の別の手順です。

テナントのルートが消えたら、この順に確認します。そのプレフィックスの VPNv4 エントリが二つあるか、それぞれに正しいルートターゲットがあるか、次ホップが解決できるか、受信側 PE が状態を持つラベルがあるかです。識別を転送値で直す、あるいはその逆は、一つの確認を通り次の確認で失敗します。