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

MPLS VPNのハブアンドスポーク

目次

MPLS VPNのハブアンドスポーク

ハブアンドスポークは、拠点同士の通信を必ず中央拠点（ハブ）を経由させる形です。拠点間を直接通さず、ハブに置いたファイアウォールや検査装置を必ず通したい、といった要件で使います。

RFC 4364の4.3.5は、RTを2つ使ってこの形を作る方法を述べています。

Alternatively, suppose one desired, for whatever reason, to create a “hub and spoke” kind of VPN. This could be done by the use of two Route Target values, one meaning “Hub” and one meaning “Spoke”. At the VRFs attached to the hub sites, “Hub” is the Export Target and “Spoke” is the Import Target. At the VRFs attached to the spoke site, “Hub” is the Import Target and “Spoke” is the Export Target.

ハブは「Hub」をexportして「Spoke」をimport、スポークは逆にします。スポーク同士は互いのexportをimportしないので、直接は届きません。RTの付け方だけでここまではできて、その部分はMPLS VPNのRTによる経路制御で扱っています。

この記事が扱うのはその先です。 直接届かないだけでは、拠点同士はまったく通信できません。ハブを折り返して通すところまでを作ります。

折り返すにはハブ側にVRFが2つ要る

スポークの経路をハブのVRFにimportしても、その経路がもう一度VPNv4へ出ていくことはありません。VPNv4の経路はPE同士のiBGPで配られ、BGPはiBGPで学んだ経路を別のiBGPピアへ渡さないからです。ハブのVRFに入った時点で、その経路は行き止まりになります。

折り返すには、経路をいったんVPNの外へ出して、戻してもらうしかありません。

  1. ハブPEがスポークの経路をVRFにimportし、ハブCEへ広告する
  2. ハブCEがそれを別のセッションで広告し返す
  3. ハブPEが受け取り、スポーク向けのRTを付けてVPNv4へ出す

(2)が別のセッションである点が効きます。BGPは、ある経路を学んだピアに対してその経路を広告しないので、1本のセッションでは戻ってきません。ハブCEとは2本のeBGPを張ります。

そのうえで、受ける側と出す側でRTの向きが逆になるため、ハブPEはVRFを2つ持ちます。片方はスポークの経路を受け取るだけ（importだけ）、もう片方は戻ってきた経路を出すだけ（exportだけ）です。RDも別にします。

戻る経路はAS_PATHで2回ふるいにかけられる

折り返す経路は、ハブCEを通る間にAS番号が2つ積まれます。スポークCEが広告した時点では空でも、スポークPEとハブPEが同じAS（この構成では65001）を通るため、ハブCEが受け取る時点で65001 65102、ハブCEが広告し返す時点で65101 65001 65102になります。この65001が2か所でふるいにかけられます。

1つ目は送る側です。 BGPは、相手のAS番号がAS_PATHに入っている経路を、そのピアへ広告しません。ハブCEから見た相手（ハブPE）のASは65001で、それはAS_PATHにすでに入っているので、ハブCEは戻そうとしません。同じ挙動はMPLS VPNで複数拠点が同じAS番号を使う場合で、PEがCEへ広告しない形として確認しています。今回は役が入れ替わって、送らない側がハブCEになります。

なお、この送信側の抑止はRFC 4271の9.2（Update-Send Process）には書かれていません。規定ではなく実装の動作で、装置によって挙動が違うことがあります。RFCが定めているのは次に挙げる受信側だけです。

これを開けるのがlocal-asです。ハブPEのセッションに別のAS番号を名乗らせると、ハブCEから見た相手のASがその番号になり、AS_PATHに含まれなくなります。名乗らせた番号は、ハブPEが受け取る経路のAS_PATHの先頭にも積まれます。

2つ目は受け取る側です。 RFC 4271の9.1.2は、受け取った経路のAS_PATHに自分のAS番号があれば、その経路を最適経路選択から外すと定めています。

If the AS_PATH attribute of a BGP route contains an AS loop, the BGP route should be excluded from the Phase 2 decision function. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. Operations of a BGP speaker that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document.

ハブCEが戻した経路のAS_PATHには65001が入っているので、ハブPEはこれに当たります。最後の1文が「自分のAS番号が入った経路をあえて受け入れる設定は、この文書の範囲外である」と断っていて、その設定がallowas-inです。

検証構成

