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

MPLS VPNのRT(Route Target)

目次

MPLS VPNのRTとは

RT(Route Target)は、経路に付ける印で、その経路をどのVRFへ取り込むかを決める値です。MPLS VPNで「どの拠点とどの拠点がつながるか」を決めているのはRTです。

RFC 4364の4.3.1は次のように述べています。

Any route associated with Route Target T must be distributed to every PE router that has a VRF associated with Route Target T.

PEは経路をMP-BGPへ載せるときにRTを付けて送り(export)、受け取ったPEは自分のVRFに設定されたRTと見比べて、一致するものだけをVRFへ入れます(import)。一致しない経路は、届いていてもVRFには入りません

exportとimportは別物

RTの設定は送信側のexportと受信側のimportに分かれていて、それぞれ独立しています。同じ値を書くのが普通ですが、そうしなければならない決まりはありません。

設定いつ効くか効果
export route-target経路をMP-BGPへ載せるときその経路にRTを付ける
import route-targetMP-BGPから経路を受け取ったとき一致するRTを持つ経路をVRFへ入れる

両者が独立しているため、片方だけを変えても結果は同じになります。受信側のimportを消しても、送信側のexportを別の値にしても、一致しなくなるという点では変わりません。この対称性は後半のラボのSTEP 1とSTEP 2で確かめます。

1つの経路に複数のRTを付けられます。また、1つのVRFが複数のRTをimportできます。ハブアンドスポークやエクストラネットは、この組み合わせで作ります(設計はMPLS VPNのRTによる経路制御で扱います)。

RDとRTの違い

RDとRTは表記が同じ<AS番号>:<番号>なので混同されがちですが、役割はまったく違います。

RDRT
何をするかプレフィックスを一意にする配布先を決める
どこに入るかNLRI(プレフィックスの一部)拡張コミュニティ(パス属性)
大きさ8バイト8バイト
VRFとの関係VRFごとに1つVRFごとにimport・exportを複数

RFC 4364の4.1は、RDについて「経路の出自も配布先も示さない」と明記しています。配布を決めているのはRTだけです(RDについてはMPLS VPNのRDで解説しています)。

RTはBGPの拡張コミュニティ(Extended Community)として運ばれます。8バイトの構造やType値そのものはBGPの拡張コミュニティ(Extended Community)で解説しています。

IOS XRでのRTの設定

IOS XRではRTをVRFの定義側vrf <名前>)に設定します。RDがrouter bgpの配下だったのとは置き場所が違います。

RTの設定(IOS XR)
vrf CUST-A
 address-family ipv4 unicast
  import route-target
   65001:100
  !
  export route-target
   65001:100
  !
 !
!

複数のRTを扱うときは、import route-targetexport route-targetの配下に値を並べます。

1つのVRFで2つのRTをexportする
vrf CUST-A
 address-family ipv4 unicast
  export route-target
   65001:100
   65001:300
  !
 !
!

検証構成

XRd 8台で、顧客Aと顧客Bがまったく同じアドレスを使う環境を作ります。RTの効果は「顧客をまたいで漏れるか、漏れないか」で現れるためです。

ノード役割
PE1 / PE2VRF CUST-A(RD 65001:1、RT 65001:100)とCUST-B(RD 65001:2、RT 65001:200)を持つ。CE向けのインタフェースは顧客ごとに分け、どちらにも同じ172.16.1.1(PE2は172.16.2.1)を設定している
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

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

STEP操作確かめること
0初期状態経路にRT 65001:100が付いている。顧客A・Bとも疎通する
1PE2のCUST-Aのimport route-targetを削除届いているのにVRFに入らない。顧客Aの疎通が落ちる
2importを戻し、PE1のCUST-Aのexportを65001:199に変更今度も入らない。送信側を変えても結果は同じ
3exportを戻し、2つ目のRT 65001:300を追加1経路に2つのRTが付く。疎通は変わらない
4PE2のCUST-Bが65001:300もimport顧客Bが顧客Aの経路を取り込む
5STEP 0の設定に戻す漏れが止まる

RTが一致する経路だけがVRFに入る(STEP 0〜2)

STEP 0では、PE2はPE1から受け取った10.1.1.0/24をCUST-Aに取り込んでいます。

