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

MPLS VPNのPE-CEルーティング（eBGP）

目次

MPLS VPNのPE-CEルーティング（eBGP）とは

PEとCEの間でeBGPを張り、CEが自分のサイトのプレフィックスを広告する形です。RFC 4364の7がPEがCEから経路を学ぶ方法の1つとして挙げています。

PE側の設定は、VRFの下にネイバーを置くだけです。

PEの設定（IOS XR）
router bgp 65001
 vrf CUST-A
  rd 65001:1
  address-family ipv4 unicast
   redistribute connected
  !
  neighbor 172.16.2.2
   remote-as 65102
   address-family ipv4 unicast
    route-policy PASS-CE2 in
    route-policy PASS-CE2 out
    soft-reconfiguration inbound always
   !
  !
 !
!

CEから受けた経路にredistributeは要りません。 VRFのBGPテーブルに入った時点でVPNv4として他のPEへ運ばれます。redistribute connectedが要るのはPE-CE区間のサブネットで、これはCEが広告するものではなくプロバイダ側で出すためです。

IOS XRはeBGPネイバーにルートポリシーを必須とします。何も当てないと経路が出入りしないので、素通しのPASS-*を置きます。ポリシー名はネイバーごとに変えます（同じ名前を複数のeBGPネイバーに当てると1つのupdate-groupにまとめられ、advertised-routesが読めなくなるため）。

CE側はふつうのeBGPルータで、MPLSもVRFも知りません。

CEの設定（IOS XR）
router bgp 65102
 bgp router-id 12.12.12.12
 address-family ipv4 unicast
  network 10.1.2.0/24
  network 10.1.100.0/24
 !
 neighbor 172.16.2.1
  remote-as 65001
  address-family ipv4 unicast
   route-policy PASS-PE2 in
   route-policy PASS-PE2 out
  !
 !
!

スタティックとの違いは冗長構成と属性

項目スタティックeBGP
到達性の検知無い。CEが落ちてもPEは広告を続けるある。セッションが切れれば経路も消える
同じ経路を複数拠点から出すできない（PEが先に選べない）できる。BGPのベストパス選択で1つに決まる
経路の制御PEの設定を変えるしかないCE側から属性で伝えられる
サイトの経路が増えたときPEの設定を足すCEが広告するだけ

とくに3つ目が大きく、顧客が自分でトラフィックの寄せ先を決められます。プロバイダに設定変更を依頼する必要がありません。

MEDで顧客側から寄せ先を決める

MEDは、自分のASへ入ってくるトラフィックにどの入口を使ってほしいかを、隣のASへ伝える属性です。値が小さいほうが優先されます。

複数の拠点から同じプレフィックスを広告しておき、優先したい拠点のMEDを小さくすれば、そちらへ寄せられます。

CE2がMEDを付けて広告する（IOS XR）
route-policy MED-200
  set med 200
  pass
end-policy
!
router bgp 65102
 neighbor 172.16.2.1
  address-family ipv4 unicast
   route-policy MED-200 out
  !
 !
!

MEDは隣接ASが同じ経路どうしでしか比較されません。 そのため、同じプレフィックスを出す拠点は同じAS番号でなければ比較の対象になりません。顧客が全拠点で同じAS番号を使うのは実運用でも普通です。

なお同じAS番号を複数の拠点で使うと、拠点どうしの経路がASループとして落ちるという別の問題が起きます。これはMPLS VPNで複数拠点が同じAS番号を使う場合で解説しています。

ベストパス選択の順序を押さえておく

どちらの拠点が選ばれるかは、BGPのベストパス選択で決まります。この記事に関係するのは次の段です（順序の番号はBGPパス属性とベストパス選択の表に合わせています。1・3はWEIGHTと自身が生成した経路で、この構成では差が付きません）。

順序判断基準この記事での役割
2LOCAL_PREF全STEPで同じ（100）
4AS_PATHの長さ全STEPで同じ（65102の1つ）
5ORIGIN全STEPで同じ（IGP）
6MULTI_EXIT_DISC（MED）顧客側が動かす値
7eBGPとiBGPeBGPで学習した経路を優先。MEDより後である点が後で効く
8NEXT_HOPまでのIGPメトリックMEDが同じときの決め手

6番目のMEDが7番目のeBGP優先より前にあることが、後で見る「負けた側のPEが自分の経路を広告しなくなる」挙動につながります。

検証構成

XRd 7台で顧客Aの3拠点を作り、拠点2と拠点3から同じ10.1.100.0/24を広告します。

ノードAS広告する経路
CE16510110.1.1.0/24（観測側）
CE26510210.1.2.0/24 ＋ 10.1.100.0/24
CE36510210.1.3.0/24 ＋ 10.1.100.0/24（CE2と同じアドレス10.1.100.1）

