↓ メインコンテンツへスキップ
KAZULOG.INFO
  1. ネットワーク 記事一覧/
  2. MPLS-VPN記事一覧/

MPLS VPNのRD（Route Distinguisher）

目次

MPLS VPNのRDとは

RD（Route Distinguisher）は、IPv4プレフィックスの前に付けて一意にするための8バイトの値です。RFC 4364の4.1が定めるVPN-IPv4アドレスは、8バイトのRDと4バイトのIPv4アドレスを連結した12バイトになります。

RDが必要なのは、顧客ごとにアドレスが重なっていても、BGPの中では別のプレフィックスとして扱う必要があるからです。顧客Aの10.1.1.0/24と顧客Bの10.1.1.0/24は、そのままではBGPにとって同じプレフィックスで、片方しか残りません。RDを付ければ65001:1:10.1.1.0/24と65001:2:10.1.1.0/24になり、共存できます。

RDはVPNの識別子ではありません。RFC 4364の4.1は次のように述べています。

An RD is simply a number, and it does not contain any inherent information; it does not identify the origin of the route or the set of VPNs to which the route is to be distributed. The purpose of the RD is solely to allow one to create distinct routes to a common IPv4 address prefix.

経路をどのVRFへ配るかを決めるのはRT（Route Target）です。この違いは後半のラボで確かめます。RTそのものはMPLS VPNのRTで解説します。

RDの形式（Type 0 / 1 / 2）

RDは2バイトのTypeと6バイトのValueでできています。Typeによって6バイトの区切り方が変わります（RFC 4364の4.2）。

TypeValueの内訳表記の例使いどころ
02バイトのAS番号 + 4バイトの番号65001:12バイトAS番号を持つ事業者。最も一般的
14バイトのIPアドレス + 2バイトの番号1.1.1.1:2ルータのアドレスを使って装置ごとに分けたいとき
24バイトのAS番号 + 2バイトの番号4259905537:14バイトAS番号を持つ事業者

どのTypeを使っても機能は変わりません。RDは値が一意かどうかだけが問題で、中身に意味はありません。RFC 4364の4.2は、この構造によって各事業者が自分の番号空間を他社と衝突せずに管理できる、と説明しています。

IOS XRでのRDの設定

IOS XRではRDをrouter bgpの配下に、VRFごとに設定します。VRFの定義（vrf <名前>）側には書きません。

RDの設定（IOS XR）
router bgp 65001
 vrf CUST-A
  rd 65001:1
  address-family ipv4 unicast
   redistribute static
  !
 !
!

値の指定方法は3通りあります。

書き方意味
rd <AS番号>:<番号>Type 0（または4バイトAS番号ならType 2）
rd <IPアドレス>:<番号>Type 1
rd autoルータIDに0から順の番号を付けて自動採番する

rd autoはルータIDを使うため、同じVPNでもPEごとに違うRDになります。その設計の良し悪しはMPLS VPNのRD設計で扱います。

RDを設定しない限り、そのVRFの経路はMP-BGPに載りません。裏を返すと、VRFを作るだけならRDは要りません（MPLS VPNのVRF）。

RDは後から変更できない

RDは、そのVRFのアドレスファミリーが有効な間は変更も削除もできません。IOS XRは次のように拒否します。

RDを変更しようとしたときのエラー
!!% 'BGP' detected the 'warning' condition 'The RD cannot be changed or removed while a VRF address family is active'

そのため、変更するにはアドレスファミリーをいったん外し、RDを変えてから戻すという手順になります。しかもIOS XRのcommitは擬似アトミックなので、この一連の操作を1回のcommitにまとめることはできません（最終状態でアドレスファミリーが有効と判定され、同じ理由で拒否されます）。2回のcommitに分ける必要があります。

アドレスファミリーを外している間、そのVRFの経路はMP-BGPから消えて通信が止まります。RDは運用開始後に気軽に変えられる値ではなく、設計時に決めておくものです。

検証構成

XRd 8台で、顧客Aと顧客Bがまったく同じアドレスを使う環境を作ります。LANだけでなくPE-CE間のリンクも同じです。

ノード役割
PE1 / PE2VRF CUST-A（RD 65001:1）とCUST-B（RD 65001:2）を持つ。RTはCUST-Aが65001:100、CUST-Bが65001:200
P1 / P2コアのみ（OSPF area 0 + LDP）。BGPを動かさない
CE-A1 / CE-B1サイト1。どちらもLAN 10.1.1.0/24、PEへ172.16.1.2
CE-A2 / CE-B2サイト2。どちらもLAN 10.1.2.0/24、PEへ172.16.2.2

PE-CE間は静的経路で、VRFのBGPにredistribute staticで載せています。RTは最初から最後まで変えません。動かすのはRDだけです。