STEP 0 PE2 の show bgp vpnv4 unicast rd 65001:1 10.1.1.0/24
RP/0/RP0/CPU0:PE2#show bgp vpnv4 unicast rd 65001:1 10.1.1.0/24
Mon Sep 21 09:11:04.781 UTC
BGP routing table entry for 10.1.1.0/24, Route Distinguisher: 65001:1
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 19           19
Last Modified: Sep 21 09:03:19.023 for 00:07:45
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local, (received & used)
    1.1.1.1 (metric 4) from 1.1.1.1 (1.1.1.1)
      Received Label 24005 
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 19
      Extended community: RT:65001:100 
      Source AFI: VPNv4 Unicast, Source VRF: CUST-A, Source Route Distinguisher: 65001:1

Extended community: RT:65001:100が経路に付いているRTです。(received & used)importedは、受け取って使っている状態を示します。

プレフィックスを指定するときはrd <RD> <プレフィックス>の形にしますshow bgp vpnv4 unicast 10.1.1.0/24ではVPN-IPv4アドレスを特定できず、%% Network not in tableになります。

STEP 1でPE2のCUST-Aからimport route-targetを削除すると、同じコマンドの出力が次のように変わります。

STEP 1 PE2(importを削除したあと)
Paths: (1 available, no best path)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local, (received-only)
    1.1.1.1 (metric 4) from 1.1.1.1 (1.1.1.1)
      Received Label 24005 
      Origin incomplete, metric 0, localpref 100, valid, internal, import-candidate, imported, not-in-vrf
      Received Path ID 0, Local Path ID 0, version 0
      Extended community: RT:65001:100 
      Source AFI: VPNv4 Unicast, Source VRF: CUST-A, Source Route Distinguisher: 65001:1

経路そのものは届いています。ラベルもRTも変わらず、validのままです。変わったのは(received-only)not-in-vrf、そしてno best pathの3点で、VRFに入らなかったことを示しています。

受信側の一覧でも同じことが読めます。CUST-A(RD 65001:1)の行だけが* i(有効だがベストでない)で、CUST-B(RD 65001:2)の行は*>iのままです。

STEP 1 PE2 の show bgp vpnv4 unicast neighbors 1.1.1.1 received routes(抜粋)
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 20
* i10.1.1.0/24        1.1.1.1                  0    100      0 ?
Route Distinguisher: 65001:2 (default for vrf CUST-B)
Route Distinguisher Version: 17
*>i10.1.1.0/24        1.1.1.1                  0    100      0 ?

Processed 2 prefixes, 2 paths

VRFに入らなければ転送もできません。顧客Aの疎通は落ち、顧客Bは影響を受けません。

STEP 1 CE-A2 から顧客Aの別拠点への疎通
RP/0/RP0/CPU0:CE-A2#ping 10.1.1.1 source 10.1.2.1 count 50 timeout 1
Mon Sep 21 09:19:03.753 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.1.1.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)

STEP 2ではimportを戻し、代わりにPE1のCUST-Aのexportを65001:199に変えます。変えたのは送信側だけですが、結果は同じです。

STEP 2 PE2(送信側のexportを変えたあと)
Paths: (1 available, no best path)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local, (received-only)
    1.1.1.1 (metric 4) from 1.1.1.1 (1.1.1.1)
      Received Label 24005 
      Origin incomplete, metric 0, localpref 100, valid, internal, import-candidate, not-in-vrf
      Received Path ID 0, Local Path ID 0, version 0
      Extended community: RT:65001:199 

RTが65001:199になり、PE2のimport(65001:100)と一致しません。パケットの中でも同じ値が運ばれています。PE1がexportを変えた直後に送り直したUPDATEが、添付のSTEP 2のキャプチャーのNo.9にあたります。

STEP 2 No.9 UPDATE(PE1 → PE2)tshark -V
        Path Attribute - EXTENDED_COMMUNITIES
            Flags: 0xc0, Optional, Transitive, Complete
                1... .... = Optional: Set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: EXTENDED_COMMUNITIES (16)
            Length: 8
            Carried extended communities: (1 community)
                Route Target: 65001:199 [Transitive 2-Octet AS-Specific]
                    Type: Transitive 2-Octet AS-Specific (0x00)
                        0... .... = IANA Authority: Allocated on First Come First Serve Basis
                        .0.. .... = Transitive across ASes: Transitive
                    Subtype (AS2): Route Target (0x02)
                    2-Octet AS: 65001
                    4-Octet AN: 199