顧客Aは中央拠点（CE-HUB）と2つの拠点（CE-SP1 / CE-SP2）です。2つの拠点は別々の PE に置いてあります。 同じ PE の同じ VRF に並べると RT の設定に関係なく通信できてしまうためです。PE-CE は eBGP で、CE ごとに別の AS（65101 / 65102 / 65103）にしてあります。同じ AS にすると as-override の話が混ざり、再広告の条件だけを見られなくなるからです。

ハブ PE（PE1）だけが VRF を2つ持ちます。CUST-A-HUBIN は 65001:1001 を import するだけ、CUST-A-HUBOUT は 65001:1000 を export するだけです。スポーク側の CUST-A はその逆で、65001:1001 を export して 65001:1000 を import します。

day-0 の設定には allowas-in も local-as も入れていません。 どちらが要るのかを1つずつ足して確かめます。

STEP操作確かめること
0初期状態（allowas-in も local-as も無し）ハブ CE は (1) で受け取るが、(2) へは自分の経路しか戻さない
1PE1 の hub-out ネイバーに allowas-in 2変わらない。受け取る側の設定なので、送る側が出していなければ効かない
2PE1 の hub-out に local-as 65011 ＋ ハブ CE 側を remote-as 65011 にハブ CE が戻すようになる。拠点間の ping が通り、traceroute にハブ CE が出る
3PE2 / PE3 の vpnv4 ネイバーに allowas-in 2変わらない。STEP 2 で既に届いているので、スポーク側には要らない
4PE1 の hub-out の allowas-in を外すハブ CE は送り続けるのに届かない。止まっているのは受け取る側
5allowas-in を戻す（最終状態）元に戻る

ハブCEは受け取るが、戻さない

初期状態で、ハブCEの BGP テーブルには両方の拠点の経路が入っています。リンク (1) から受け取ったものです。

STEP 0 CE-HUB の BGP テーブル
RP/0/RP0/CPU0:CE-HUB#show bgp
Thu Oct 15 12:57:45.797 UTC
BGP router identifier 11.11.11.11, local AS number 65101
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 9
BGP main routing table version 9
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 10.1.1.1/32        0.0.0.0                  0         32768 i
*> 10.1.2.1/32        172.16.1.1                             0 65001 65102 i
*> 10.1.3.1/32        172.16.1.1                             0 65001 65103 i
*> 172.16.1.0/24      172.16.1.1               0             0 65001 ?
*> 172.16.2.0/24      172.16.1.1                             0 65001 ?
*> 172.16.3.0/24      172.16.1.1                             0 65001 ?
*> 172.16.5.0/24      172.16.5.1               0             0 65001 ?

Processed 7 prefixes, 7 paths

ところが、リンク (2) へ広告しているのは自分の 10.1.1.1/32 だけです。

STEP 0 CE-HUB が (2) の PE1 へ広告している経路
RP/0/RP0/CPU0:CE-HUB#show bgp neighbors 172.16.5.1 advertised-routes
Thu Oct 15 12:57:48.382 UTC
Network            Next Hop        From            AS Path
10.1.1.1/32        172.16.5.2      Local           65101i

Processed 1 prefixes, 1 paths

拠点の経路の AS_PATH には、PE の AS である 65001 が入っています。広告先のハブ PE もその AS なので、ハブCEは送りません。接続経路（172.16.1.0/24 など）も PE の redistribute connected 由来で同じ AS が付くため、同じ理由で出ていません。

拠点1から拠点2へは届きません。

STEP 0 CE-SP1 から CE-SP2 への ping
RP/0/RP0/CPU0:CE-SP1#ping 10.1.3.1 source 10.1.2.1 count 10 timeout 1
Thu Oct 15 12:54:59.412 UTC
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.3.1 timeout is 1 seconds:
..........
Success rate is 0 percent (0/10)

allowas-inだけでは何も変わらない

ハブ PE の (2) 側のネイバーに allowas-in を入れます。

STEP 1 PE1 に投入した設定
router bgp 65001
 vrf CUST-A-HUBOUT
  neighbor 172.16.5.2
   address-family ipv4 unicast
    allowas-in 2
   !
  !
 !
!
end
STEP 1 CE-HUB が (2) の PE1 へ広告している経路
RP/0/RP0/CPU0:CE-HUB#show bgp neighbors 172.16.5.1 advertised-routes
Thu Oct 15 13:03:37.786 UTC
Network            Next Hop        From            AS Path
10.1.1.1/32        172.16.5.2      Local           65101i

