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

MPLS VPNのPE-CEルーティング（スタティック）

目次

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

PEは、CEにつながる回線ごとにその先にどのアドレスがあるかを知る必要があります。RFC 4364の7はこう書いています。

The PE routers that attach to a particular VPN need to know, for each attachment circuit leading to that VPN, which of the VPN’s addresses should be reached over that attachment circuit.

PEはそれをVPN-IPv4の経路に変換してBGPに入れます。サイトの経路がコアのIGPに入ることはありません。

Routes from a VPN site are NOT leaked into the backbone’s IGP.

この「知る方法」がPE-CEルーティングで、RFC 4364はスタティック・RIP・OSPF・eBGPを挙げています。この記事はいちばん単純なスタティックを扱います。CE側はPE向けのデフォルトルートを1本持つだけで、MPLSもBGPも動かしません。

スタティックが向くのはstub VPN

RFC 4364の7は、スタティックの適用範囲をはっきり限定しています。

  1. Static routing (i.e., configuration) may be used. (This is likely to be useful only in stub VPNs.)

stub VPNとtransit VPNの違いは、VPNの外から経路を受け取ってPEへ再配布するルータがサイトにいるかどうかです。

A “transit VPN” is one that contains a router that receives routes from a “third party” (i.e., from a router that is not in the VPN, but is not a PE router) and that redistributes those routes to a PE router. A VPN that is not a transit VPN is a “stub VPN”.

サイトの中で経路が閉じていれば、PEに書くべきプレフィックスの一覧は固定されます。外から来る経路を中継するサイトでは一覧が動くので、スタティックでは追随できません。RFC 4364は、企業のネットワークを含む大多数のVPNはstubだと述べています。

IOS XRでの書き方

設定は2つに分かれます。VRFごとのスタティックを書くことと、それをMP-BGPに載せることです。

PEの設定（IOS XR）
router static
 vrf CUST-A
  address-family ipv4 unicast
   10.1.2.0/24 172.16.2.2
   10.1.3.0/24 172.16.2.2
  !
 !
!
router bgp 65001
 vrf CUST-A
  rd 65001:1
  address-family ipv4 unicast
   redistribute static
   redistribute connected
  !
 !
!
設定役割
router staticのvrf CUST-AそのVRFの経路表にスタティックを入れる
redistribute staticVRFのスタティックをVPNv4として広告する
redistribute connectedPE-CEリンクのような接続経路を広告する

VRFに書いただけでは相手のPEには届きません。 VRFの経路表とMP-BGPは別のものなので、redistributeで明示的に橋渡しします。

CE側はPE向けのデフォルトだけです。相手サイトのプレフィックスを個別に書く必要はありません。

CEの設定（IOS XR）
router static
 address-family ipv4 unicast
  0.0.0.0/0 172.16.2.1
 !
!

出力インタフェースを書くと、そのインタフェースに紐づく

宛先のあとに書けるのは、ネクストホップだけではありません。

書き方例経路が有効な条件
ネクストホップのみ10.1.3.0/24 172.16.2.2ネクストホップが解決できること
出力インタフェース＋ネクストホップ10.1.2.0/24 GigabitEthernet0/0/0/0 172.16.2.2そのインタフェースがupで、かつネクストホップが解決できること
出力インタフェースのみ10.1.2.0/24 GigabitEthernet0/0/0/0そのインタフェースがupであること（point-to-point向け）

出力インタフェースを書くと、その経路はインタフェースの状態に直結します。 そのため、該当のインタフェースをshutdownするだけでその経路を無効にでき、予備の経路へ迂回させられます。計画的な保守でリンクを片側だけ外すときや、障害時に予備へ寄せたいときに使う手です。

予備は、同じ宛先にアドミニストレーティブディスタンス（AD）を大きくして書きます（フローティングスタティック）。

主と予備を書いたPE2のスタティック
router static
 vrf CUST-A
  address-family ipv4 unicast
   10.1.2.0/24 GigabitEthernet0/0/0/0 172.16.2.2
   10.1.2.0/24 GigabitEthernet0/0/0/2 172.16.4.2 200
  !
 !
