MPLS VPN における RD と RT: 一意性とインポートポリシー

二つの顧客サイトが 10.20.0.0/24 を広告しても、両方とも一つのプロバイダーネットワーク内で有効なままです。ルート識別子はそれらの広告を別個に保ち、ルートターゲットはどの顧客 VRF がコピーを受け取れるかを決めます。両者は設定の中で隣り合って現れ、まったく別の役割を担います。この二つを混同すると、もっともらしく見えて何も直らない変更につながります。

顧客エッジから遠隔の VRF まで一本のルートをたどってください こうして分担は具体的になり、識別情報はルートが BGP に入る前に付与され、配布ポリシーはルートが受け側のプロバイダーエッジに届いた時点で評価されます。

VPN-IPv4 ルートは RD と IPv4 プレフィックスの組み合わせです

RFC 4364 は VPN-IPv4 アドレスファミリーを、八バイトのルート識別子とそれに続く四バイトの IPv4 アドレスとして定義しています。RD は顧客プレフィックスの前に付くため、異なるサイトからの同一プレフィックスは二つの異なる BGP ルートになります。

この構造が一意性の仕組みそのものです。プロバイダーは顧客に重複しないアドレス空間の合意を求める必要がなく、あるサイトのルートが別サイトの同一プレフィックスを黙って置き換えることもありません。

RD の形式自体は管理者が選ぶ値で、通常は自律システム番号とローカル番号です。その数値的な形は慣習にすぎず、たまたま同じ数字を使うルートターゲットと二つのフィールドが意味を共有する証拠ではありません。

RD は重複するプレフィックスを区別可能にします

同じプレフィックスに対する二つの広告を考えます。サイト A は RD 65000:101 を、サイト B は RD 65000:202 を持ち、どちらも 10.20.0.0/24 向けです。BGP は独立に比較し、絞り込み、選択できる二つの VPN-IPv4 ルートを持つことになります。

RD はどちらのルートをどの VRF が受け取るべきかを示すものではなく、顧客やサービスを識別するものでもありません。ルートの識別フィールドであって、所属リストではありません。VRF 自身の RD は、それがインポートするルートの RD と一致する必要はありません。

だからこそ、別サイトの番号に合わせて RD を変えても何も直りません。反対側でルートが欠けている場合、数字を合わせるとインポートの判断を修復するのではなく、別の識別問題を生むだけです。

RT は BGP の属性であり、パケットのタグではありません

エクスポートポリシーは一つ以上のルートターゲットを BGP 拡張コミュニティ属性としてルートに付与します。受け側のプロバイダーエッジは、それらの属性を各 VRF のインポートポリシーと照合します。RT はコントロールプレーンを通じてルートとともに運ばれます。照合はルーティングポリシーの中だけで、顧客パケットが転送される前に起こります。

顧客のデータパケットは RT を運びません。ルートが VRF にインストールされると、転送はその VRF のテーブルと、アーキテクチャが割り当てる MPLS ラベルスタックを使います。プロバイダーエッジが顧客パケットごとにルートターゲットを読むことはありません。

ルートは複数の RT を持て、VRF は複数をインポートできます。設定はしばしば短いブロックのように見えます:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

そのブロックは二つの独立した文として読んでください。エクスポート行はこの VRF を出るルートに何を付与するかを、インポート行はこの VRF が何を検討するかを制御します。番号が一致していると便利ですが、必須ではありません。

インポートの資格はインストールではありません

ルートは VRF にとって資格があっても、その転送テーブルに現れないことがあります。資格はフィルターであり、その後に通常の BGP の決定プロセスが資格のあるルートを比較して一つを選びます。古い、あるいは優先度の低いルートは別の資格ある経路に負けることがあります。

選ばれたルートを確認し、インポートポリシーだけで判断しないでください。RT 65000:500 をインポートし 10.20.0.0/24 のルートを表示しない VRF は、ルートを受け取って選択時に拒否したか、まったく受け取っていない可能性があります。

この区別は、予期しないプレフィックスが現れたときにも重要です。広すぎるインポートポリシーはサイトが使うつもりのないルートまで引き込みますが、RD の一意性はそれを防ぎません。配布範囲は RT ポリシーの問題です。

欠けているルートをコントロールプレーンの順序で追跡します

広告から始めてください。起点の VRF が意図した RT をエクスポートしているか、ルートがルートリフレクターまたは受け側 PE に VPN-IPv4 ルートとして存在するかを確かめ、次に、送信側の設定ではなく受け取ったままの属性を確認します。

次に、受け側 VRF のインポートリストとルートの実際の RT 値を比べます。最後に、その VRF で選択されたルートとラベル結合を調べます。各手順は異なる問いに答えるもので、RD へ飛ぶと通常は間違っている手順を飛ばしてしまいます。

動作しているサイトと失敗しているサイトについて、RD、エクスポートされた RT、インポートされた RT、選択されたネクストホップを記録します。四つの値を並べると、漠然とした「VPN がルートを渡していない」が、実際に異なるコントロールプレーンの手順へと変わります。