STEP操作確かめること
0初期状態同じ10.1.1.0/24が2つのRDの下に並ぶ。Pは VPN経路を持たない
1PE1のCUST-BのRDを変更しようとする拒否される
2CUST-Bのアドレスファミリーを外す顧客Bの通信が止まる
3RDをType 1（1.1.1.1:2）にしてアドレスファミリーを戻す通信が回復。RDが違ってもRTが同じなら届く
4もう一度アドレスファミリーを外す（rd autoにするための前提）
5rd autoにするルータID + 0で自動採番される

同じプレフィックスがRDで分かれる（STEP 0）

PE1のBGPテーブルはRDごとに区切られて表示されます。

STEP 0 PE1 の show bgp vpnv4 unicast
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 14
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 65001:2 (default for vrf CUST-B)
Route Distinguisher Version: 15
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?

Processed 4 prefixes, 4 paths

10.1.1.0/24と10.1.2.0/24がそれぞれ2回ずつ現れ、Processed 4 prefixesと数えられています。BGPから見れば4つの別々のプレフィックスで、RDだけが違います。(default for vrf CUST-A)は、そのRDがどのVRFのものかを示す表示です。

コアのPルータはBGPを動かしていません。

STEP 0 P1 で VPNv4 のテーブルを見たところ
RP/0/RP0/CPU0:P1#show bgp vpnv4 unicast
Sun Sep 20 06:27:01.056 UTC
% BGP instance 'default' not active

パケットの中身も確認できます。PE1とP1の間を流れたVPNv4のUPDATEでは、MP_REACH_NLRIの中にRDとラベルが入っています。

STEP 0 の VPNv4 UPDATE（tshark -V の抜粋）
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...1 .... = Extended-Length: Set
                .... 0000 = Unused: 0x0
            Type Code: MP_REACH_NLRI (14)
            Length: 32
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
            Next hop:  RD=0:0 IPv4=2.2.2.2
                Route Distinguisher: 0:0
                IPv4 Address: 2.2.2.2
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                BGP Prefix
                    Prefix Length: 112
                    Label Stack: 24005 (bottom)
                    Route Distinguisher: 65001:1
                    MP Reach NLRI IPv4 prefix: 10.1.2.0
上のtshark出力のパケット（Type 0のRD）のpcapをダウンロード

RDはパス属性ではなくNLRIの一部です。経路の付属情報ではなく、プレフィックスそのものの一部として運ばれます。

変更は拒否され、通信を止めないと変えられない（STEP 1〜2）

STEP 1でPE1のCUST-BのRDを1.1.1.1:2に変えようとすると、commitが失敗します。

STEP 1 show configuration failed の出力
RP/0/RP0/CPU0:PE1(config)#show configuration failed
Sun Sep 20 06:31:37.073 UTC
!! SEMANTIC ERRORS: This configuration was rejected by 
!! the system due to semantic errors. The individual 
!! errors with each failed configuration command can be 
!! found below.


router bgp 65001
 vrf CUST-B
  rd 1.1.1.1:2
!!% 'BGP' detected the 'warning' condition 'The RD cannot be changed or removed while a VRF address family is active'
 !
!
end

STEP 2でアドレスファミリーを外すと、顧客Bの通信が止まります。

STEP 2 CE-B1 から顧客Bの別拠点への疎通
RP/0/RP0/CPU0:CE-B1#ping 10.1.2.1 source 10.1.1.1 count 50 timeout 1
Sun Sep 20 09:06:57.309 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.1.2.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)

このとき顧客Aは影響を受けません。止まるのは操作したVRFだけです。

RDが違ってもRTが同じなら届く（STEP 3）

STEP 3でRDをType 1の1.1.1.1:2にしてアドレスファミリーを戻します。変更したのはPE1のCUST-Bだけで、PE2のCUST-Bは65001:2のままです。

STEP 3 PE1 の BGP テーブル（RD が混在する）
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 14
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 65001:2
Route Distinguisher Version: 18
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 1.1.1.1:2 (default for vrf CUST-B)
Route Distinguisher Version: 20
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?

Processed 5 prefixes, 5 paths

自分が広告する経路は新しいRD（1.1.1.1:2）、PE2から届く経路は元のRD（65001:2）で、同じテーブルに別々のRDとして並びます。それでも顧客Bの通信は回復します。

RDが違っても、RTが同じならVRFに取り込まれるからです。配布先を決めているのはRTであって、RDではありません。冒頭のRFC 4364の記述が、そのまま実機の動作として確認できます。

パケットの中のRDもType 1の表記に変わります。