Processed 1 prefixes, 1 paths

変わりません。 allowas-in は受け取る側の設定で、送る側が出していない段階では効きません。

local-asで送信側が開く

ハブ PE の (2) 側のネイバーに local-as 65011 を入れ、ハブCE側はそのネイバーの remote-as を 65011 に変えます。

STEP 2 PE1 に投入した設定
router bgp 65001
 vrf CUST-A-HUBOUT
  neighbor 172.16.5.2
   local-as 65011
  !
 !
!
end
STEP 2 CE-HUB に投入した設定
router bgp 65101
 neighbor 172.16.5.1
  remote-as 65011
 !
!
end

ハブCEから見た相手の AS が 65011 になり、AS_PATH の 65001 と重ならなくなりました。拠点の経路が広告されます。

STEP 2 CE-HUB が (2) の PE1 へ広告している経路
RP/0/RP0/CPU0:CE-HUB#show bgp neighbors 172.16.5.1 advertised-routes
Thu Oct 15 13:10:42.637 UTC
Network            Next Hop        From            AS Path
10.1.1.1/32        172.16.5.2      Local           65101i
10.1.2.1/32        172.16.5.2      172.16.1.1      65101 65001 65102i
10.1.3.1/32        172.16.5.2      172.16.1.1      65101 65001 65103i
172.16.1.0/24      172.16.5.2      172.16.1.1      65101 65001?
172.16.2.0/24      172.16.5.2      172.16.1.1      65101 65001?
172.16.3.0/24      172.16.5.2      172.16.1.1      65101 65001?

Processed 6 prefixes, 6 paths

キャプチャーにも出ています。添付の STEP 2 の (2) 側のキャプチャーの No.17 に6つの UPDATE が入っていて、そのうち 10.1.3.1/32 を載せたものがこれです。

STEP 2 No.17 CE-HUB → PE1 の UPDATE（tshark -V の抜粋）
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 62
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 39
    Path attributes
        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: 14
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 172.16.5.2
                IPv4 Address: 172.16.5.2
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                10.1.3.1/32
                    MP Reach NLRI prefix length: 32
                    MP Reach NLRI IPv4 prefix: 10.1.3.1
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65101 65001 65103 
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: AS_PATH (2)
            Length: 14
            AS Path segment: 65101 65001 65103
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 3
                AS4: 65101
                AS4: 65001
                AS4: 65103
上のtshark出力のパケット（No.17 UPDATE）のpcapをダウンロード

ハブ PE は、自分の AS が入ったこの経路を allowas-in で受け取ります。local-as の分が先頭に積まれて 65011 65101 65001 65103 になっています。

STEP 2 PE1 が (2) で受け取った経路
RP/0/RP0/CPU0:PE1#show bgp vrf CUST-A-HUBOUT neighbors 172.16.5.2 received routes
Thu Oct 15 13:08:50.015 UTC
BGP VRF CUST-A-HUBOUT, state: Active
BGP Route Distinguisher: 65001:12
VRF ID: 0x60000003
BGP router identifier 1.1.1.1, local AS number 65001
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000003   RD version: 30
BGP main routing table version 30
BGP NSR Initial initsync version 13 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:12 (default for vrf CUST-A-HUBOUT)
Route Distinguisher Version: 30
*  10.1.1.1/32        172.16.5.2               0             0 65011 65101 i
*  10.1.2.1/32        172.16.5.2                             0 65011 65101 65001 65102 i
*  10.1.3.1/32        172.16.5.2                             0 65011 65101 65001 65103 i
*  172.16.1.0/24      172.16.5.2                             0 65011 65101 65001 ?
*  172.16.2.0/24      172.16.5.2                             0 65011 65101 65001 ?
*  172.16.3.0/24      172.16.5.2                             0 65011 65101 65001 ?

Processed 6 prefixes, 6 paths

拠点1の BGP テーブルに相手の拠点の経路が入りました。