!

ADの小さい主の経路だけが経路表に入り、主のインタフェースがdownすると予備が入ります。このときVPNから見えるプレフィックスは変わらないので、相手のPEには何も起きません。VPNv4の広告は続いたまま、PE2の中で出口が変わるだけです。

redistribute connected を入れるかどうか

redistribute connectedは、そのVRFに属するインタフェースのサブネット（＝PE-CEリンク）をVPNに広告します。入れないと、相手サイトからPE-CEリンクのアドレスへは届きません。

入れる入れない
リンクのアドレスへpingやtracerouteが通り、障害の切り分けがしやすいプロバイダのリンクのアドレスを顧客のVPNに出さずに済む

アドレス設計とどこまで顧客に見せるかで決まります。

スタティックの限界

スタティックは宛先に届くかどうかを見ていません。 書いてあれば経路表に入り、PEはそれを広告し続けます。経路が消えるのは、ネクストホップが解決できなくなったときと、書いた出力インタフェースがdownしたときだけです。

起きたことPEのスタティックVPNv4の広告
サイトのLANが消えた残る残る
CEが落ちた（PE側のリンクはup）残る残る
PE側のリンクがdown（予備なし）消える取り消される
PE側のリンクがdown（予備あり）予備に切り替わる続く

CEが黙って落ちる構成では、PEは経路を広告し続け、パケットはPE-CE間で捨てられます。eBGPやOSPFならセッションや隣接が切れて経路が消えますが、スタティックにはその仕掛けがありません。

項目スタティックの場合
設定の単純さCE側は何も要らない。PEだけで完結する
サイトの経路が増えたときPEの設定を足す必要がある
到達性の検知無い
向く構成stub VPNで、プレフィックスが固定のサイト

検証構成

XRd 5台です。PE2とCE-A2の間は2本にして、主のインタフェースを落として予備へ迂回させるSTEPを作ります。

ノード役割
PE1 / PE2vrf CUST-A（RD 65001:1、RT 65001:100）
P1コアのみ（OSPF area 0 ＋ LDP）
CE-A1サイト1。LAN 10.1.1.0/24
CE-A2サイト2。LAN 10.1.2.0/24と10.1.3.0/24。PE2へ主と予備の2本

day-0ではPEにVRFのスタティックもredistributeも入れていません。 VRF・IGP・LDP・MP-BGPまでが上がった状態から、STEPで1つずつ足していきます。

STEP操作確かめること
0初期状態（VRFのスタティックもredistributeも無い）VPNv4は0本。VRFの経路表は接続経路だけ
1PEにVRFのスタティックを入れるVRFの経路表には入るがVPNv4には出ない
2redistribute staticVPNv4に載り、サイト間の疎通が通る
3redistribute connectedPE-CEリンクのサブネットも載る
4CE-A2のLoopback1をshutdown宛先が消えてもスタティックも広告も残る
5Lo1を戻し、CE-A2のGi0/0/0/0をshutdownCEが落ちてもPE2側はupのままで広告が残る
6CE-A2のGi0/0/0/0を戻し、PE2のGi0/0/0/0をshutdownスタティックがRIBから消え、VPNv4が取り消される
7PE2のGi0/0/0/0を戻し、予備の経路（AD 200）を足す予備は経路表に入らない（主が生きているため）
8主リンクの両端をshutdown予備へ切り替わって疎通が続く。広告は取り消されない
9復旧（最終状態）主に戻る

STEP 1：VRFに書いただけでは広告されない

PE2に2本のスタティックを入れます。10.1.2.0/24は出力インタフェース付き、10.1.3.0/24はネクストホップのみです。

PE2：VRFの経路表（STEP 1）
Gateway of last resort is not set

S    10.1.2.0/24 [1/0] via 172.16.2.2, 00:03:00, GigabitEthernet0/0/0/0
S    10.1.3.0/24 [1/0] via 172.16.2.2, 00:03:00
C    172.16.2.0/24 is directly connected, 00:08:35, GigabitEthernet0/0/0/0
L    172.16.2.1/32 is directly connected, 00:08:35, GigabitEthernet0/0/0/0
C    172.16.4.0/24 is directly connected, 00:08:35, GigabitEthernet0/0/0/2
L    172.16.4.1/32 is directly connected, 00:08:35, GigabitEthernet0/0/0/2