PE3側のコアリンクだけOSPFコストを10にしてあるので、同点ならPE2側が選ばれます。確認はCE1からのtracerouteで、最終ホップが172.16.2.2（CE2）か172.16.3.2（CE3）かで寄せ先が分かります。

STEP 1〜3で触るのはCE側だけです。PEの設定は一度も変えません。

STEP操作確かめること
0初期状態（MEDなし）2パス届く。同点なので次ホップまでのIGPメトリックでPE2側
1CE2がMED 200、CE3がMED 100PE3側へ寄る
2CE2をMED 50に変更PE2側へ戻る
3両CEのMEDを外すSTEP 0の状態に戻る
4PE2-CE2のリンクを両端shutdownセッションが切れて自動でPE3側へ
5復旧（最終状態）PE2側に戻る

STEP 0：同点なら次ホップまでのIGPメトリック

PE1には2つのパスが届いています。

PE1：10.1.100.0/24 の2つのパス（STEP 0）
RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast rd 65001:1 10.1.100.0/24
Sun Oct  4 05:40:43.568 UTC
BGP routing table entry for 10.1.100.0/24, Route Distinguisher: 65001:1
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 17           17
Last Modified: Oct  4 05:38:43.023 for 00:02:00
Paths: (2 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65102, (received & used)
    2.2.2.2 (metric 3) from 2.2.2.2 (2.2.2.2)
      Received Label 24006 
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 17
      Extended community: RT:65001:100 
      Source AFI: VPNv4 Unicast, Source VRF: CUST-A, Source Route Distinguisher: 65001:1
  Path #2: Received by speaker 0
  Not advertised to any peer
  65102, (received & used)
    4.4.4.4 (metric 12) from 4.4.4.4 (4.4.4.4)
      Received Label 24006 
      Origin IGP, metric 0, localpref 100, valid, internal, import-candidate, imported
      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

LOCAL_PREF（100）もAS_PATH（65102）もMED（metric 0）も同じで、差が出たのは次ホップまでのIGPメトリックです。2.2.2.2が3、4.4.4.4が12なので、PE2側がbestになっています。

トラフィックも拠点2へ向かいます。

CE1 → 10.1.100.1 のtraceroute（STEP 0）
RP/0/RP0/CPU0:CE1#traceroute 10.1.100.1 source 10.1.1.1 timeout 1 probe 2 maxttl 6
Sun Oct  4 05:39:52.396 UTC

Type escape sequence to abort.
Tracing the route to 10.1.100.1

 1  172.16.1.1 7 msec  4 msec 
 2  10.0.13.3 [MPLS: Labels 24002/24006 Exp 0] 14 msec  12 msec 
 3  10.0.23.2 [MPLS: Label 24006 Exp 0] 15 msec  13 msec 
 4  172.16.2.2 24 msec  *

STEP 1・2：CE側のMEDだけで寄せ先が変わる

CE2にset med 200、CE3にset med 100を入れます。入れるのはCEだけです。

CE2に投入した設定（STEP 1）
route-policy MED-200
  set med 200
  pass
end-policy
!
router bgp 65102
 neighbor 172.16.2.1
  address-family ipv4 unicast
   route-policy MED-200 out
  !
 !
!
end

MEDが小さいCE3側が選ばれます。

CE1 → 10.1.100.1（STEP 1）
RP/0/RP0/CPU0:CE1#traceroute 10.1.100.1 source 10.1.1.1 timeout 1 probe 2 maxttl 6
Sun Oct  4 05:45:17.767 UTC

Type escape sequence to abort.
Tracing the route to 10.1.100.1

 1  172.16.1.1 6 msec  4 msec 
 2  10.0.13.3 [MPLS: Labels 24001/24006 Exp 0] 19 msec  12 msec 
 3  10.0.34.4 [MPLS: Label 24006 Exp 0] 13 msec  11 msec 
 4  172.16.3.2 21 msec  *
CE1 → 10.1.100.1（STEP 2）
RP/0/RP0/CPU0:CE1#traceroute 10.1.100.1 source 10.1.1.1 timeout 1 probe 2 maxttl 6
Sun Oct  4 05:50:39.791 UTC

Type escape sequence to abort.
Tracing the route to 10.1.100.1

 1  172.16.1.1 6 msec  4 msec 
 2  10.0.13.3 [MPLS: Labels 24002/24006 Exp 0] 15 msec  14 msec 
 3  10.0.23.2 [MPLS: Label 24006 Exp 0] 16 msec  12 msec 
 4  172.16.2.2 15 msec  *

STEP 2でCE2が自分のMEDを50に下げると、今度は拠点2へ戻ります。プロバイダ側の設定は一行も変えていません。 スタティックでは、この操作はPEの設定変更なしには実現できません。

選ばれなかった側のパスは、PE1から消える

ここで、STEP 1のPE1をもう一度見ます。

PE1：10.1.100.0/24（STEP 1）
RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast rd 65001:1 10.1.100.0/24
Sun Oct  4 05:46:11.165 UTC
BGP routing table entry for 10.1.100.0/24, Route Distinguisher: 65001:1
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 23           23
Last Modified: Oct  4 05:43:45.023 for 00:02:26
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65102, (received & used)
    4.4.4.4 (metric 12) from 4.4.4.4 (4.4.4.4)
      Received Label 24006 
      Origin IGP, metric 100, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 23
      Extended community: RT:65001:100 
      Source AFI: VPNv4 Unicast, Source VRF: CUST-A, Source Route Distinguisher: 65001:1

パスが1つしかありません。 STEP 0では2つあったのに、MEDに差を付けた途端に減っています。理由は負けた側のPE2にあります。

PE2：10.1.100.0/24（STEP 1）
RP/0/RP0/CPU0:PE2#show bgp vrf CUST-A 10.1.100.0/24
Sun Oct  4 05:46:46.335 UTC
BGP routing table entry for 10.1.100.0/24, Route Distinguisher: 65001:1
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 25           25
Last Modified: Oct  4 05:43:45.023 for 00:03:01
Paths: (3 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65102, (received & used)
    4.4.4.4 (metric 12) from 4.4.4.4 (4.4.4.4)
      Received Label 24006 
      Origin IGP, metric 100, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 25
      Extended community: RT:65001:100 
      Source AFI: VPNv4 Unicast, Source VRF: CUST-A, Source Route Distinguisher: 65001:1
  Path #2: Received by speaker 0
  Not advertised to any peer
  65102
    172.16.2.2 from 172.16.2.2 (12.12.12.12)
      Origin IGP, metric 200, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Extended community: RT:65001:100 
      Origin-AS validity: (disabled)

PE2は10.1.100.0/24について、CE2から受けたMED 200の経路と、PE3から来たMED 100の経路の両方を持っています。そしてベストパスに選んだのはPE3から来たほうです。前半の表のとおり、MEDの比較（6番目）はeBGP優先（7番目）より前にあるためです。

自分のeBGP経路がベストでなくなったPE2は、それを他のPEへ広告しません。出力にもNot advertised to any peerと出ています。

キャプチャーにも同じことが出ています。

PE1-P1間のBGP UPDATE（STEP 1）
$ tshark -r mpls-vpn-pece-bgp-step1-pe1p1.pcap -Y 'bgp.type==2' -T fields \
    -e frame.number -e ip.src \
    -e bgp.update.path_attribute.multi_exit_disc \
    -e bgp.mp_reach_nlri_ipv4_prefix -e bgp.mp_unreach_nlri_ipv4_prefix
11	2.2.2.2	200	10.1.2.0	10.1.100.0
24	4.4.4.4	100	10.1.3.0,10.1.100.0
PE1-P1間のBGP UPDATE（STEP 2）
$ tshark -r mpls-vpn-pece-bgp-step2-pe1p1.pcap -Y 'bgp.type==2' -T fields \
    -e frame.number -e ip.src \
    -e bgp.update.path_attribute.multi_exit_disc \
    -e bgp.mp_reach_nlri_ipv4_prefix -e bgp.mp_unreach_nlri_ipv4_prefix
7	2.2.2.2	50	10.1.2.0,10.1.100.0	
8	4.4.4.4			10.1.100.0

STEP 1では、PE2（2.2.2.2）が自分の10.1.2.0/24をMED 200で広告しながら、10.1.100.0/24は取り消しています。STEP 2では逆に、PE3（4.4.4.4）が10.1.100.0/24を取り消しています。負けたほうが取り消す、という動きです。

取り消しのUPDATEは、添付のSTEP 1のキャプチャーのNo.11です。

PE2 → PE1 のUPDATE（tshark -V、MP_UNREACH_NLRIの部分）
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 45
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 22
    Path attributes
        Path Attribute - MP_UNREACH_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_UNREACH_NLRI (15)
            Length: 18
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
            Withdrawn Routes
                BGP Prefix
                    Prefix Length: 112
                    Label Stack: 0 (withdrawn)
                    Route Distinguisher: 65001:1
                    MP Unreach NLRI IPv4 prefix: 10.1.100.0
上のtshark出力のパケット（No.11 UPDATE、PE2による取り消し）のpcapをダウンロード

バックアップを残すのがBest ExternalとADD-PATH

この挙動は仕様どおりですが、運用上は困ります。PE1はバックアップになるはずのパスを1つも知らないので、拠点3が落ちたときは、PE2が改めて自分の経路をベストにして広告し直すまで切り替われません。

これを解決するのが、非ベストの外部経路も広告するBGP Best Externalと、同じプレフィックスに複数のパスを流すBGPのADD-PATHです。VPNv4での使い方はVPNv4のBest Externalで扱います。

STEP 4：セッションが切れれば自動で切り替わる

PE2-CE2のリンクを両端で落とします（片側だけでは対向のインタフェースがupのままなので、リンク断は両端で作ります）。

PE1：10.1.100.0/24（STEP 4）
RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast rd 65001:1 10.1.100.0/24
Sun Oct  4 06:02:47.965 UTC
BGP routing table entry for 10.1.100.0/24, Route Distinguisher: 65001:1
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 34           34
Last Modified: Oct  4 05:59:53.023 for 00:02:55
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65102, (received & used)
    4.4.4.4 (metric 12) from 4.4.4.4 (4.4.4.4)
      Received Label 24006 
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 34
      Extended community: RT:65001:100 
      Source AFI: VPNv4 Unicast, Source VRF: CUST-A, Source Route Distinguisher: 65001:1

PE2から来ていた経路が消え、残った拠点3のパスがベストになりました。収束を待ってからpingを流すと全通で、拠点3側へ寄って通信が続いています。なおこのpingはリンクを落としてから約100秒後に実行したもので、切り替え中にパケットが落ちるかどうかを測ったものではありません。

CE1 → 10.1.100.1 のping（STEP 4）
RP/0/RP0/CPU0:CE1#ping 10.1.100.1 source 10.1.1.1 count 10 timeout 1
Sun Oct  4 06:01:35.212 UTC
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.100.1 timeout is 1 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 12/17/36 ms

スタティックでは、CEが落ちてもPEは広告を続けてパケットが捨てられるだけでした。eBGPならセッションが切れた時点で経路が消え、もう一方の拠点へ寄ります。これが冗長構成を組めるということです。

STEP 5：復旧

リンクを戻すと、IGPメトリックの近いPE2側が再びベストになり、STEP 0と同じ状態に戻ります。

参考

RFCタイトル参照した節
RFC 4364BGP/MPLS IP Virtual Private Networks (VPNs)7（PEがCEから経路を学ぶ方法）
RFC 4271A Border Gateway Protocol 4 (BGP-4)9.1.2.2（ベストパス選択の順序）、5.1.4（MULTI_EXIT_DISC）

書籍: Luc De Ghein『MPLS Fundamentals』（Cisco Press、2006）7章

検証Configおよびshow結果

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

ファイル内容
..._show.txtそのSTEPでの状態一式。OSPF（show ospf neighbor / show ospf database）、LDP（show mpls ldp neighbor brief / show mpls ldp bindings）、MPLS転送（show mpls forwarding / show mpls label table）、MP-BGP（show bgp vpnv4 unicast / show bgp vpnv4 unicast rd 65001:1 10.1.100.0/24 / show bgp vpnv4 unicast labels）、VRF（show vrf all detail / show route vrf CUST-A / show cef vrf CUST-A）、PE-CE間のeBGP（advertised-routes・routes・received routesの3点セット）。PEは50コマンド、Pは20、CEは16
..._log.txtそのSTEPの範囲だけに絞ったshow logging
..._run.txtそのSTEP時点のshow running-config（＝そのSTEPの検証Config）
..._ping.txtCE間のpingとtraceroute
..._trace.txtPEのshow bgp trace
..._commit.cfgそのSTEPで実際にcommitされた設定（変更したルータの分だけ）

STEP 0：初期状態（MEDなし）

ルータshow出力syslogrunning-configpingtrace投入した設定
CE1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE2showlogrunping--
PE3showlogrunpingtrace-
CE3showlogrunping--

STEP 1：CE2がMED 200、CE3がMED 100

ルータshow出力syslogrunning-configpingtrace投入した設定
CE1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE2showlogrunping-commit
PE3showlogrunpingtrace-
CE3showlogrunping-commit

STEP 2：CE2をMED 50に変更

ルータshow出力syslogrunning-configpingtrace投入した設定
CE1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE2showlogrunping-commit
PE3showlogrunpingtrace-
CE3showlogrunping--

STEP 3：両CEのMEDを外す

ルータshow出力syslogrunning-configpingtrace投入した設定
CE1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE2showlogrunping-commit
PE3showlogrunpingtrace-
CE3showlogrunping-commit

STEP 4：PE2-CE2のリンクを両端shutdown

ルータshow出力syslogrunning-configpingtrace投入した設定
CE1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE2showlogrunping-commit
PE3showlogrunpingtrace-
CE3showlogrunping--

STEP 5：復旧（最終状態）

ルータshow出力syslogrunning-configpingtrace投入した設定
CE1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE2showlogrunping-commit
PE3showlogrunpingtrace-
CE3showlogrunping--

パケットキャプチャーはSTEPごとに取得しています。

STEPPE1-P1間
0pcap
1pcap
2pcap
3pcap
4pcap
5pcap

関連記事