STEP 2 CE-SP1 の BGP テーブル
RP/0/RP0/CPU0:CE-SP1#show bgp
Thu Oct 15 13:10:58.180 UTC
BGP router identifier 12.12.12.12, local AS number 65102
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 11
BGP main routing table version 11
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 10.1.1.1/32        172.16.2.1                             0 65001 65011 65101 i
*> 10.1.2.1/32        0.0.0.0                  0         32768 i
*> 10.1.3.1/32        172.16.2.1                             0 65001 65011 65101 65001 65103 i
*> 172.16.1.0/24      172.16.2.1                             0 65001 65011 65101 65001 ?
*> 172.16.2.0/24      172.16.2.1               0             0 65001 ?
*> 172.16.3.0/24      172.16.2.1                             0 65001 65011 65101 65001 ?
*> 172.16.5.0/24      172.16.2.1                             0 65001 ?

Processed 7 prefixes, 7 paths

ping も通ります。

STEP 2 CE-SP1 から CE-SP2 への ping
RP/0/RP0/CPU0:CE-SP1#ping 10.1.3.1 source 10.1.2.1 count 10 timeout 1
Thu Oct 15 13:08:13.957 UTC
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.3.1 timeout is 1 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 22/25/35 ms

traceroute にハブCEが出ます。 4ホップ目の 172.16.5.2 がハブCEで、5ホップ目の 172.16.1.1 はハブ PE のリンク (1) 側です。パケットがハブ PE から出てハブCEを折り返し、もう一方のリンクから戻っています。

STEP 2 CE-SP1 から CE-SP2 への traceroute
RP/0/RP0/CPU0:CE-SP1#traceroute 10.1.3.1 source 10.1.2.1 timeout 1 probe 2 maxttl 6
Thu Oct 15 13:08:16.111 UTC

Type escape sequence to abort.
Tracing the route to 10.1.3.1

 1  172.16.2.1 6 msec  5 msec 
 2  10.0.23.3 [MPLS: Labels 24000/24010 Exp 0] 13 msec  12 msec 
 3  10.0.13.1 [MPLS: Label 24010 Exp 0] 11 msec  12 msec 
 4  172.16.5.2 12 msec  12 msec 
 5  172.16.1.1 15 msec  12 msec 
 6  10.0.13.3 [MPLS: Labels 24002/24006 Exp 0] 23 msec  22 msec

6ホップで打ち切る指定（maxttl 6）なので CE-SP2 までは出ていませんが、到達することは上の ping が示しています。

スポーク側のPEには要らない

ハブCEが戻した経路の AS_PATH には 65001 が残ったまま、VPNv4 でコアを渡ります。受け取るスポーク側の PE も AS 65001 なので、そこでも落ちる可能性があります。確かめるために、スポーク側の PE の vpnv4 ネイバーにも allowas-in を入れます。

STEP 3 PE2 に投入した設定
router bgp 65001
 neighbor 1.1.1.1
  address-family vpnv4 unicast
   allowas-in 2
  !
 !
!
end
STEP 3 CE-SP1 から CE-SP2 への ping
RP/0/RP0/CPU0:CE-SP1#ping 10.1.3.1 source 10.1.2.1 count 10 timeout 1
Thu Oct 15 13:13:52.674 UTC
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.3.1 timeout is 1 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 21/25/41 ms

変わりません。 STEP 2 の時点ですでに届いていたので、この設定は要りません。AS ループの検査が効くのは eBGP で受け取るところで、iBGP の vpnv4 では落ちていない、ということです。

allowas-inを外すと受信側で止まる

ハブ PE の (2) 側から allowas-in だけを外します。local-as は残します。

STEP 4 PE1 に投入した設定
router bgp 65001
 vrf CUST-A-HUBOUT
  neighbor 172.16.5.2
   address-family ipv4 unicast
    no allowas-in 2
   !
  !
 !
!
end

ハブCEは送り続けています。

STEP 4 CE-HUB が (2) の PE1 へ広告している経路
RP/0/RP0/CPU0:CE-HUB#show bgp neighbors 172.16.5.1 advertised-routes
Thu Oct 15 13:23:41.692 UTC
Network            Next Hop        From            AS Path
10.1.1.1/32        172.16.5.2      Local           65101i
10.1.2.1/32        172.16.5.2      172.16.1.1      65101 65001 65102i
10.1.3.1/32        172.16.5.2      172.16.1.1      65101 65001 65103i
172.16.1.0/24      172.16.5.2      172.16.1.1      65101 65001?
172.16.2.0/24      172.16.5.2      172.16.1.1      65101 65001?
172.16.3.0/24      172.16.5.2      172.16.1.1      65101 65001?

Processed 6 prefixes, 6 paths