書き方の違いはそのまま表示に出ます。10.1.2.0/24の行には出力インタフェース（GigabitEthernet0/0/0/0）が付き、10.1.3.0/24には付きません。

一方、PE1のVPNv4には何も入っていません。

PE1：VPNv4の経路（STEP 1）
RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast
Wed Sep 23 15:39:04.036 UTC

1行も出ません。VRFの経路表とMP-BGPは別物で、redistributeしない限り橋渡しされません。

STEP 2：redistribute staticで広告される

両方のPEにredistribute staticを入れます。

PE1：VPNv4の経路（STEP 2）
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 9
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
*>i10.1.3.0/24        2.2.2.2                  0    100      0 ?

Processed 3 prefixes, 3 paths

PE2が広告した2本と、PE1自身の10.1.1.0/24が入りました。この時点でサイト間のpingが通ります。

STEP 3：redistribute connectedでPE-CEリンクも広告される

PE1：VPNv4の経路（STEP 3）
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 14
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
*>i10.1.3.0/24        2.2.2.2                  0    100      0 ?
*> 172.16.1.0/24      0.0.0.0                  0         32768 ?
*>i172.16.2.0/24      2.2.2.2                  0    100      0 ?
*>i172.16.4.0/24      2.2.2.2                  0    100      0 ?

Processed 6 prefixes, 6 paths

PE-CEリンクの3つのサブネットが増えて6本になりました。違いはCE-A1からリンクのアドレスへのpingに出ます。

CE-A1 → 172.16.2.1（STEP 2）
RP/0/RP0/CPU0:CE-A1#ping 172.16.2.1 source 10.1.1.1 count 10 timeout 1
Wed Sep 23 15:42:16.717 UTC
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 172.16.2.1 timeout is 1 seconds:
..........
Success rate is 0 percent (0/10)
CE-A1 → 172.16.2.1（STEP 3）
RP/0/RP0/CPU0:CE-A1#ping 172.16.2.1 source 10.1.1.1 count 10 timeout 1
Wed Sep 23 15:46:25.434 UTC
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 172.16.2.1 timeout is 1 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 12/14/29 ms

STEP 4・5：スタティックは宛先が生きているかを見ていない

STEP 4でCE-A2のLAN（Loopback1）を落とし、STEP 5ではCE-A2のPE向けインタフェースを落とします。どちらもPE2の経路表は変わりません。

PE2：VRFの経路表（STEP 4、CE-A2のLANを落とした後）
Gateway of last resort is not set

B    10.1.1.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:10:13
S    10.1.2.0/24 [1/0] via 172.16.2.2, 00:14:42, GigabitEthernet0/0/0/0
S    10.1.3.0/24 [1/0] via 172.16.2.2, 00:14:42
B    172.16.1.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:06:04
C    172.16.2.0/24 is directly connected, 00:20:17, GigabitEthernet0/0/0/0
L    172.16.2.1/32 is directly connected, 00:20:17, GigabitEthernet0/0/0/0
C    172.16.4.0/24 is directly connected, 00:20:17, GigabitEthernet0/0/0/2
L    172.16.4.1/32 is directly connected, 00:20:17, GigabitEthernet0/0/0/2

10.1.2.0/24はそのまま残り、VPNv4の広告も6本のままです。届かないのはpingだけです。

CE-A1からのping（STEP 4）
RP/0/RP0/CPU0:CE-A1#ping 10.1.2.1 source 10.1.1.1 count 10 timeout 1
Wed Sep 23 15:50:00.716 UTC
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.2.1 timeout is 1 seconds:
..........
Success rate is 0 percent (0/10)
RP/0/RP0/CPU0:CE-A1#ping 10.1.3.1 source 10.1.1.1 count 10 timeout 1
Wed Sep 23 15:50:15.082 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 = 10/15/38 ms