STEP 3 の VPNv4 UPDATE（tshark -V の抜粋）
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...1 .... = Extended-Length: Set
                .... 0000 = Unused: 0x0
            Type Code: MP_REACH_NLRI (14)
            Length: 32
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
            Next hop:  RD=0:0 IPv4=1.1.1.1
                Route Distinguisher: 0:0
                IPv4 Address: 1.1.1.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                BGP Prefix
                    Prefix Length: 112
                    Label Stack: 24006 (bottom)
                    Route Distinguisher: 1.1.1.1:2
                    MP Reach NLRI IPv4 prefix: 10.1.1.0
上のtshark出力のパケット（Type 1のRD）のpcapをダウンロード

rd autoは「ルータID + 0」から採番する（STEP 5）

STEP 4でもう一度アドレスファミリーを外し、STEP 5でrd autoにします。

STEP 5 PE1 の BGP テーブル
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 14
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 65001:2
Route Distinguisher Version: 18
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 1.1.1.1:0 (default for vrf CUST-B)
Route Distinguisher Version: 25
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?

Processed 5 prefixes, 5 paths

PE1のルータIDは1.1.1.1で、採番は0から始まっています。autoはルータIDを使うため、同じVPNでもPEごとに違うRDになります。

STEP 5 の VPNv4 UPDATE（tshark -V の抜粋）
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...1 .... = Extended-Length: Set
                .... 0000 = Unused: 0x0
            Type Code: MP_REACH_NLRI (14)
            Length: 32
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
            Next hop:  RD=0:0 IPv4=1.1.1.1
                Route Distinguisher: 0:0
                IPv4 Address: 1.1.1.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                BGP Prefix
                    Prefix Length: 112
                    Label Stack: 24006 (bottom)
                    Route Distinguisher: 1.1.1.1:0
                    MP Reach NLRI IPv4 prefix: 10.1.1.0
上のtshark出力のパケット（rd autoのRD）のpcapをダウンロード

VRFごとにRDを揃えるか、PEごとに分けるかは設計の選択です。分けるとルートリフレクタが複数の経路を保持できるようになる一方、保持する経路数が増えます。この判断はMPLS VPNのRD設計で扱います。

検証Configおよびshow結果

各STEPで8台すべてから、次の種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態は最後のSTEPのもの）。

ファイル内容
..._show.txtshow version / show interface description / show route と、PEはVPNv4とVRF、Pはコア、CEは経路表のshow一式
..._ping.txtそのSTEPでのpingとtracerouteの結果
..._log.txtそのSTEPの範囲だけに絞ったshow logging
..._run.txtそのSTEP時点のshow running-config（＝そのSTEPの検証Config）
..._commit.cfgそのSTEPでcommitされた設定（設定を変えたルータの分のみ）
..._failed.cfg拒否された設定とエラー（STEP 1のみ）

STEP 0：初期状態（CUST-A は rd 65001:1、CUST-B は rd 65001:2）

ルータshow出力pingsyslogrunning-config
PE1showpinglogrun
PE2showpinglogrun
P1showpinglogrun
P2showpinglogrun
CE-A1showpinglogrun
CE-A2showpinglogrun
CE-B1showpinglogrun
CE-B2showpinglogrun

STEP 1：RDの変更が拒否される

ルータshow出力pingsyslogrunning-config拒否された設定
PE1showpinglogrunfailed
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

STEP 2：CUST-Bのアドレスファミリーを外す（顧客Bの通信が止まる）

ルータshow出力pingsyslogrunning-config投入した設定
PE1showpinglogruncommit
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

STEP 3：RDをType 1にしてアドレスファミリーを戻す

ルータshow出力pingsyslogrunning-config投入した設定
PE1showpinglogruncommit
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

STEP 4：もう一度アドレスファミリーを外す

ルータshow出力pingsyslogrunning-config投入した設定
PE1showpinglogruncommit
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

STEP 5：rd auto にする（最終状態）

ルータshow出力pingsyslogrunning-config投入した設定
PE1showpinglogruncommit
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

パケットキャプチャーはPE1-P1間で全STEPを通して取得しています。

PE1-P1間のキャプチャー全体をダウンロード

参考

RFCタイトル概要
RFC 4364BGP/MPLS IP Virtual Private Networks (VPNs)VPN-IPv4アドレスとRD（4.1）、RDのType 0 / 1 / 2（4.2）、配布を決めるのはRTであること（4.3.1）
RFC 4760Multiprotocol Extensions for BGP-4VPNv4プレフィックスを運ぶMP_REACH_NLRI

書籍: Luc De Ghein『MPLS Fundamentals』（Cisco Press, 2006）Chapter 7 / Mobeen Tahir ほか『Cisco IOS XR Fundamentals』（Cisco Press, 2009）Chapter 9

検証環境: Cisco IOS XRd 26.1.1（Cisco Modeling Labs）

関連記事