それでもハブ PE には1本しか入りません。 残っているのは AS_PATH に 65001 を含まない 10.1.1.1/32 だけです。

STEP 4 PE1 が (2) で受け取った経路
RP/0/RP0/CPU0:PE1#show bgp vrf CUST-A-HUBOUT neighbors 172.16.5.2 received routes
Thu Oct 15 13:21:47.061 UTC
BGP VRF CUST-A-HUBOUT, state: Active
BGP Route Distinguisher: 65001:12
VRF ID: 0x60000003
BGP router identifier 1.1.1.1, local AS number 65001
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000003   RD version: 35
BGP main routing table version 35
BGP NSR Initial initsync version 13 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:12 (default for vrf CUST-A-HUBOUT)
Route Distinguisher Version: 35
*  10.1.1.1/32        172.16.5.2               0             0 65011 65101 i

Processed 1 prefixes, 1 paths

このネイバーには soft-reconfiguration inbound always が入っていて、入力ポリシーを通る前の生の経路が保持されます。その received routes にすら出ていないので、届いていないのではなく、届いたものを受け取っていないということです。落としているのは、記事の前半で引いた RFC 4271 の9.1.2の検査にあたります。なお、破棄の瞬間を数えるカウンタはこの検証では取得していません（このネイバーの show bgp ... neighbors <ピア> を採っていないため）。ここで示せるのは、送った側の6本と受け取った側の1本という対比までです。

拠点間の疎通も切れます。

STEP 4 CE-SP1 から CE-SP2 への ping
RP/0/RP0/CPU0:CE-SP1#ping 10.1.3.1 source 10.1.2.1 count 10 timeout 1
Thu Oct 15 13:20:49.884 UTC
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.3.1 timeout is 1 seconds:
..........
Success rate is 0 percent (0/10)

local-as と allowas-in は、どちらか一方では足りません。 送信側の壁と受信側の壁は別々にあり、両方を開けて初めてハブCEの再広告が成立します。

検証Configおよびshow結果

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

ファイル内容
..._show.txtshow version / show interface description / OSPF・LDP・BGP・VRFの各showなど
..._log.txtそのSTEPの範囲だけに絞ったshow logging
..._run.txtそのSTEP時点のshow running-config（＝そのSTEPの検証Config）
..._ping.txtそのSTEPのpingとtraceroute（全CEから全CEへ）
..._trace.txtshow bgp trace（PEのみ）
..._commit.cfgそのSTEPで実際にcommitされた設定（変更したルータのみ）

STEP 0：初期状態（allowas-in も local-as も無し）

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-HUBshowlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE-SP1showlogrunping--
PE3showlogrunpingtrace-
CE-SP2showlogrunping--

STEP 1：PE1 の hub-out ネイバーに allowas-in 2

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-HUBshowlogrunping--
PE1showlogrunpingtracecommit
P1showlogrunping--
PE2showlogrunpingtrace-
CE-SP1showlogrunping--
PE3showlogrunpingtrace-
CE-SP2showlogrunping--

STEP 2：PE1 の hub-out に local-as 65011 ＋ ハブ CE 側を remote-as 65011 に

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-HUBshowlogrunping-commit
PE1showlogrunpingtracecommit
P1showlogrunping--
PE2showlogrunpingtrace-
CE-SP1showlogrunping--
PE3showlogrunpingtrace-
CE-SP2showlogrunping--

STEP 3：PE2 / PE3 の vpnv4 ネイバーに allowas-in 2

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-HUBshowlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-SP1showlogrunping--
PE3showlogrunpingtracecommit
CE-SP2showlogrunping--

STEP 4：PE1 の hub-out の allowas-in を外す

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-HUBshowlogrunping--
PE1showlogrunpingtracecommit
P1showlogrunping--
PE2showlogrunpingtrace-
CE-SP1showlogrunping--
PE3showlogrunpingtrace-
CE-SP2showlogrunping--

STEP 5：allowas-in を戻す（最終状態）

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-HUBshowlogrunping--
PE1showlogrunpingtracecommit
P1showlogrunping--
PE2showlogrunpingtrace-
CE-SP1showlogrunping--
PE3showlogrunpingtrace-
CE-SP2showlogrunping--

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

STEPPE1-CE-HUB間（(2) 側）PE1-P1間
0pcappcap
1pcappcap
2pcappcap
3pcappcap
4pcappcap
5pcappcap

まとめ