10.1.2.1は落ちますが、同じCEの10.1.3.1は通ります。STEP 5でCE-A2のインタフェースを落としても、PE2側のインタフェースはupのままなので結果は同じです。PEはCEが落ちたことを知りません。

STEP 6：PE側のリンクが落ちると取り消される

PE2のGi0/0/0/0を落とします。接続経路が消えるとネクストホップが解決できなくなり、スタティックがRIBから消えます。

PE2：VRFの経路表（STEP 6）
Gateway of last resort is not set

B    10.1.1.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:19:33
B    172.16.1.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:15:25
C    172.16.4.0/24 is directly connected, 00:29:38, GigabitEthernet0/0/0/2
L    172.16.4.1/32 is directly connected, 00:29:38, GigabitEthernet0/0/0/2

10.1.2.0/24も10.1.3.0/24も無くなりました。PE1のVPNv4も3本に減っています。

PE1：VPNv4の経路（STEP 6）
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 17
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*> 172.16.1.0/24      0.0.0.0                  0         32768 ?
*>i172.16.4.0/24      2.2.2.2                  0    100      0 ?

Processed 3 prefixes, 3 paths

このときPE2が送ったUPDATEがキャプチャーに残っています。添付のSTEP 6のキャプチャーのNo.31です。

PE2 → PE1 のUPDATE（tshark -V、MP_UNREACH_NLRIの部分）
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 75
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 52
    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: 48
            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.3.0
                BGP Prefix
                    Prefix Length: 112
                    Label Stack: 0 (withdrawn)
                    Route Distinguisher: 65001:1
                    MP Unreach NLRI IPv4 prefix: 10.1.2.0
                BGP Prefix
                    Prefix Length: 112
                    Label Stack: 0 (withdrawn)
                    Route Distinguisher: 65001:1
                    MP Unreach NLRI IPv4 prefix: 172.16.2.0
上のtshark出力のパケット（No.31 UPDATE、経路の取り消し）のpcapをダウンロード

MP_UNREACH_NLRIで3本まとめて取り消されています。

STEP 7・8：出力インタフェースを書いておくと予備へ迂回する

主のリンクを戻し、予備の経路をAD 200で足します。

PE2に投入した設定（STEP 7）
interface GigabitEthernet0/0/0/0
 no shutdown
!
router static
 vrf CUST-A
  address-family ipv4 unicast
   10.1.2.0/24 GigabitEthernet0/0/0/2 172.16.4.2 200
   10.1.3.0/24 172.16.4.2 200
  !
 !
!
end

予備は経路表には現れません。ADの小さい主だけが入ります。

PE2：VRFの経路表（STEP 7）
Gateway of last resort is not set

B    10.1.1.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:23:22
S    10.1.2.0/24 [1/0] via 172.16.2.2, 00:02:22, GigabitEthernet0/0/0/0
S    10.1.3.0/24 [1/0] via 172.16.2.2, 00:02:22
B    172.16.1.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:19:14
C    172.16.2.0/24 is directly connected, 00:02:22, GigabitEthernet0/0/0/0
L    172.16.2.1/32 is directly connected, 00:02:22, GigabitEthernet0/0/0/0
C    172.16.4.0/24 is directly connected, 00:33:27, GigabitEthernet0/0/0/2
L    172.16.4.1/32 is directly connected, 00:33:27, GigabitEthernet0/0/0/2

ここで主リンクの両端を落とします。STEP 5で見たとおり片側だけでは対向のインタフェースがupのままなので、リンク断を作るには両端を落とします。出力インタフェースに紐づいた主の経路が無効になり、予備が入ります。

PE2：VRFの経路表（STEP 8、主リンクを落とした後）
Gateway of last resort is not set

B    10.1.1.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:27:21
S    10.1.2.0/24 [200/0] via 172.16.4.2, 00:02:28, GigabitEthernet0/0/0/2
S    10.1.3.0/24 [200/0] via 172.16.4.2, 00:02:28
B    172.16.1.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:23:12
C    172.16.4.0/24 is directly connected, 00:37:25, GigabitEthernet0/0/0/2
L    172.16.4.1/32 is directly connected, 00:37:25, GigabitEthernet0/0/0/2