上のtshark出力のパケット(No.9 UPDATE)のpcapをダウンロード

1経路に複数のRTを付けられる(STEP 3)

STEP 3でexportを65001:100に戻し、2つ目のRT 65001:300を足します。

STEP 3 PE2 の show bgp vpnv4 unicast rd 65001:1 10.1.1.0/24(抜粋)
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local, (received & used)
    1.1.1.1 (metric 4) from 1.1.1.1 (1.1.1.1)
      Received Label 24005 
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 24
      Extended community: RT:65001:100 RT:65001:300 
      Source AFI: VPNv4 Unicast, Source VRF: CUST-A, Source Route Distinguisher: 65001:1

RT:65001:100 RT:65001:300と2つ並びました。65001:100が残っているので、CUST-Aの取り込みは変わりません。CE-A2からの疎通も100パーセントのままです。

拡張コミュニティは1つ8バイトで、属性の中に並べて運ばれます。添付のSTEP 3のキャプチャーのNo.4が、このときPE1が送り直したUPDATEです。

STEP 3 No.4 UPDATE(PE1 → PE2)tshark -V
        Path Attribute - EXTENDED_COMMUNITIES
            Flags: 0xc0, Optional, Transitive, Complete
                1... .... = Optional: Set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: EXTENDED_COMMUNITIES (16)
            Length: 16
            Carried extended communities: (2 communities)
                Route Target: 65001:100 [Transitive 2-Octet AS-Specific]
                    Type: Transitive 2-Octet AS-Specific (0x00)
                        0... .... = IANA Authority: Allocated on First Come First Serve Basis
                        .0.. .... = Transitive across ASes: Transitive
                    Subtype (AS2): Route Target (0x02)
                    2-Octet AS: 65001
                    4-Octet AN: 100
                Route Target: 65001:300 [Transitive 2-Octet AS-Specific]
                    Type: Transitive 2-Octet AS-Specific (0x00)
                        0... .... = IANA Authority: Allocated on First Come First Serve Basis
                        .0.. .... = Transitive across ASes: Transitive
                    Subtype (AS2): Route Target (0x02)
                    2-Octet AS: 65001
                    4-Octet AN: 300
上のtshark出力のパケット(No.4 UPDATE)のpcapをダウンロード

Lengthが8から16へ増えています。RTを1つ足すと属性が8バイト伸びる、という関係がそのまま出ています。

RTを足すと別の顧客のVRFに入る(STEP 4〜5)

STEP 4でPE2のCUST-Bに65001:300のimportを足すと、顧客Aの経路が顧客BのVRFに入ります

この構成では顧客Aと顧客Bが同じ10.1.1.0/24を使っているため、show route vrf CUST-Bでは区別がつきません。漏れが現れるのはBGPテーブルのパス数です。

PE2 の show bgp vrf CUST-B(抜粋)
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:2 (default for vrf CUST-B)
Route Distinguisher Version: 17
*>i10.1.1.0/24        1.1.1.1                  0    100      0 ?
*> 10.1.2.0/24        172.16.2.2               0         32768 ?

Processed 2 prefixes, 2 paths
PE2 の show bgp vrf CUST-B(抜粋)
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:2 (default for vrf CUST-B)
Route Distinguisher Version: 25
*>i10.1.1.0/24        1.1.1.1                  0    100      0 ?
* i                   1.1.1.1                  0    100      0 ?
*> 10.1.2.0/24        172.16.2.2               0         32768 ?

Processed 2 prefixes, 3 paths
PE2 の show bgp vrf CUST-B(抜粋)
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:2 (default for vrf CUST-B)
Route Distinguisher Version: 27
*>i10.1.1.0/24        1.1.1.1                  0    100      0 ?
*> 10.1.2.0/24        172.16.2.2               0         32768 ?

Processed 2 prefixes, 2 paths

