6-2 MPLS L3VPN — 顧客ごとの経路表を 1 つのコアで運ぶ
MPLS 網に顧客ごとの経路表を載せる L3VPN を csr1000v 8 台で扱います。VRF で経路表を分け、RD で prefix を 2 本にし、RT で輸出入を決める流れと、2 段ラベルスタック・as-override・SoO を逐語の show 出力で追います。
1. 前節の振り返りと本節の内容
前節 6-1 MPLS 基礎 では、csr1000v 4 台で組んだ網の上で 1 本の LSP を追いました。ラベルの値は下流の LSR が配ったものを上流がそのまま使うこと、配られた広告を全部持つ LIB と現在使う 1 本だけを持つ LFIB が別物であること、出口の 1 つ手前でラベルが外れること (PHP) を、実機の出力で確かめています。そこで運んでいたのはグローバルな経路表 1 つの宛先で、パケットに乗るラベルは常に 1 枚でした。
本節は、同じ網の上に顧客ごとに分かれた経路表を載せます。6-1 の末尾で挙げた 4 つがそのまま登場します。顧客ごとに経路表を分ける VRF、経路を区別するための RD、どの経路をどの顧客に配るかを決める RT、そして事業者側の PE と顧客側の CE の関係です。6-1 §3.2 で「ラベルは積める」とだけ触れた S ビットも、ここで 2 枚積みの実物になります。
この組み合わせを MPLS L3VPN と呼びます。規格上の名前は BGP/MPLS IP VPNs で、RFC 4364 が定めています。6-1 §1 で見たとおり、MPLS のアーキテクチャを定義した RFC 3031 §2.1 が挙げる 5 つの動機に顧客ごとの経路表は入っていません。L3VPN は別の RFC が定める応用であり、本節はそちらを扱います。
ラボは csr1000v 8 台で、顧客 A と顧客 B が同じアドレス計画を使います。両顧客とも 192.168.10.0/24 と 192.168.20.0/24 を持ち、PE1 との接続にはどちらも 172.30.11.0/30 を、PE2 との接続にはどちらも 172.30.22.0/30 を使います。この重なりを意図的に作ってあるので、「本当に分かれているのか」を出力の見た目ではなく所属で判定することになります。以降の出力・既定値は、すべて次のバージョンでの実測です。
Cisco IOS XE Software, Version 17.03.08a2. VRF — 経路表を分ける
VRF (Virtual Routing and Forwarding) は、1 台のルータの中に独立した経路表を複数持たせる仕組みです。従来の 1 台 1 経路表という前提を外し、インタフェースごとに「どの経路表に属するか」を決めます。あるインタフェースから入ったパケットは、そのインタフェースが属する経路表だけを引きます。
VRF は MPLS が無くても成立します。3-2 ルーティングの基本 の落とし穴で、管理用の Mgmt-vrf に投入した静的ルートがグローバルの show ip route に現れないことを確認しました。あれと同じ分離が、顧客ごとに用意されるのが本節の VRF です。MPLS を伴わずに VRF だけで経路表を分ける構成は VRF Lite と呼ばれます。事業者網を介さないので、分離が届く範囲は VRF を設定した機器と、その間を VLAN などで直接結んだ範囲にとどまります。本節はそこに MPLS と MP-BGP を足して、分かれた経路表を事業者網の向こう側まで運ぶところへ進みます。
VRF の定義はこうなります。
! ===== [PE1] show running-config | section vrf definition CUST-A =====
vrf definition CUST-A
rd 65000:100
!
address-family ipv4
route-target export 65000:100
route-target import 65000:100
exit-address-familyrd と route-target の 2 行が §3 と §4 の主題です。ここではまず、この VRF にインタフェースを入れる側を見ます。
! ===== [PE1] show running-config interface GigabitEthernet3 =====
Building configuration...
Current configuration : 184 bytes
!
interface GigabitEthernet3
description to CE-A1 Gi2 (VRF CUST-A)
vrf forwarding CUST-A
ip address 172.30.11.1 255.255.255.252
negotiation auto
no mop enabled
no mop sysid
endvrf forwarding CUST-A の 1 行で、Gi3 が VRF CUST-A に属します。投入の順序には決まりがあります。 vrf forwarding を後から入れると、IOS-XE は既に付いていた IP アドレスを外します。vrf forwarding → ip address の順に入れる必要があります。本ラボはこの順序で組んでおり、逆順にしたときの表示は検証していません（既に IP を持つインタフェースを VRF へ関連付けると IP が外れること自体は広く知られた挙動ですが、本ラボは逆順を試していないので、そのときの表示は確かめていません）。
もう 1 つ、この設定に書かれていない行が重要です。ip ospf 1 area 0 がありません。6-1 §4.1 では顧客側のインタフェースについて「MPLS には入れないが IGP には入れる」と書きました。あれは VRF が無いときの話です。VRF に入れたインタフェースは、その VRF の経路表に属します。本節が確かめたいのは「グローバルの経路表に顧客網が 1 本も無い」ことなので、PE-CE 間のインタフェースにはグローバルの OSPF プロセスを入れていません。なお OSPF は VRF ごとにプロセスを持てるので、PE-CE を OSPF で組む構成もあります。本ラボは PE-CE を eBGP に統一しており、その構成は検証していません。
3. RD — 同じ prefix を 2 本にする
VRF で経路表を分けても、それだけでは事業者網を越えられません。PE1 の VRF CUST-A にある 192.168.10.0/24 と、VRF CUST-B にある 192.168.10.0/24 を、同じ BGP セッションで PE2 へ運ぼうとすると、IPv4 の世界では、この 2 本が同じ 1 つの宛先として扱われるという壁に当たります。BGP は同じ宛先に複数の経路があればベストパスを 1 本だけ選ぶので、片方の顧客の経路しか運ばれません。
そこで、運ぶときだけ prefix の前に 8 バイトの番号を前置し、12 バイトの別のアドレス族として扱います。この前置きが RD (Route Distinguisher) で、できあがったものを VPNv4 アドレスと呼びます。RFC 4364 が定める構造です。
| 要素 | 長さ |
|---|---|
| RD | 8 バイト |
| IPv4 prefix | 4 バイト |
| VPNv4 アドレス | 12 バイト |
本ラボでは VRF CUST-A に 65000:100、VRF CUST-B に 65000:200 を割り当てています。同じ 192.168.10.0/24 が 65000:100:192.168.10.0/24 と 65000:200:192.168.10.0/24 という別々の名前になり、1 つのテーブルに 2 本のまま並びます。
RD がするのはここまでです。 どの VRF へ入れるかは RD が決めるのではなく、次節の RT が決めます。本ラボは VRF ごとに RD を 1 つ割り当て、PE1 と PE2 で同じ値を使っています。
4. RT — 拡張 community で輸出入を決める
RT (Route Target) は、経路に付いて回るタグです。実体は BGP の拡張 community で、3-8 BGP community 属性 で標準 community (32 ビット) と対比して「64 ビットの拡張 community」として紹介したものと同じ値です。64 ビット = 8 バイトで、§3 の RD と同じ長さになります。
RT は 2 方向の設定を持ちます。
| 設定 | 意味 |
|---|---|
route-target export | この VRF の経路を広告するときに付けるタグ |
route-target import | このタグが付いた経路を、この VRF に取り込む |
§2 で見た vrf definition CUST-A には export と import が両方 65000:100 で入っていました。PE2 側の VRF CUST-A も同じ値を import するので、PE1 が広告した CUST-A の経路が PE2 の CUST-A に入ります。RD と RT は書式が同じ 65000:100 なので混同しやすいのですが、仕事は別です。 RD は運ぶときに一意にするための前置きで、経路の名前の一部になります。RT は経路に付いてくるタグで、入れ先を決めます。
4.1 落ちる場所は「VRF の入口」ではない
3-8 では拡張 community の説明として「VRF ごとに、どの RT を持つ経路を取り込むか (import) を定義する」と書きました。取り込みの判断が RT で決まることはそのとおりです。ただし 経路が落ちる場所は「VRF の入口」ではありません。
RFC 4364 §4.3.2 は、PE ルータは「経路の RT のいずれかと一致する import target を持つ VRF が 1 つも無いなら、その VPN-IPv4 経路を install すべきではない」とし、そうした経路は inbound filtering で捨てるべきだと規定しています。本ラボの PE も、bgp default route-target filter を明示的に設定していない状態でこの絞り込みが効いています（§6.4）。したがって「BGP テーブルには入ったが VRF には入らなかった」という状態にはならず、どの VRF の import RT にも当たらない経路は BGP テーブルからも消えます。§6.4 でこの様子を削除前・削除後の出力で確かめます。
条件は「どの VRF とも一致しない」であることに注意してください。 他の VRF の import RT に当たる経路は、その PE の BGP テーブルには残ります。§10.1 で見る 192.168.30.0/24 がその例で、PE1 は顧客 B の VRF で取り込むので経路自体は持っていますが、顧客 A の表には入りません。
ただし規格は例外を 2 つ挙げています。 経路反射器 (route reflector) と、事業者間 VPN の ASBR です。これらは自分が持つ VRF と一致しない経路も中継のために保持する必要があるので、この絞り込みをしません。実運用の VPNv4 は RR を経由する構成が一般的なので、RR の上で「BGP テーブルから消えたかどうか」を切り分けの材料にすると外します。 本ラボは PE 同士を直接つないだ構成で、RR を置いていません。
RT を運ぶには、VPNv4 のセッションで拡張 community を送る必要があります。本ラボはこの行を明示的に打っていませんが、設定には入っています (§6.3)。
5. ラボ構成
csr1000v を 8 台つなぎます。内訳は事業者網が 3 台 (PE1 / P / PE2)、顧客側が 5 台 (CE-A1 / CE-A1b / CE-A2 / CE-B1 / CE-B2) です。
5.1 6-1 の LER / LSR と、本節の PE / P / CE
6-1 §2.1 では、装置の種別を表す語 (LSR / LER) とその LSP 上での位置を表す語 (ingress / transit / penultimate / egress) を別の軸として整理しました。本節はここに 3 つ目の語彙が加わります。
| 本節の呼び名 | 6-1 での対応 | 役割 |
|---|---|---|
| PE (Provider Edge) | LER | 顧客と接し、VRF を持ち、ラベルを積む |
| P (Provider) | LSR | コアの内側だけを見る。顧客を知らない |
| CE (Customer Edge) | — | 顧客側の機器。MPLS も VRF も持たない |
PE は 6-1 の LER にあたります。 6-1 の言い方では LER は「MPLS 網の縁にいて、IP の世界と接する LSR」なので、P も PE も LSR で、そのうち縁にいるものが LER です。本節の P は縁にいない LSR にあたります。呼び名が変わっただけで、装置の種別としては同じものを指します。そして 6-1 で確認したとおり、位置は装置の属性ではなく LSP ごとに決まります。本節で PE1 → PE2 の向きを追うとき PE2 は egress ですが、逆向きの LSP では PE2 が ingress です。
5.2 意図的に重ねてあるアドレス
このラボは 3 か所でアドレスを重ねています。重ねること自体が教材です。
| # | 重なり | 何を確かめるためか |
|---|---|---|
| 1 | PE1 の Gi3 と Gi4 が同じ 172.30.11.1/30 (PE2 側も VRF CUST-A と CUST-B のインタフェースが同じ 172.30.22.0/30) | VRF が違えば同じアドレスが 1 台に同居できる |
| 2 | CE-A1 と CE-B1 が同じ 192.168.10.1、CE-A2 と CE-B2 が同じ 192.168.20.1 | 同じ宛先が顧客ごとに別の機器を指す |
| 3 | CE-A1 の Gi3 と CE-A1b の Gi3 が同じ LAN 192.168.10.0/24 | 多重接続サイトの実体 |
副作用として、配線の取り違えが show ip interface brief では検出できません。PE1 の Gi3 と Gi4 を入れ違えても出力が同じ文字列になるためです。本ラボでは配線をプロトコルの隣接で照合しました。コアは LDP の discovery、PE-CE は VRF ごとに対向の AS 番号が違うことを使います。
5.3 コアの設定
コアは OSPF area 0 と LDP で、6-1 と同じ構成です。mpls ip を入れたのはコアの 2 本のリンクの両端 4 か所 (PE1 Gi2 / P Gi2・Gi3 / PE2 Gi2) だけです。
! ===== [PE1] show mpls interfaces ===== (mpls ip はコア向け Gi2 だけ)
Interface IP Tunnel BGP Static Operational
GigabitEthernet2 Yes (ldp) No No No Yes PE1 で MPLS が有効なのは Gi2 だけで、VRF に入れた Gi3 と Gi4 は並んでいません。LDP の隣接も、コアの 2 本のリンクにしか張られていません。
! ===== [PE1] show mpls ldp discovery =====
Local LDP Identifier:
1.1.1.1:0
Discovery Sources:
Interfaces:
GigabitEthernet2 (ldp): xmit/recv
LDP Id: 2.2.2.2:0
! ===== [P] show mpls ldp discovery =====
Local LDP Identifier:
2.2.2.2:0
Discovery Sources:
Interfaces:
GigabitEthernet2 (ldp): xmit/recv
LDP Id: 1.1.1.1:0
GigabitEthernet3 (ldp): xmit/recv
LDP Id: 3.3.3.3:0
! ===== [PE2] show mpls ldp discovery =====
Local LDP Identifier:
3.3.3.3:0
Discovery Sources:
Interfaces:
GigabitEthernet2 (ldp): xmit/recv
LDP Id: 2.2.2.2:0PE1 は P とだけ、PE2 も P とだけ隣接しており、P は両方と隣接しています。PE-CE 側へ LDP の discovery が漏れていません。
5.4 BGP の設定
PE1 の BGP はこうなります。
! ===== [PE1] show running-config | section router bgp =====
router bgp 65000
bgp router-id 1.1.1.1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family
!
address-family ipv4 vrf CUST-A
neighbor 172.30.11.2 remote-as 65100
neighbor 172.30.11.2 activate
neighbor 172.30.11.2 as-override
neighbor 172.30.11.2 soo 65000:1
exit-address-family
!
address-family ipv4 vrf CUST-B
neighbor 172.30.11.2 remote-as 65200
neighbor 172.30.11.2 activate
exit-address-family読みどころが 4 つあります。
no bgp default ipv4-unicast— グローバルの IPv4 ユニキャストを既定で有効にしません。PE が扱うのは VPNv4 と、VRF ごとの IPv4 です。address-family vpnv4— PE1 と PE2 のあいだの iBGP で VPNv4 を運びます。update-source Loopback0で、セッションは Loopback0 のアドレス (1.1.1.1 と 3.3.3.3) のあいだに張られます。address-family ipv4 vrf CUST-A/CUST-B— PE-CE 間の eBGP は VRF ごとに定義します。同じ neighbor アドレス 172.30.11.2 が 2 つの VRF に現れています。 顧客 A と顧客 B が同じアドレスを使っているためで、remote-asだけが 65100 と 65200 で違います。as-overrideとsoo— §8 と §9 で扱います。この 2 行は全フェーズを終えた時点の設定なので、§8 と §9 で見る「投入前」の状態には入っていません。
PE2 側は VRF CUST-A に neighbor が 2 つあります。
! ===== [PE2] show running-config | section router bgp =====
router bgp 65000
bgp router-id 3.3.3.3
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
exit-address-family
!
address-family ipv4 vrf CUST-A
neighbor 172.30.12.2 remote-as 65100
neighbor 172.30.12.2 activate
neighbor 172.30.12.2 as-override
neighbor 172.30.12.2 soo 65000:1
neighbor 172.30.22.2 remote-as 65100
neighbor 172.30.22.2 activate
neighbor 172.30.22.2 as-override
exit-address-family
!
address-family ipv4 vrf CUST-B
neighbor 172.30.22.2 remote-as 65201
neighbor 172.30.22.2 activate
exit-address-familyVRF CUST-A の 172.30.22.2 が site2 の CE-A2、172.30.12.2 が site1 の 2 台目 CE-A1b です。同じ 172.30.22.2 は VRF CUST-B にもあり、そちらは顧客 B の CE-B2 です。顧客 A の site1 が 2 つの PE につながっているのが、§9 の主題になります。
顧客側は素の eBGP だけです。VRF も MPLS もありません。
! ===== [CE-A1] show running-config | section router bgp =====
router bgp 65100
bgp router-id 10.0.0.1
bgp log-neighbor-changes
network 192.168.10.0
neighbor 172.30.11.1 remote-as 65000! ===== [CE-B1] show running-config | section router bgp =====
router bgp 65200
bgp router-id 10.0.0.4
bgp log-neighbor-changes
network 192.168.10.0
neighbor 172.30.11.1 remote-as 65000CE-A1 と CE-B1 は同じ neighbor アドレス 172.30.11.1 へ、同じ 192.168.10.0/24 を network 文で広告しています。違うのは自分の AS 番号 (65100 と 65200) だけです。
VRF に redistribute connected は入れていません。 入れると PE-CE 間のリンクが両方の RD ブロックに現れ、§6 で見たい構造が濁るためです。この選択の副作用として、PE-CE 間のリンクは VPN に載りません。以降の ping がすべて source を明示しているのはこのためです (§11)。
6. 実測: 経路表が分かれている
実測を撮った順は、本文の順と違います。 as-override を入れる前に撮ったのは、§6 のうち §6.4 を除く出力と、§8 の「適用前」と書かれた出力です。入れた後に撮ったのが §6.4・§7・§9・§10 です。as-override そのものは §8 で扱います。§7 で顧客 A の ping が通っているのは、§8 の投入が済んだ後の状態だからです。
まず BGP のセッションを確認します。PE1 が持つセッションは 3 本です。
! ===== [PE1] show bgp vpnv4 unicast all summary =====
BGP router identifier 1.1.1.1, local AS number 65000
BGP table version is 9, main routing table version 9
5 network entries using 1280 bytes of memory
5 path entries using 680 bytes of memory
6/4 BGP path/bestpath attribute entries using 1824 bytes of memory
3 BGP AS-PATH entries using 72 bytes of memory
2 BGP extended community entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 3904 total bytes of memory
BGP activity 5/0 prefixes, 5/0 paths, scan interval 60 secs
5 networks peaked at 07:01:49 Aug 25 2026 UTC (08:27:07.412 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
3.3.3.3 4 65000 573 574 9 0 0 08:37:09 3
172.30.11.2 4 65100 571 573 9 0 0 08:33:59 1
172.30.11.2 4 65200 564 563 9 0 0 08:28:39 13.3.3.3 が PE2 との VPNv4 の iBGP、残りの 2 本が CE-A1 と CE-B1 との eBGP です。172.30.11.2 が 2 行に出ています。 同じアドレスの相手が 2 つのセッションとして並び、AS 列が 65100 と 65200 で分かれています。VRF を指定した表示なら、片方ずつ見えます。
! ===== [PE1] show ip bgp vpnv4 vrf CUST-A summary ===== (PE-CE の隣接が配線の証明を兼ねる)
BGP router identifier 1.1.1.1, local AS number 65000
BGP table version is 9, main routing table version 9
2 network entries using 512 bytes of memory
2 path entries using 272 bytes of memory
6/4 BGP path/bestpath attribute entries using 1824 bytes of memory
3 BGP AS-PATH entries using 72 bytes of memory
2 BGP extended community entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2728 total bytes of memory
BGP activity 5/0 prefixes, 5/0 paths, scan interval 60 secs
5 networks peaked at 07:01:49 Aug 25 2026 UTC (08:26:45.354 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.30.11.2 4 65100 571 573 9 0 0 08:33:37 1
! ===== [PE2] show ip bgp vpnv4 vrf CUST-A summary =====
BGP router identifier 3.3.3.3, local AS number 65000
BGP table version is 8, main routing table version 8
2 network entries using 512 bytes of memory
2 path entries using 272 bytes of memory
6/4 BGP path/bestpath attribute entries using 1824 bytes of memory
3 BGP AS-PATH entries using 72 bytes of memory
2 BGP extended community entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2728 total bytes of memory
BGP activity 5/0 prefixes, 5/0 paths, scan interval 60 secs
5 networks peaked at 07:01:49 Aug 25 2026 UTC (08:26:47.575 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.30.12.2 4 65100 572 568 8 0 0 08:33:24 0
172.30.22.2 4 65100 564 565 8 0 0 08:28:17 1PE2 側の VRF CUST-A には 172.30.12.2 と 172.30.22.2 の 2 本があり、前者の State/PfxRcd は 0 です。CE-A1b は network 文も redistribute も持たないので、1 本も広告していません (§9)。
6.1 1 台の中に複数の経路表がある
PE1 が持つ VRF を並べます。
! ===== [PE1] show vrf =====
Name Default RD Protocols Interfaces
CUST-A 65000:100 ipv4 Gi3
CUST-B 65000:200 ipv4 Gi4
Mgmt-vrf <not set> ipv4 Gi1顧客用の CUST-A と CUST-B に加えて、管理用の Mgmt-vrf があります。この Mgmt-vrf は day0 で作られるもので、3-2 ルーティングの基本 で扱ったものと同じです。Interfaces 列に注目すると、Gi3 が CUST-A、Gi4 が CUST-B に属しています。
次にインタフェースのアドレスを見ます。
! ===== [PE1] show ip interface brief ===== (Gi3 と Gi4 に同じ 172.30.11.1)
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1 172.16.1.231 YES TFTP up up
GigabitEthernet2 10.10.12.1 YES TFTP up up
GigabitEthernet3 172.30.11.1 YES TFTP up up
GigabitEthernet4 172.30.11.1 YES TFTP up up
Loopback0 1.1.1.1 YES TFTP up up Gi3 と Gi4 に同じ 172.30.11.1 が付いています。 通常の 1 経路表のルータでは重複として拒否される設定が、VRF が違えば通ります。ただし show ip interface brief は VRF 列を持たないので、この出力単体では「なぜ通るのか」が分かりません。所属を示すのは 1 つ前の show vrf の Interfaces 列です。2 つの出力を並べて初めて主張が閉じます。
経路表を VRF ごとに引きます。
! ===== [PE1] show ip route vrf CUST-A =====
Routing Table: CUST-A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.30.11.0/30 is directly connected, GigabitEthernet3
L 172.30.11.1/32 is directly connected, GigabitEthernet3
B 192.168.10.0/24 [20/0] via 172.30.11.2, 08:34:47
B 192.168.20.0/24 [200/0] via 3.3.3.3, 08:28:36! ===== [PE1] show ip route vrf CUST-B =====
Routing Table: CUST-B
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.30.11.0/30 is directly connected, GigabitEthernet4
L 172.30.11.1/32 is directly connected, GigabitEthernet4
B 192.168.10.0/24 [20/0] via 172.30.11.2, 08:29:30
B 192.168.20.0/24 [200/0] via 3.3.3.3, 08:27:58
B 192.168.30.0/24 [200/0] via 3.3.3.3, 08:27:58同じ 192.168.10.0/24 が両方の表にあります。 どちらも via 172.30.11.2 で、next-hop の文字列まで同じです。違うのは、この経路がどちらの eBGP セッションから来たかだけです。
もう 1 つ、AD (Administrative Distance) の値に注目します。192.168.10.0/24 は [20/0]、192.168.20.0/24 は [200/0] です。前者は CE から直接受け取った eBGP の経路、後者は PE2 から VPNv4 で受け取った iBGP の経路で、AD がそのまま分かれています。CUST-B の表にだけ 192.168.30.0/24 があるのは、この網を顧客 B の site2 だけが持っているからです。
そしてグローバルの経路表を見ます。
! ===== [PE1] show ip route ===== (グローバルに顧客網が無い)
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 10.10.12.2, 08:38:24, GigabitEthernet2
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/3] via 10.10.12.2, 08:38:10, GigabitEthernet2
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.10.12.0/30 is directly connected, GigabitEthernet2
L 10.10.12.1/32 is directly connected, GigabitEthernet2
O 10.10.23.0/30 [110/2] via 10.10.12.2, 08:38:10, GigabitEthernet2192.168 で始まる経路が 1 本もありません。 あるのは Loopback0 の 3 つ (1.1.1.1 / 2.2.2.2 / 3.3.3.3) とコアのリンク 2 本だけです。PE-CE 間の 172.30.11.0/30 も載っていません。
載っていない理由は、§2 で見たとおり vrf forwarding でインタフェースを VRF に入れたからです。VRF に属するインタフェースの connected 経路は、その VRF の経路表へ入ります。実際、上の VRF CUST-A の表には C 172.30.11.0/30 is directly connected, GigabitEthernet3 が、VRF CUST-B の表には同じ prefix が Gi4 として入っています。グローバル OSPF に入れていないことは、この分離の理由ではありません（VRF IF をグローバル OSPF に入れていないのは本ラボの構成上の選択で、その場合に何が起きるかは確かめていません）。
! ===== [PE1] show ip ospf interface brief ===== (VRF IF は載らない)
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo0 1 0 1.1.1.1/32 1 LOOP 0/0
Gi2 1 0 10.10.12.1/30 1 BDR 1/1OSPF が動いているのは Lo0 と Gi2 だけで、VRF に入れた Gi3 と Gi4 は並んでいません。
6.2 VPNv4 テーブルは RD ブロックに分かれる
顧客の経路を PE1 から PE2 へ運ぶのが、§3 で見た VPNv4 です。PE1 の VPNv4 テーブルを見ます。
! ===== [PE1] show bgp vpnv4 unicast all ===== (RD ブロックが 2 つ・どちらにも 192.168.10.0/24)
BGP table version is 9, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:100 (default for vrf CUST-A)
*> 192.168.10.0 172.30.11.2 0 0 65100 i
*>i 192.168.20.0 3.3.3.3 0 100 0 65100 i
Route Distinguisher: 65000:200 (default for vrf CUST-B)
*> 192.168.10.0 172.30.11.2 0 0 65200 i
*>i 192.168.20.0 3.3.3.3 0 100 0 65201 i
*>i 192.168.30.0 3.3.3.3 0 100 0 65201 iRoute Distinguisher: の行で 2 つのブロックに分かれ、どちらのブロックにも 192.168.10.0 の行があります。この 2 行は Next Hop まで同じ 172.30.11.2 で、違うのは RD のヘッダ行と Path 列 (65100 と 65200) だけです。§3 で「同じ prefix が 2 本のまま並ぶ」と書いたものが、そのままの形で出ています。
ここから 1 つ、実務上の帰結が出ます。show bgp vpnv4 unicast all 系の出力は、決して 1 顧客のスコープになりません。 prefix の文字列で探すと必ず両方に当たるので、読むときも判定するときも RD ブロック単位で行う必要があります。
6.3 経路に RT が付いている
prefix を指定して、経路の属性を開きます。
! ===== [PE1] show bgp vpnv4 unicast all 192.168.20.0/24 ===== (③ RT が経路に付いている)
BGP routing table entry for 65000:100:192.168.20.0/24, version 5
Paths: (1 available, best #1, table CUST-A)
Flag: 0x100
Advertised to update-groups:
2
Refresh Epoch 1
65100
3.3.3.3 (metric 3) (via default) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65000:100
mpls labels in/out nolabel/19
rx pathid: 0, tx pathid: 0x0
Updated on Aug 25 2026 07:01:09 UTC
BGP routing table entry for 65000:200:192.168.20.0/24, version 8
Paths: (1 available, best #1, table CUST-B)
Advertised to update-groups:
3
Refresh Epoch 1
65201
3.3.3.3 (metric 3) (via default) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65000:200
mpls labels in/out nolabel/20
rx pathid: 0, tx pathid: 0x0
Updated on Aug 25 2026 07:01:49 UTCExtended Community: RT:65000:100 の行が RT です。同じコマンドの出力に 65000:200:192.168.20.0/24 のエントリも続き、そちらには RT:65000:200 が付いています。同じ 192.168.20.0/24 という文字列に対して、RD の違う 2 つのエントリが返ってきます。
mpls labels in/out nolabel/19 の行も出ています。これは §7 で扱う内ラベルです。
RT を運ぶには VPNv4 のセッションで拡張 community を送る必要がありますが、本ラボはこれを設定していません。既定値も含めて running-config を表示すると、こうなります。
! ===== [PE1] show running-config all | section address-family vpnv4 ===== (U1: 明示設定なしの既定値)
address-family vpnv4
bgp aggregate-timer 30
bgp update-group split as-override
bgp nexthop trigger enable
bgp nexthop trigger delay 5
bgp scan-time 60
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extendedneighbor 3.3.3.3 send-community extended が入っています。 本ラボの day0 はこの行を投入していません。それでも show running-config all にも、§5.4 で引用した素の show running-config | section router bgp にも出ています。RT を運ぶには拡張 community の送出が要るので、L3VPN として成立させるための最低限が機器側で用意されている形です。この行が「機器が書き込んだ実設定」なのか「素の設定にも表示される既定値」なのかは、本ラボでは切り分けていません（§2 の Gi3 の設定にも、投入していない negotiation auto や no mop enabled が同じように出ています）。設定手順として明示的に書かれることも多い行です。他のバージョンや機種でも同じとは限らないので、設定を書き起こすときは省かずに書くほうが安全です。
6.4 import RT を外すと、そのブロックからだけ消える
§4.1 で「RT が合わない経路は受信の段階で捨てられる」と書きました。これを PE2 で確かめます。PE2 の VRF CUST-A から route-target import 65000:100 を外し、削除前・削除後・復元後の 3 状態を撮ります。
削除前の PE2 の VRF CUST-A の経路表です。
! ===== [PE2] show ip route vrf CUST-A ===== (削除前)
Routing Table: CUST-A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
172.30.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.30.12.0/30 is directly connected, GigabitEthernet4
L 172.30.12.1/32 is directly connected, GigabitEthernet4
C 172.30.22.0/30 is directly connected, GigabitEthernet3
L 172.30.22.1/32 is directly connected, GigabitEthernet3
B 192.168.10.0/24 [200/0] via 1.1.1.1, 00:02:39
B 192.168.20.0/24 [20/0] via 172.30.22.2, 08:57:52同じ時点の VPNv4 テーブルです。
! ===== [PE2] show bgp vpnv4 unicast all ===== (削除前)
BGP table version is 11, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:100 (default for vrf CUST-A)
*>i 192.168.10.0 1.1.1.1 0 100 0 65100 i
*> 192.168.20.0 172.30.22.2 0 0 65100 i
Route Distinguisher: 65000:200 (default for vrf CUST-B)
*>i 192.168.10.0 1.1.1.1 0 100 0 65200 i
*> 192.168.20.0 172.30.22.2 0 0 65201 i
*> 192.168.30.0 172.30.22.2 0 0 65201 iここで route-target import 65000:100 を外します。経路表はこうなります。
! ===== [PE2] show ip route vrf CUST-A ===== (削除後)
Routing Table: CUST-A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
172.30.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.30.12.0/30 is directly connected, GigabitEthernet4
L 172.30.12.1/32 is directly connected, GigabitEthernet4
C 172.30.22.0/30 is directly connected, GigabitEthernet3
L 172.30.22.1/32 is directly connected, GigabitEthernet3
B 192.168.20.0/24 [20/0] via 172.30.22.2, 08:58:10192.168.10.0/24 が消えました。 残っている 192.168.20.0/24 は、CE-A2 から直接受け取っている eBGP の経路なので影響を受けません。
同じ時点の VPNv4 テーブルが要点です。
! ===== [PE2] show bgp vpnv4 unicast all ===== (削除後)
BGP table version is 12, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:100 (default for vrf CUST-A)
*> 192.168.20.0 172.30.22.2 0 0 65100 i
Route Distinguisher: 65000:200 (default for vrf CUST-B)
*>i 192.168.10.0 1.1.1.1 0 100 0 65200 i
*> 192.168.20.0 172.30.22.2 0 0 65201 i
*> 192.168.30.0 172.30.22.2 0 0 65201 i読み方を 4 つに分けます。
Route Distinguisher: 65000:100のブロックは残っています。- そのブロックの中に 192.168.20.0 は在ります。
- そのブロックの中に 192.168.10.0 は在りません。
Route Distinguisher: 65000:200のブロックには 192.168.10.0 が在ります。
消えたのは顧客 A の 192.168.10.0/24 だけで、顧客 B の同名 prefix は残っています。 これが §3 で見た RD の存在意義そのものです。同じ文字列の prefix が、RD によって別々に扱われています。
そして消えたのは経路表からだけではありません。VPNv4 テーブルからも消えています。 これが §4.1 で書いた「落ちる場所」の違いです。PE2 は経路を受け取ったうえで VRF に入れないのではなく、どの VRF の import RT にも当たらないので受け取っていません。
import を戻すと復旧します。
! ===== [PE2] show ip route vrf CUST-A ===== (復元後)
Routing Table: CUST-A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
172.30.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.30.12.0/30 is directly connected, GigabitEthernet4
L 172.30.12.1/32 is directly connected, GigabitEthernet4
C 172.30.22.0/30 is directly connected, GigabitEthernet3
L 172.30.22.1/32 is directly connected, GigabitEthernet3
B 192.168.10.0/24 [200/0] via 1.1.1.1, 00:00:11
B 192.168.20.0/24 [20/0] via 172.30.22.2, 08:58:32この復旧は PE2 の中だけの話ではありません。PE2 が CE-A2 へ広告し直すところまで戻ります。
! ===== [CE-A2] show ip route 192.168.10.0 255.255.255.0 ===== (復元後・遠端まで戻った)
Routing entry for 192.168.10.0/24
Known via "bgp 65100", distance 20, metric 0
Tag 65000, type external
Last update from 172.30.22.1 00:00:13 ago
Routing Descriptor Blocks:
* 172.30.22.1, from 172.30.22.1, 00:00:13 ago
opaque_ptr 0x7F6DBAB195D8
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 65000
MPLS label: noneCE-A2 の RIB に Known via "bgp 65100", distance 20 として入っています。AS Hops 2 と Route tag 65000 の表示については §8 で扱います。
7. 実測: ラベルが 2 枚積まれる
ここまでは制御平面の話でした。顧客の経路が PE1 と PE2 のあいだで正しく分かれて運ばれることは確かめましたが、実際のパケットがどういう形でコアを通るのかはまだ見ていません。
入口でラベルを貼る動作を imposition、出口でラベルを外して素の IP へ戻す動作を disposition と呼びます。6-1 §5.2 では、入口でラベルを貼る判断が LFIB ではなく CEF 側で行われることを確かめました。本節はそこにもう 1 枚が加わります。
7.1 制御平面には 2 つの値がある
PE1 が 192.168.20.0/24 へ送るときに使う値を、2 つの独立した出力から取ります。まず内側です。
! ===== [PE1] show bgp vpnv4 unicast all labels ===== (内ラベル・フローの帰属)
Network Next Hop In label/Out label
Route Distinguisher: 65000:100 (CUST-A)
192.168.10.0 172.30.11.2 19/nolabel
192.168.20.0 3.3.3.3 nolabel/19
Route Distinguisher: 65000:200 (CUST-B)
192.168.10.0 172.30.11.2 20/nolabel
192.168.20.0 3.3.3.3 nolabel/20
192.168.30.0 3.3.3.3 nolabel/21Out label の列が、PE1 が積む内ラベルです。VRF CUST-A の 192.168.20.0 は 19、VRF CUST-B の同じ 192.168.20.0 は 20 です。同じ prefix でも顧客ごとに値が違います。
次に外側です。
! ===== [PE1] show mpls forwarding-table 3.3.3.3 32 ===== (外ラベル = transport)
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
18 17 3.3.3.3/32 0 Gi2 10.10.12.2 引いているのは 3.3.3.3/32 です。顧客の宛先 192.168.20.0/24 ではありません。3.3.3.3 は PE2 の Loopback0、すなわち VPNv4 経路の BGP next-hop です。PE1 が P へ渡すときに貼る値は 17 で、これは P が 3.3.3.3/32 に対して配った値です。
この 2 つが 1 か所に並ぶのが CEF の出力です。
! ===== [PE1] show ip cef vrf CUST-A 192.168.20.0 detail ===== (imposition は CEF 側)
192.168.20.0/24, epoch 0, flags [rib defined all labels]
recursive via 3.3.3.3 label 19
nexthop 10.10.12.2 GigabitEthernet2 label 17-(local:18)recursive via 3.3.3.3 label 19 が内ラベル、nexthop 10.10.12.2 GigabitEthernet2 label 17-(local:18) が外ラベルです。顧客の経路を BGP next-hop へ再帰的に解決し、その next-hop に対する transport の LSP を引く、という 2 段構えがそのまま行に出ています。
7.2 PE1 から P への線上では 2 枚
顧客 A と顧客 B の ping を同時に流し、P の Gi2 (PE1 から受ける側) でパケットを捕まえます。
! ===== [CE-A1] ping 192.168.20.1 source GigabitEthernet3 repeat 60 =====
Type escape sequence to abort.
Sending 60, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (60/60), round-trip min/avg/max = 2/4/12 ms! ===== [CE-B1] ping 192.168.20.1 source Loopback1 repeat 120 (顧客 A と同時) =====
Type escape sequence to abort.
Sending 120, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (120/120), round-trip min/avg/max = 2/5/15 ms捕まえたフレームのうち、顧客 B のものはこうなります。
8 122 15.573020 52:54:00:41:7D:B8 -> 52:54:00:EE:F5:42 -- MPLS unicast
0000: 525400EE F5425254 00417DB8 88470001 RT...BRT.A}..G..
0010: 10FE0001 41FE4500 006400AA 0000FE01 ....A.E..d......
0020: 1C9CC0A8 0A01C0A8 14010800 CE7A0002 .............z..
0030: 00000000 000001E1 ADECABCD ABCDABCD ................| 位置 | 値 | 意味 |
|---|---|---|
| 0x0C-0x0D | 8847 | イーサタイプ (MPLS unicast) |
| 0x0E-0x11 | 0001 10FE | 1 枚目 = Label 17 / TC 0 / S=0 / TTL 254 |
| 0x12-0x15 | 0001 41FE | 2 枚目 = Label 20 / TC 0 / S=1 / TTL 254 |
| 0x16 以降 | 4500 ... | 内側の IPv4 ヘッダ |
1 枚目の S が 0 で、その下にもう 1 枚あります。 2 枚目の S は 1 で、その直後のバイトが 45 — IPv4 の version 4 / IHL 5 です。6-1 §3.2 で「S ビットが存在する理由は重ねられることにある」と書いたものの実物がこれです。
同じキャプチャの中に、顧客 A のフレームも混ざっています。
11 122 15.586020 52:54:00:41:7D:B8 -> 52:54:00:EE:F5:42 -- MPLS unicast
0000: 525400EE F5425254 00417DB8 88470001 RT...BRT.A}..G..
0010: 10FE0001 31FE4500 00640046 0000FE01 ....1.E..d.F....
0020: 1D00C0A8 0A01C0A8 14010800 F1F80003 ................
0030: 00000000 000001E5 8A69ABCD ABCDABCD .........i......| 位置 | 値 | 意味 |
|---|---|---|
| 0x0E-0x11 | 0001 10FE | 1 枚目 = Label 17 / S=0 |
| 0x12-0x15 | 0001 31FE | 2 枚目 = Label 19 / S=1 |
外ラベルは 2 顧客とも 17 で同じ、内ラベルだけが 19 と 20 で違います。 1 本の LSP を 2 つの顧客が同時に通っており、区別しているのは内ラベルです。
ここで注意が要ります。どちらのフレームがどちらの顧客かは、キャプチャ単体では決められません。 内側の IP ヘッダを読むと、どちらも送信元 192.168.10.1・宛先 192.168.20.1 で同じ文字列になるためです。帰属を確定させているのは §7.1 の show bgp vpnv4 unicast all labels で、そちらが 19 を CUST-A、20 を CUST-B と宣言しています。キャプチャと制御平面を突き合わせて初めて、どちらの顧客かが言えます。
同じ線には、ラベルが 1 枚だけのフレームも流れています。
6 77 12.534020 52:54:00:41:7D:B8 -> 52:54:00:EE:F5:42 -- MPLS unicast
0000: 525400EE F5425254 00417DB8 88470001 RT...BRT.A}..G..
0010: 1DFF45C0 003B3250 4000FF06 40A50101 ..E..;2P@...@...
0020: 01010303 030300B3 6B34E187 6ED5F9C6 ........k4..n...
0030: 01315018 3F8EACD4 0000FFFF FFFFFFFF .1P.?...........| 位置 | 値 | 意味 |
|---|---|---|
| 0x0E-0x11 | 0001 1DFF | Label 17 / TC 6 / S=1 / TTL 255 |
| 0x12 以降 | 45C0 ... | 内側の IPv4 ヘッダ (1.1.1.1 → 3.3.3.3 / TCP 179) |
外ラベルと同じ 17 が、S=1 で 1 枚だけ乗っています。 内側は PE1 と PE2 のあいだの TCP 179、つまり VPNv4 を運んでいる iBGP セッション自身です。同じラベル値でも、下に何か積まれているかどうかで S の値が変わります。 S は「そのラベルが最下段か」だけを表しており、ラベルの値とは無関係です。
7.3 P から PE2 への線上では 1 枚 — PHP
次に PE2 の Gi2 (P から受ける側) で捕まえます。
1 118 1.303985 52:54:00:01:30:AC -> 52:54:00:86:48:AA -- MPLS unicast
0000: 52540086 48AA5254 000130AC 88470001 RT..H.RT..0..G..
0010: 41FD4500 006400AA 0000FE01 1C9CC0A8 A.E..d..........
0020: 0A01C0A8 14010800 CE7A0002 00000000 .........z......
0030: 000001E1 ADECABCD ABCDABCD ABCDABCD ................ 4 118 1.317977 52:54:00:01:30:AC -> 52:54:00:86:48:AA -- MPLS unicast
0000: 52540086 48AA5254 000130AC 88470001 RT..H.RT..0..G..
0010: 31FD4500 00640046 0000FE01 1D00C0A8 1.E..d.F........
0020: 0A01C0A8 14010800 F1F80003 00000000 ................
0030: 000001E5 8A69ABCD ABCDABCD ABCDABCD .....i..........| フレーム | 0x0E-0x11 | 意味 |
|---|---|---|
| #1 | 0001 41FD | Label 20 / S=1 / TTL 253 |
| #4 | 0001 31FD | Label 19 / S=1 / TTL 253 |
1 枚しかありません。 0x12 のバイトが 45 になっており、シムはこの 1 枚で終わりです。値は 19 と 20 で、§7.2 の内ラベルと同じです。
2 つの測定点をまとめると、次のようになります。
! 復号結果 (P Gi2 in): 2 枚積みフレーム 32 件 / 外ラベル [17] (S=0) / 内ラベル [19, 20] (S=1)
! 復号結果 (PE2 Gi2 in): フレーム 39 件 / うち 1 枚のみ 39 件 / ラベル [19, 20]件数は突き合わせないでください。 32 件と 39 件は別々のバッファの計数で、どちらも 40 で打ち切っています。同じパケットを両端で数えた対応関係ではありません。
外ラベルを外したのは P で、これが 6-1 §7 で扱った PHP (Penultimate Hop Popping) です。仕組みも 6-1 と同じです。出口の PE2 が自分の Loopback0 に対して imp-null を配っています。
! ===== [PE2] show mpls ldp bindings 3.3.3.3 32 ===== (PHP の発生源 = egress 自身の local binding)
lib entry: 3.3.3.3/32, rev 2
local binding: label: imp-null
remote binding: lsr: 2.2.2.2:0, label: 17P はそれを受け取っています。
! ===== [P] show mpls ldp bindings 3.3.3.3 32 ===== (P が受け取った広告)
lib entry: 3.3.3.3/32, rev 10
local binding: label: 17
remote binding: lsr: 3.3.3.3:0, label: imp-null
remote binding: lsr: 1.1.1.1:0, label: 18remote binding: lsr: 3.3.3.3:0, label: imp-null の行が PE2 からの広告です。受け取った結果、P の転送表はこうなります。
! ===== [P] show mpls forwarding-table 3.3.3.3 32 ===== (PHP の実行者)
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
17 Pop Label 3.3.3.3/32 122988 Gi3 10.10.23.2 Pop Label です。P は 17 で入ってきたフレームからラベルを 1 枚外して Gi3 へ出します。
7.4 PE2 は内ラベルで VRF と出口を選ぶ
外ラベルが外れても、PE2 に届いた時点でまだ内ラベルが残っています。PE2 はこれを自分の転送表で引きます。
! ===== [PE2] show mpls forwarding-table vrf CUST-A ===== (PE2 は内ラベルで VRF を選ぶ)
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
19 No Label 192.168.20.0/24[V] \
13908 Gi3 172.30.22.2 ラベル 19 が VRF CUST-A の 192.168.20.0/24 に対応し、出口が Gi3・next-hop が 172.30.22.2 です。 [V] の印が VRF 所属を示し、Outgoing Label は No Label — ここでラベルが全部外れて素の IP になります。これが disposition です。
PE2 は顧客の判別に宛先 IP を使っていません。 使っているのは内ラベルです。顧客 A と顧客 B の宛先はどちらも 192.168.20.1 なので、宛先 IP からは判別できません。
7.5 P は顧客を知らない
ここまでの転送に、P は顧客の情報を一切使っていません。P が何を持っていないかを 4 つの出力で確かめます。
! ===== [P] show vrf ===== (顧客 VRF は無い。管理用の Mgmt-vrf だけ)
Name Default RD Protocols Interfaces
Mgmt-vrf <not set> ipv4 Gi1顧客 VRF がありません。 出ているのは管理用の Mgmt-vrf だけです。この行は day0 が作るもので、show vrf が空になるわけではない点に注意が要ります。
! ===== [P] show ip route ===== (顧客網が 1 本も無い)
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 10.10.12.1, 08:53:08, GigabitEthernet2
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 10.10.23.2, 08:52:54, GigabitEthernet3
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.12.0/30 is directly connected, GigabitEthernet2
L 10.10.12.2/32 is directly connected, GigabitEthernet2
C 10.10.23.0/30 is directly connected, GigabitEthernet3
L 10.10.23.1/32 is directly connected, GigabitEthernet3192.168 で始まる経路が 1 本もありません。 Loopback0 の 3 つとコアのリンク 2 本だけです。
! ===== [P] show mpls forwarding-table ===== (transport ラベルだけ)
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 1.1.1.1/32 123873 Gi2 10.10.12.1
17 Pop Label 3.3.3.3/32 123061 Gi3 10.10.23.2 LFIB は 2 行だけです。 1.1.1.1/32 と 3.3.3.3/32、つまり両端の PE の Loopback0 に対する transport のラベルだけを持っています。§7.1 で見た VPN ラベル 19 と 20 は、この表に 1 行もありません。
! ===== [P] show running-config | section router bgp ===== (出力なし = BGP を持たない)
! (空出力そのものは撮れていないのと区別できないため、次の 1 本と組で示す)
! ===== [P] show ip bgp summary ===== (BGP プロセスが無いことの裏取り)
% BGP not activeP は BGP プロセスを持っていません。 % BGP not active という応答は、出力が空だったのではなく「BGP が動いていない」という返事です。
事業者のコアは、顧客の経路を 1 本も持たないまま顧客のパケットを運んでいます。VRF の数も、顧客の prefix も、顧客の AS 番号も、P は知りません。これが L3VPN の要になる性質で、コアの規模が顧客数に引きずられない理由でもあります。
7.6 通しで見る
入口の CE-A1 から traceroute を打つと、ここまで個別に見たものが 1 本に並びます。
! ===== [CE-A1] traceroute 192.168.20.1 source GigabitEthernet3 probe 1 timeout 1 ===== (コアの見え方)
Type escape sequence to abort.
Tracing the route to 192.168.20.1
VRF info: (vrf in name/id, vrf out name/id)
1 172.30.11.1 6 msec
2 10.10.12.2 [MPLS: Labels 17/19 Exp 0] 28 msec
3 172.30.22.1 [MPLS: Label 19 Exp 0] 11 msec
4 172.30.22.2 22 msec- 1 行目
172.30.11.1— PE1 の VRF CUST-A 側のインタフェース - 2 行目
10.10.12.2— P。[MPLS: Labels 17/19 Exp 0]と複数形で、2 枚積みがそのまま出ています - 3 行目
172.30.22.1— PE2。[MPLS: Label 19 Exp 0]と単数形で、外ラベルが外れた後の状態です - 4 行目
172.30.22.2— CE-A2
2 行目に P の 10.10.12.2 が出ています。 §7.5 で確かめたとおり P は顧客の経路を 1 本も持たないのに、顧客側から打った traceroute に応答しています。この読み方は §11 で扱います。
7.7 6-1 の 3 つの記述を読み直す
6-1 は 1 枚のラベルだけを扱ったので、いくつかの記述に前提が隠れていました。ここで明示します。
1 つ目は PHP です。 6-1 §7 では「R3 はラベルを外して素の IP パケットとして R4 へ渡す」と書きました。本節では、PHP の後も VPN ラベルが 1 枚残っています (§7.3)。PHP が外すのは常に最上段の 1 枚だけであり、6-1 でそれが素の IP になったのは、積まれていたラベルが 1 枚しか無かったからです。
2 つ目はラベルの帰属です。 6-1 の要点は「ラベルの値は下流の LSR が決め、上流はそれを使う」でした。これが当てはまるのは外ラベルだけです。 PE1 の下流は P で、外ラベル 17 は確かに P が配った値です。しかし内ラベル 19 を配ったのは P ではなく、LSP の向こう端にいる PE2 です。MP-BGP が PE1 と PE2 のあいだで直接やり取りしており、途中の P はこの値を配りも読みもしません。証拠は §7.5 の LFIB で、P の表に VPN ラベルが 1 行も無いことです。
3 つ目は、6-1 から何が変わって何が変わっていないかです。 6-1 でも egress の Loopback0 (4.4.4.4/32) に対する LSP は存在していました。終端が Loopback0 であること自体は 6-1 から変わっていません。 変わったのは次の 2 点です。
| # | 変わったこと |
|---|---|
| 1 | 顧客網が IGP から消えたので、コアに顧客網宛の FEC が無くなった (§6.1・§7.5) |
| 2 | 外ラベルを引き当てる鍵が、宛先 prefix から BGP next-hop (PE2 の Loopback0) に変わった (§7.1) |
なお、ラベル値がその場限りの意味しか持たないという 6-1 の性質は、内ラベルでも変わりません。§7.1 の出力で、PE1 は CUST-A の 192.168.10.0 に対して In label 19 を配っており、PE2 が CUST-A の 192.168.20.0 に対して配った Out label 19 と数字が一致します。この 2 つの 19 は別物です。
8. PE-CE eBGP と as-override
PE と CE のあいだは eBGP で結びます。ここで、顧客が複数の拠点で同じ AS 番号を使っていると、経路が届かなくなります。eBGP には、受け取った経路の AS_PATH に自分の AS 番号が入っていたらその経路を捨てる、というループ防止の規則があるためです。
本ラボの顧客 A は site1 も site2 も AS 65100 です。site1 の 192.168.10.0/24 が PE1 → PE2 と運ばれて CE-A2 へ広告されるとき、AS_PATH には 65100 が入っています。CE-A2 自身が 65100 なので、この経路は捨てられます。
この拒否は、PE 側からは見えません。 PE2 の広告内容を見ます。
! ===== [PE2] show ip bgp vpnv4 vrf CUST-A neighbors 172.30.22.2 advertised-routes ===== (as-override 適用前・PE は広告している)
BGP table version is 8, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:100 (default for vrf CUST-A)
*>i 192.168.10.0 1.1.1.1 0 100 0 65100 i
*> 192.168.20.0 172.30.22.2 0 0 65100 i
Total number of prefixes 2 Route Distinguisher: 65000:100 のブロックに 192.168.10.0 が在り、Path 列は 65100 です。PE2 は広告しています。 ところが受け取る側はこうです。
! ===== [CE-A2] show ip bgp 192.168.10.0/24 ===== (as-override 適用前・CE は受け取っていない)
% Network not in table% Network not in table です。 広告は届いているのに、CE-A2 の BGP テーブルに入っていません。
拒否は対称に起きます。site2 の 192.168.20.0/24 も、site1 の CE-A1 に入りません。
! ===== [CE-A1] show ip bgp 192.168.20.0/24 ===== (as-override 適用前・拒否は対称に起きる)
% Network not in table多重接続サイトの 2 台目 CE-A1b も同じです。
! ===== [CE-A1b] show ip bgp 192.168.10.0/24 ===== (as-override 適用前・多重接続サイトの 2 台目)
% Network not in table対照として、顧客 B を見ます。顧客 B は site1 が AS 65200、site2 が AS 65201 で、拠点ごとに別の AS 番号です。
! ===== [CE-B1] show ip bgp ===== (対照: 顧客 B は拠点ごとに別 AS なので as-override 無しで届いている)
BGP table version is 4, local router ID is 10.0.0.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 192.168.10.0 0.0.0.0 0 32768 i
*> 192.168.20.0 172.30.11.1 0 65000 65201 i
*> 192.168.30.0 172.30.11.1 0 65000 65201 i設定を何も足していない時点で、192.168.20.0/24 も 192.168.30.0/24 も入っています。 Path 列は 65000 65201 で、自分の 65200 は含まれていません。同一 AS でなければ、この問題は起きません。
8.1 as-override は AS_PATH を書き換える
顧客が同一 AS を使い続けたい場合、PE 側で neighbor <ip> as-override を設定します。この設定を入れると、PE は CE へ広告するときに AS_PATH の中の「その neighbor の remote-as と一致する AS 番号」を自分の AS 番号へ置き換えます。置き換わるのは相手として設定した AS 番号だけで、AS_PATH 中の他の AS には触れません。本ラボでは PE1 の CE-A1 向け、PE2 の CE-A2 向け、PE2 の CE-A1b 向けの 3 本すべてに入れています (§5.4 の設定)。
適用後の CE-A2 を見ます。
! ===== [CE-A2] show ip bgp 192.168.10.0/24 ===== (as-override 適用後・AS_PATH が書き換わっている)
BGP routing table entry for 192.168.10.0/24, version 3
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
65000 65000
172.30.22.1 from 172.30.22.1 (3.3.3.3)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on Aug 25 2026 15:36:34 UTCPath 列が 65000 65000 になっています。 元は 65100 の 1 つだけでしたが、それが事業者の AS 65000 に置き換わり、PE2 が自分の AS を前置した結果 65000 が 2 つ並んでいます。CE-A2 から見て自分の 65100 が含まれないので、受け入れられます。
CE-A1 側も対称に入ります。
! ===== [CE-A1] show ip bgp 192.168.20.0/24 ===== (as-override 適用後・対称)
BGP routing table entry for 192.168.20.0/24, version 3
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65000 65000
172.30.11.1 from 172.30.11.1 (1.1.1.1)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on Aug 25 2026 15:36:20 UTCそして PE 側の広告内容です。
! ===== [PE2] show ip bgp vpnv4 vrf CUST-A neighbors 172.30.22.2 advertised-routes ===== (as-override 適用後・PE 側の広告は変わっていない)
BGP table version is 8, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:100 (default for vrf CUST-A)
*>i 192.168.10.0 1.1.1.1 0 100 0 65100 i
*> 192.168.20.0 172.30.22.2 0 0 65100 i
Total number of prefixes 2 適用前 (§8 冒頭) と同じ内容です。 Path 列も 65100 のままです。advertised-routes が送信側のローカルな BGP テーブルから起こされる表示で、送出時の AS_PATH 加工までは映さないため、と考えられます。ただしその機序自体は本ラボでは確かめていません。 確かなのは、この出力が前後で変わらなかったことと、as-override が効いたことの証拠は受信側の CE からしか取れなかったことです。
変わったのは PE の広告ではなく、CE の受け入れです。 PE は前も後も同じ経路を広告し続けており、CE 側が捨てなくなりました。
なお §6.4 の最後で見た CE-A2 の RIB の AS Hops 2 が、この 65000 65000 を数えた結果です。並んで出ている Route tag 65000 のほうは数ではなく、学習元の AS 番号 (事業者の 65000) が経路のタグとして入ったものです。
9. 多重接続サイトと SoO
as-override は同一 AS の設計を通しますが、AS_PATH によるループ防止をサイト単位で外すという代償を伴います。それが表に出るのが、1 つのサイトが 2 つの PE につながっている構成です。
本ラボの顧客 A の site1 は、CE-A1 (→PE1) と CE-A1b (→PE2) の 2 台で、両者は同じ LAN 192.168.10.0/24 に載っています。この 2 台のあいだに BGP は張っていません。また CE-A1b は経路を 1 本も広告しません。
! ===== [CE-A1b] show running-config | section router bgp ===== (U4: network 文も redistribute も無い)
router bgp 65100
bgp router-id 10.0.0.2
bgp log-neighbor-changes
neighbor 172.30.12.1 remote-as 65000network 文も redistribute もありません。PE2 から見ると、こうなります。
! ===== [PE2] show bgp vpnv4 unicast vrf CUST-A neighbors 172.30.12.2 routes ===== (U4: 0 件であること)
Total number of prefixes 0 CE-A1b から受け取っている経路は 0 本です。 したがって以降で CE-A1b の表に現れるものは、すべて PE2 から広告されたものです。
9.1 サイト自身の経路が戻ってくる
as-override を入れた後の CE-A1b の BGP テーブルを見ます。
! ===== [CE-A1b] show ip bgp ===== (as-override 適用後・サイト自身の経路が戻ってきている (r> = RIB-failure))
BGP table version is 3, local router ID is 10.0.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
r> 192.168.10.0 172.30.12.1 0 65000 65000 i
*> 192.168.20.0 172.30.12.1 0 65000 65000 i1 行目の 192.168.10.0 は、CE-A1b 自身が載っている LAN です。 経路は CE-A1 → PE1 → PE2 → CE-A1b と一周して戻ってきています。行頭が r> になっているのは RIB-failure で、同じ網が connected として既に RIB に在るため BGP の経路が RIB へ入らなかったことを示します。
prefix を指定するとこう見えます。
! ===== [CE-A1b] show ip bgp 192.168.10.0/24 ===== (SoO 適用前)
BGP routing table entry for 192.168.10.0/24, version 5
Paths: (1 available, best #1, table default, RIB-failure(17))
Not advertised to any peer
Refresh Epoch 3
65000 65000
172.30.12.1 from 172.30.12.1 (3.3.3.3)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on Aug 25 2026 15:55:45 UTCPaths: (1 available, best #1, table default, RIB-failure(17)) の行に RIB-failure が出ています。
as-override が無ければ、この経路は AS_PATH に 65100 を含むので CE-A1b が捨てていました。 as-override が 65100 を 65000 へ書き換えたことで、その守りが外れています。
PE2 側の広告内容も確認します。
! ===== [PE2] show ip bgp vpnv4 vrf CUST-A neighbors 172.30.12.2 advertised-routes ===== (SoO 適用前・PE2 はサイトへ広告している)
BGP table version is 10, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:100 (default for vrf CUST-A)
*>i 192.168.10.0 1.1.1.1 0 100 0 65100 i
*> 192.168.20.0 172.30.22.2 0 0 65100 i
Total number of prefixes 2 PE2 はサイト自身の経路を、そのサイトの CE へ広告しています。 合計 2 本です。
9.2 SoO でサイトを識別する
この状況で使うのが SoO (Site of Origin) です。RT と同じく BGP の拡張 community で、3-8 BGP community 属性 で「経路が発生したサイトを識別する拡張 community」として紹介したものです。
neighbor <ip> soo <value> は、2 つの別々の仕事をします。
| 仕事 | 内容 |
|---|---|
| タグを付ける | その neighbor から受信した経路に SoO を付ける |
| 広告を止める | その SoO を持つ経路を、その neighbor へ広告しない |
本ラボでは、site1 に 65000:1 を割り当て、PE1 の CE-A1 向け neighbor (タグを付ける側) と PE2 の CE-A1b 向け neighbor (広告を止める側) の両方に設定します。§5.4 の設定に出ていた neighbor 172.30.11.2 soo 65000:1 と neighbor 172.30.12.2 soo 65000:1 がそれです。
適用後、PE1 が持つ経路に SoO が付きます。
! ===== [PE1] show bgp vpnv4 unicast all 192.168.10.0/24 ===== (SoO 適用後・経路に SoO が付いた)
BGP routing table entry for 65000:100:192.168.10.0/24, version 12
Paths: (1 available, best #1, table CUST-A)
Advertised to update-groups:
1
Refresh Epoch 4
65100
172.30.11.2 (via vrf CUST-A) from 172.30.11.2 (10.0.0.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: SoO:65000:1 RT:65000:100
mpls labels in/out 19/nolabel
rx pathid: 0, tx pathid: 0x0
Updated on Aug 25 2026 15:56:22 UTC
BGP routing table entry for 65000:200:192.168.10.0/24, version 3
Paths: (1 available, best #1, table CUST-B)
Advertised to update-groups:
1
Refresh Epoch 1
65200
172.30.11.2 (via vrf CUST-B) from 172.30.11.2 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:65000:200
mpls labels in/out 20/nolabel
rx pathid: 0, tx pathid: 0x0
Updated on Aug 25 2026 07:00:17 UTCExtended Community: SoO:65000:1 RT:65000:100 の行が、CE-A1 から受け取った 192.168.10.0/24 に付いた SoO です。同じ出力の後半にある 65000:200:192.168.10.0/24 (顧客 B の同名 prefix) には RT:65000:200 しか付いていません。設定したのは CUST-A の 1 セッションだけなので、顧客 B は影響を受けません。
CE-A1b の側を見ます。
! ===== [CE-A1b] show ip bgp 192.168.10.0/24 ===== (SoO 適用後・サイトへ戻らなくなった)
% Network not in tableサイト自身の経路が戻らなくなりました。 PE2 の広告内容も 1 本に減っています。
! ===== [PE2] show ip bgp vpnv4 vrf CUST-A neighbors 172.30.12.2 advertised-routes ===== (SoO 適用後・広告が止まった)
BGP table version is 11, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:100 (default for vrf CUST-A)
*> 192.168.20.0 172.30.22.2 0 0 65100 i
Total number of prefixes 1 Total number of prefixes が 2 から 1 になり、192.168.10.0 の行が消えています。残った 192.168.20.0 は site2 の CE-A2 から受け取った経路です。 PE2 の CE-A2 向け neighbor には soo を設定していない (§5.4) ので、この経路に SoO は付いておらず、site1 の CE-A1b へ広告され続けます。
site2 の CE-A2 も影響を受けていません。
! ===== [CE-A2] show ip bgp 192.168.10.0/24 ===== (site2 は影響を受けていない)
BGP routing table entry for 192.168.10.0/24, version 3
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
65000 65000
172.30.22.1 from 172.30.22.1 (3.3.3.3)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on Aug 25 2026 15:56:22 UTC本ラボが実測したのは、ここまでです。 すなわち「サイト自身の経路が、そのサイトの CE へ広告されなくなった」という広告の有無です。転送のループそのものは再現していません。 SoO がどのような条件でループを防いでいるかという機構の説明は RFC 4364 由来の記述であり、本ラボの実測とは区別します (§11)。
10. 実測: 同じアドレスが別の相手に届く
最後に、顧客 A と顧客 B が完全に分かれていることをデータプレーンで確かめます。CE-A1 と CE-B1 は、どちらも 192.168.10.1 を持ち、どちらも PE1 の 172.30.11.1 につながっています。この 2 台から同じ宛先 192.168.20.1 へ ping を打ちます。
! ===== [CE-A1] ping 192.168.20.1 source GigabitEthernet3 =====
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/5/9 ms! ===== [CE-B1] ping 192.168.20.1 source Loopback1 =====
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/10 msどちらも 100% で成功します。 送信元アドレスの表示 (Packet sent with a source address of 192.168.10.1) も同じです。この 2 本は、送信元も宛先も同じ文字列でありながら、別々の相手と通信しています。
それを確かめるために、CE-A2 の Loopback1 だけを shutdown します。CE-B2 の Loopback1 (同じ 192.168.20.1) は触りません。
! ===== [CE-A1] ping 192.168.20.1 source GigabitEthernet3 =====
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
.....
Success rate is 0 percent (0/5)! ===== [CE-B1] ping 192.168.20.1 source Loopback1 =====
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/8 ms顧客 A だけが 0% になり、顧客 B は 100% のままです。 同じ 192.168.20.1 が、2 台の別の機器だったことが確定します。
CE-A1 の経路表からも引っ込んでいます。
! ===== [CE-A1] show ip route 192.168.20.0 255.255.255.0 ===== (A 側は経路が引っ込んだ)
% Network not in table10.1 片方の VPN にしか無い網
顧客 B の site2 だけが持つ 192.168.30.0/24 でも同じことを確かめます。まず陽性対照として、顧客 B から届くことを見ます。
! ===== [CE-B1] ping 192.168.30.1 source Loopback1 =====
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.30.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/10 ms顧客 A から打つと届きません。
! ===== [CE-A1] ping 192.168.30.1 source GigabitEthernet3 =====
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.30.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
.....
Success rate is 0 percent (0/5)どこで落ちているかを分けて見ます。まず CE-A1 自身の経路表です。
! ===== [CE-A1] show ip route 192.168.30.0 255.255.255.0 ===== (落下点 = CE-A1 自身の RIB)
% Network not in tableCE-A1 は 192.168.30.0/24 への経路を持っていません。パケットは PE1 まで届かず、CE-A1 の中で捨てられています。 これが落下点です。
そして根本の原因は PE1 の側にあります。
! ===== [PE1] show ip route vrf CUST-A 192.168.30.0 255.255.255.0 ===== (根本原因 = RT が合わないので import されていない)
Routing Table: CUST-A
% Network not in tablePE1 の VRF CUST-A にも 192.168.30.0/24 がありません。この経路は PE2 が RT:65000:200 を付けて広告しています。PE1 はこの経路自体は受け取っており、§6.1 で見たとおり VRF CUST-B の表には載っています。VRF CUST-A が import するのは 65000:100 だけなので、CUST-A の表には入りません。落下点は CE-A1 の RIB、原因は PE1 の VRF CUST-A に経路が無いことという 2 段になります。
11. 落とし穴・補足
tracerouteにコアの P が出てくる理由。 §7.6 の 2 行目に P の 10.10.12.2 が出ています。P は顧客の経路を 1 本も持たない (§7.5) のに、顧客側から打った探査に応答しています。前半の仕掛けは 6-1 §9 で扱った TTL の写しです。mpls ip propagate-ttlは既定で有効なので、入口の PE1 は顧客の IP TTL をラベルの TTL へ写し、コアの各ホップがそれを減らします。探査の TTL は P で尽きます。問題は後半で、P が返す ICMP の宛先は顧客の 192.168.10.1 なのに、P はそのアドレスへの経路を持っていません。 一般に説明される動作は、ラベル付きパケットの TTL が尽きたとき、LSR は作った ICMP を宛先 IP で引き直さず、元のパケットが背負っていたラベルスタックに載せて LSP の先へ流すというものです。ICMP は LSP の終端である PE2 まで進みます。**そこから先をどう戻るのかは、本ラボでは追っていません。**この機構は RFC 3032 §2.3.2「Tunneling Private Addresses through a Public Backbone」 に記述があります (原文は “one can copy the label stack from the original packet to the ICMP message” という書き方で、必須要件としてではなく取りうる方法として示されています)。私用アドレスを公衆網でトンネルしている場合、送信元へ ICMP を返そうにも経路が無いので、元のパケットのラベルスタックを ICMP にコピーしてラベルスイッチする、つまり送信元の方向ではなく元の宛先の方向へ進ませる、という記述です。本節のコアはまさにその状況にあります。本ラボはこの ICMP がどの経路で戻ったかを捕まえていないので、ここは出典どおりの記述にとどめます。 実測として言えるのは、上のtracerouteの表示だけです。- 顧客側から打つ
pingにはsourceの指定が要ります。 本ラボは VRF にredistribute connectedを入れていないので、PE-CE 間のリンク (172.30.11.0/30 など) は VPN に載りません。PE-CE リンク側のアドレス (CE-A1 なら 172.30.11.2) を送信元にすると、相手側に戻り経路が無いので失敗するはずです（本ラボでは試していません）。§10 のpingがすべてsource GigabitEthernet3やsource Loopback1を付けているのは、顧客網側のアドレスを送信元にするためです。redistribute connectedを入れると PE-CE のリンクが両方の RD ブロックに現れるので、§6.2 の出力の見え方も変わります。 show bgp vpnv4 unicast allは顧客のスコープになりません。 §6.2 のとおり、prefix の文字列で探すと RD の違う 2 つのエントリに当たります。1 顧客だけを見たいときはshow ip route vrf <VRF>やshow bgp vpnv4 unicast vrf <VRF>を使うか、RD ブロック単位で読みます。- SoO は受信の時点で付くので、既に学習済みの経路には遡りません。 設定を投入しただけでは経路に SoO が現れず、受信し直し (route refresh によるソフトリセット) が要ります。本ラボで受理された語順は
clear bgp vrf <VRF> ipv4 unicast <neighbor> inで、clear bgp vpnv4 unicast vrf ...やclear ip bgp vrf ...はいずれも% Invalid inputで拒否されました。 - 同じ neighbor アドレスが 2 つの VRF に居るので、neighbor 単位のコマンドには
vrfを明示します。 本ラボの 172.30.11.2 は CUST-A の CE-A1 と CUST-B の CE-B1 の両方です。vrfを省くと、どちらを指しているか決まりません。 - 拡張 community の表示順を判定に使わないでください。 §9.2 の出力は
SoO:65000:1 RT:65000:100の順で、SoO が RT より前に出ています。順序を前提にした読み取りは、別の組み合わせで崩れます。 show ip bgp <prefix>はステータスコードの列を印字しません。 §9.1 のr>(RIB-failure) はテーブル形式のshow ip bgpでしか見えず、prefix を指定した形式ではPaths:の行にRIB-failure(NN)として出ます。同じ状態を見るのに 2 つの表示形式が要ります。- PE ごとに違う RD を使う運用があります。 本ラボは VRF ごとに RD を 1 つ割り当て、PE1 と PE2 で同じ値を使いました。実運用では PE ごとに RD を変え、同じ顧客網が複数の PE から別々の VPNv4 経路として広告されるようにする設計があります。本ラボではこの構成を検証していません。
- SoO のループ発生条件は本ラボの実測ではありません。 §9.2 のとおり、実測したのは広告の有無だけです。「SoO が無いと転送のループが起きる」という機構の説明は RFC 4364 由来のもので、本ラボは転送のループを再現していません。
- ラベルの値のローカル性は内ラベルでも変わりません。 §7.7 のとおり、PE1 が配った 19 と PE2 が配った 19 は別のものです。値の一致から何かを読み取ろうとしないでください。
- 収束を待つために打った操作を明かしておきます。 SoO と RT import の変更では、反映を促すために
clear bgp vrf <VRF> ipv4 unicast <neighbor> inまたは... outを打っています。本節の「適用後」の出力は、その後の状態です。as-override については、本ラボは clear の要否を確かめていません。 撮影に使ったスクリプトは as-override の投入直後にも同じclearを 3 本送りますが、この出力を撮った実行では語順を誤っていて機器に拒否されており (正しい語順は上のとおり)、経路は待っているうちに入れ替わりました。clear が無ければ入れ替わらなかったのかどうかは分かりません。 - ラベルを 2 枚積むと 8 バイト増えます。 実運用ではコア側の MTU に余裕が要り、足りなければフラグメントか PMTUD の問題になります。本ラボは MTU を既定のまま触っておらず、この影響は測っていません。
- 本節に掲載していない確認が 3 つあります。
clearの語順を確かめたときの% Invalid input、show cdpの% CDP is not enabled、そして SoO を投入した直後に経路へ反映されていなかったこと — この 3 つは作業中に画面で確認したもので、掲載した出力には含めていません。 - csr1000v (CML) は CDP が既定で無効です。
show cdpは% CDP is not enabledを返します。本ラボはアドレスを意図的に重ねているため、配線の照合は LDP の discovery と PE-CE の対向 AS 番号で行いました (§5.2)。
12. 次節
本節では、1 つの MPLS 網の上に顧客ごとの経路表を載せる L3VPN を追いました。VRF が 1 台の中で経路表を分け、RD が同じ prefix を 2 本のまま運べる形にし、RT が入れ先を決めること。パケットにはラベルが 2 枚積まれ、外は道順を、内は誰の経路表かを表すこと。PHP が外すのは最上段の 1 枚だけで、内ラベルが残るから PE2 は顧客を取り違えないこと。そしてコアの P は顧客 VRF も顧客経路も BGP セッションも持たないまま、顧客のパケットを運んでいること。PE-CE 間では同一 AS の設計を as-override が通し、その代償として外れるサイト単位の守りを SoO が補うこと。ただし SoO について実機で確かめたのは、サイト自身の経路がそのサイトへ広告されなくなるところまでです (§9.2)。転送のループそのものは再現していません。
ここまでの 2 節が扱ったのは、事業者が用意した網です。顧客は PE に接続し、経路表の分離も経路の運搬も事業者側の設定に委ねていました。
次節 6-3 Cisco SD-WAN 概要では、拠点側の機器がオーバーレイを張って拠点間を結ぶ方式へ移ります。vManage / vSmart / vBond / cEdge という 4 種類の構成要素がそれぞれどの平面を担当するのか、そして本節までの事業者網主導の分離と何が入れ替わるのかを見ていきましょう。