距離が[200/0]に変わり、出口がGigabitEthernet0/0/0/2（予備）になりました。疎通は途切れていません。

CE-A1 → 10.1.2.1 のtraceroute（STEP 8）
RP/0/RP0/CPU0:CE-A1#traceroute 10.1.2.1 source 10.1.1.1 timeout 1 probe 2 maxttl 6
Wed Sep 23 16:07:24.228 UTC

Type escape sequence to abort.
Tracing the route to 10.1.2.1

 1  172.16.1.1 5 msec  4 msec 
 2  10.0.13.3 [MPLS: Labels 24001/24003 Exp 0] 25 msec  17 msec 
 3  10.0.23.2 [MPLS: Label 24003 Exp 0] 22 msec  15 msec 
 4  172.16.4.2 18 msec  *

最後のホップが172.16.4.2（予備リンクのCE側）になっています。迂回したことが経路として見えます。

VPN側から見ると何が変わったかは、STEP 6と並べると分かります。

PE1-P1間のBGP UPDATE（STEP 6）
$ tshark -r mpls-vpn-pece-static-step6-pe1p1.pcap -Y 'bgp.type==2' \
    -T fields -e frame.number -e ip.src \
    -e bgp.mp_unreach_nlri_ipv4_prefix -e bgp.mp_reach_nlri_ipv4_prefix
31	2.2.2.2	10.1.3.0,10.1.2.0,172.16.2.0
PE1-P1間のBGP UPDATE（STEP 8）
$ tshark -r mpls-vpn-pece-static-step8-pe1p1.pcap -Y 'bgp.type==2' \
    -T fields -e frame.number -e ip.src \
    -e bgp.mp_unreach_nlri_ipv4_prefix -e bgp.mp_reach_nlri_ipv4_prefix
7	2.2.2.2	172.16.2.0	
9	2.2.2.2		10.1.3.0,10.1.2.0

STEP 6では顧客の経路2本とリンクの1本が取り消されました。STEP 8で取り消されたのは、実際に消えたリンクの172.16.2.0/24だけです。10.1.2.0/24と10.1.3.0/24は取り消されず、同じ内容で送り直されています。相手のPEから見れば経路は生きたままで、PE2の中で出口が変わっただけ、ということです。

STEP 9：復旧

主リンクを戻すと、ADの小さい主の経路が入り直してSTEP 7の状態に戻ります。予備の設定は残したままです。

参考

RFCタイトル参照した節
RFC 4364BGP/MPLS IP Virtual Private Networks (VPNs)7（PEがCEから経路を学ぶ方法、stub VPNとtransit VPN、サイトの経路をIGPに入れないこと）

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

検証Configおよびshow結果

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

ファイル内容
..._show.txtshow route vrf CUST-A / show bgp vpnv4 unicast / show cef vrf CUST-A / show running-config router static など
..._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：初期状態（VRFのスタティックもredistributeも無い）

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE-A2showlogrunping--

STEP 1：PEにVRFのスタティックを入れる

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtracecommit
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A2showlogrunping--

STEP 2：redistribute static

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtracecommit
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A2showlogrunping--

STEP 3：redistribute connected

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtracecommit
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A2showlogrunping--

STEP 4：CE-A2のLoopback1をshutdown

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE-A2showlogrunping-commit

STEP 5：Lo1を戻し、CE-A2のGi0/0/0/0をshutdown

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE-A2showlogrunping-commit

STEP 6：CE-A2のGi0/0/0/0を戻し、PE2のGi0/0/0/0をshutdown

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A2showlogrunping-commit

STEP 7：PE2のGi0/0/0/0を戻し、予備の経路（AD 200）を足す

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A2showlogrunping-commit

STEP 8：主リンクの両端をshutdown

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A2showlogrunping-commit

STEP 9：復旧（最終状態）

ルータshow出力syslogrunning-configpingtrace投入した設定
CE-A1showlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A2showlogrunping-commit

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

STEPPE1-P1間
0pcap
1pcap
2pcap
3pcap
4pcap
5pcap
6pcap
7pcap
8pcap
9pcap

関連記事