STEP 4だけ10.1.1.0/24に2行目(Network欄が空の* i)が現れ、Processed 2 prefixes, 3 pathsとパスが1本増えています。増えた1本が、RT 65001:300で取り込まれた顧客Aの経路です。CUST-BのimportにはSTEP 4だけ2つのRTが入っています。

STEP 4 PE2 の show vrf all detail(CUST-Bの部分)
  Import VPN route-target communities:
    RT:65001:200
    RT:65001:300

STEP 5でこのimportを外すと2パスに戻り、漏れが止まります。顧客をまたいで経路が入るかどうかは、RTの組み合わせだけで決まります。RDは最初から最後まで65001:165001:2のままで、一度も変えていません。

参考

規格タイトルこの記事で参照した箇所
RFC 4364BGP/MPLS IP Virtual Private Networks (VPNs)4.1(RDは配布先を示さない)、4.3(VRFのimport / export)、4.3.1(RTが一致するPEへ配布される)
RFC 4360BGP Extended Communities Attribute拡張コミュニティ(Type 16)として運ばれること

書籍: 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)

検証Configおよびshow結果

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

ファイル内容
..._show.txtshow version / show vrf all detail / show bgp vpnv4 unicast / show bgp vpnv4 unicast rd <RD> <プレフィックス> / 3点セット(advertised-routes / routes / received routes)/ show route vrf / show cef vrf / show mpls forwarding など
..._log.txtそのSTEPの範囲だけに絞ったshow logging。各STEPの開始時にlogmsgでマーカーを入れ、その時刻をshow logging startに指定して取得したもの
..._run.txtそのSTEP時点のshow running-config(=そのSTEPの検証Config)
..._ping.txtそのSTEPのpingtraceroute
..._commit.cfgそのSTEPで実際にcommitされた設定だけ。設定を変えたルータの分のみ

最終状態(STEP 5)はSTEP 0と同じ設定に戻しています。

STEP 0:初期状態

ルータshow出力syslogrunning-configping投入した設定
PE1showlogrunping-
PE2showlogrunping-
P1showlogrunping-
P2showlogrunping-
CE-A1showlogrunping-
CE-A2showlogrunping-
CE-B1showlogrunping-
CE-B2showlogrunping-

STEP 1:PE2のCUST-Aのimport route-targetを削除

ルータshow出力syslogrunning-configping投入した設定
PE1showlogrunping-
PE2showlogrunpingcommit
P1showlogrunping-
P2showlogrunping-
CE-A1showlogrunping-
CE-A2showlogrunping-
CE-B1showlogrunping-
CE-B2showlogrunping-

STEP 2:importを戻し、PE1のCUST-Aのexportを65001:199に変更

ルータshow出力syslogrunning-configping投入した設定
PE1showlogrunpingcommit
PE2showlogrunpingcommit
P1showlogrunping-
P2showlogrunping-
CE-A1showlogrunping-
CE-A2showlogrunping-
CE-B1showlogrunping-
CE-B2showlogrunping-

STEP 3:exportを戻し、2つ目のRT 65001:300を追加

ルータshow出力syslogrunning-configping投入した設定
PE1showlogrunpingcommit
PE2showlogrunping-
P1showlogrunping-
P2showlogrunping-
CE-A1showlogrunping-
CE-A2showlogrunping-
CE-B1showlogrunping-
CE-B2showlogrunping-

STEP 4:PE2のCUST-Bが65001:300もimport

ルータshow出力syslogrunning-configping投入した設定
PE1showlogrunping-
PE2showlogrunpingcommit
P1showlogrunping-
P2showlogrunping-
CE-A1showlogrunping-
CE-A2showlogrunping-
CE-B1showlogrunping-
CE-B2showlogrunping-

STEP 5:STEP 0の設定に戻す(最終状態)

ルータshow出力syslogrunning-configping投入した設定
PE1showlogrunpingcommit
PE2showlogrunpingcommit
P1showlogrunping-
P2showlogrunping-
CE-A1showlogrunping-
CE-A2showlogrunping-
CE-B1showlogrunping-
CE-B2showlogrunping-
パケットキャプチャーはSTEPごとに取得しています。
STEPPE1-P1間
0pcap
1pcap
2pcap
3pcap
4pcap
5pcap

関連記事