MPLSのOAM（LSP Ping / LSP Traceroute）

通常のpingはIPの経路しか試しません。ラベルを積まないので、LSPが壊れていても通ってしまいます。 MPLSのデータプレーンを試すのがLSP Ping（RFC 8029）です。仕組みを解説し、IOS XR（XRd）のラボで実際のパケットを観測します。ラベルの配布はLDPとはで解説しています。

なぜIPのpingでは足りないのか

MPLSでパケットを運ぶとき、入口のPEはトランスポートラベルを積みます。一方IPのpingはラベルを積まずに送るので、IGPの経路だけを試して終わりです。ラベルの転送が壊れていてもIPのpingは成功し、経路表にも異常は出ません。

RFC 8029のタイトルが「Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures」であるとおり、この仕組みが対象にするのはデータプレーンの故障です。制御プレーン（LDP）が「LSPはある」と言っているのに転送が壊れている、という食い違いを見つけます。

LSP Pingの仕組み

LSP PingはMPLS echo requestを、確かめたいLSPのラベルを積んで送ります。受け取った側はMPLS echo replyを返します。

要素	内容
宛先アドレス	127/8（2.1節）。LSPが壊れて途中でIPとして転送されても、外へ出ていかないようにするため。16Mアドレスあるので、ECMPの経路を振り分けるのにも使える
Target FEC Stack	どのFECを確かめているかを入れるTLV。先頭がラベルスタックの最上位に対応する。LDPで配ったIPv4プレフィックスならSub-Type 1
Reply Mode	返し方。2 = IPv4/IPv6のUDPで返すが既定。1は返さない、3はRouter Alert付き、4はアプリケーションレベルの制御チャネル

Target FEC Stackがあることが要点です。 ラベルだけを見て転送すると、途中のLSRが別のFECのラベルと取り違えていても気づけません。「このラベルで運ばれているのは本来このFECのはずだ」という情報を一緒に運ぶので、受け取った側が食い違いを検出できます。

Return Code

応答には結果を表すReturn Codeが入ります。RFCが定めているもののうち、よく使うのは次の3つです。

値	RFC 8029の定義	このラボで観測したか
3	応答したルータがそのFECの出口	観測した（正常なLSPの応答はすべてこれ）
4	そのFECのマッピングが無い	観測していない
8	ラベルスイッチした	観測していない

この記事で実際に出たのは0（リクエスト自身）と3だけです。 4と8はRFCの定義として挙げているだけで、このラボでは再現していません。4や8が出るのは、応答したルータがそのFECを知らない場合や、出口ではなく途中のLSRが応答した場合です。

LSP Traceroute

LSP TracerouteはラベルスタックのTTLを1ずつ増やして送ります。TTLが尽きた位置のLSRが応答するので、ホップごとの状態が分かります。応答にはそのホップで使われるラベルとMRU（最大受信ユニット）が入ります。

通常のIPのtracerouteでは、コアのLSRがどのラベルを使っているかも、どこでPHPが起きているかも見えません。

検証構成

冗長性のない直列構成です。コア（PE1 - P1 - P2 - PE2）でOSPFとLDPを動かし、CE1とCE2はVRF CUST-AでPEに接続してVPNv4で疎通させます。LSP Pingの起点はPE1、確かめるFECはPE2のLoopback（5.5.5.5/32）です。

MPLS-OAMラボ
  CE1 ------ PE1 ------ P1 ------ P2 ------ PE2 ------ CE2
(AS 65101)    |          ^                   |   (AS 65102)
           vrf CUST-A    |                vrf CUST-A
              +------ iBGP vpnv4 (Lo0) ------+
                         STEP 2 で LDP を落とす

ルータ	Lo0	役割	ラベル範囲
CE1	1.1.1.1	AS 65101、192.168.1.0/24	-
PE1	2.2.2.2	入口/出口LSR。LSP Pingの起点	24000 - 24999
P1	3.3.3.3	中継LSR（swap）	33000 - 33999
P2	4.4.4.4	中継LSR（PHP）	44000 - 44999
PE2	5.5.5.5	入口/出口LSR。確かめるFEC	55000 - 55999
CE2	6.6.6.6	AS 65102、192.168.2.0/24	-

ラベルの範囲を装置ごとに分けてあります。 LSP Tracerouteはホップごとに使われるラベルを見せるので、どの装置が配ったラベルかが読めるようにするためです。

検証の全体像

STEP	操作	確かめること
0	初期状態（`mpls oam` 無効）	LSP Pingが使えないこと。IOS XRでは明示的な有効化が要る
1	コア4台で`mpls oam`を有効化	`ping mpls` / `traceroute mpls`が成功。パケットの中身をキャプチャーで確認
2	ACLでPE1 - P1のLDPをdrop	LSP Pingが失敗すること。コア内のIP疎通は通ったままであること
3	ACLを外す	復旧すること
4	P1に静的ラベルを入れて転送だけ壊そうとする	設定では食い違わせられないこと
5	すべて撤去（最終状態）	STEP 0と同じに戻ること

STEP 0：IOS XRでは既定で使えない

有効化していない状態でping mplsを打つと、実行されずに終わります。

STEP 0 PE1 ping mpls ipv4 5.5.5.5/32（mpls oam が無効）
RP/0/RP0/CPU0:PE1#ping mpls ipv4 5.5.5.5/32
Mon Oct 12 03:37:56.859 UTC
% MPLS Embedded Management Subsystem is not running.
To enable, use 'mpls oam' global config command.

OAMを担うサブシステムが動いていないためです。設定は1行で、コア4台すべてに入れます（応答する側にも要ります）。

STEP 1 PE1にcommitした設定
mpls oam
!

STEP 1：正常なLSPを確かめる

有効化すると通ります。verboseを付けると応答ごとにReturn Codeが出ます。出力の冒頭には結果を表す記号の凡例が毎回printされるので、失敗したときはここを見ます。

STEP 1 PE1 ping mpls ipv4 5.5.5.5/32 repeat 2 verbose
RP/0/RP0/CPU0:PE1#ping mpls ipv4 5.5.5.5/32 repeat 2 verbose
Mon Oct 12 03:44:38.956 UTC

Sending 2, 100-byte MPLS Echos to 5.5.5.5/32,
      timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
  'L' - labeled output interface, 'B' - unlabeled output interface,
  'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
  'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
  'P' - no rx intf label prot, 'p' - premature termination of LSP,
  'R' - transit router, 'I' - unknown upstream index,
  'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

!      size 100, reply addr 10.4.5.5, return code 3
!      size 100, reply addr 10.4.5.5, return code 3

Success rate is 100 percent (2/2), round-trip min/avg/max = 14/15/16 ms

return code 3はRFC 8029の「応答したルータがそのFECの出口」です。

tracerouteは各ホップのラベルを見せる

STEP 1 PE1 traceroute mpls ipv4 5.5.5.5/32
RP/0/RP0/CPU0:PE1#traceroute mpls ipv4 5.5.5.5/32
Mon Oct 12 03:44:39.229 UTC

Tracing MPLS Label Switched Path to 5.5.5.5/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
  'L' - labeled output interface, 'B' - unlabeled output interface,
  'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
  'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
  'P' - no rx intf label prot, 'p' - premature termination of LSP,
  'R' - transit router, 'I' - unknown upstream index,
  'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

  0 10.2.3.2 MRU 1500 [Labels: 33003 Exp: 0]
L 1 10.2.3.3 MRU 1500 [Labels: 44003 Exp: 0] 20 ms
L 2 10.3.4.4 MRU 1500 [Labels: implicit-null Exp: 0] 74 ms
! 3 10.4.5.5 80 ms

ホップごとの行が続きます。Lがラベル付きで出て行くホップ、!が到達です。

ラベルの値から、誰が配ったラベルかが読めます。 PE1が積む33003はP1の範囲（33000番台）、P1が張り替える44003はP2の範囲（44000番台）です。ホップ2がimplicit-nullになっているのはP2がPHPでラベルを外すからで、tracerouteの出力からそのまま読み取れます。MRUも各ホップで分かります。

パケットの中身

PE1が送ったecho requestです。

STEP 1 No.856 MPLS Echo Request（PE1 → 127.0.0.1、tshark -V 抜粋）
MultiProtocol Label Switching Header, Label: 33003, Exp: 0, S: 1, TTL: 255
    0000 1000 0000 1110 1011 .... .... .... = MPLS Label: 33003 (0x080eb)
    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0
    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1
    .... .... .... .... .... .... 1111 1111 = MPLS TTL: 255
Internet Protocol Version 4, Src: 10.2.3.2, Dst: 127.0.0.1
    0100 .... = Version: 4
    .... 0110 = Header Length: 24 bytes (6)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 96
    Identification: 0x0000 (0)
    010. .... = Flags: 0x2, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 1
        [Expert Info (Note/Sequence): "Time To Live" only 1]
            ["Time To Live" only 1]
            [Severity level: Note]
            [Group: Sequence]
    Protocol: UDP (17)
    Header Checksum: 0x5884 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 10.2.3.2
    Destination Address: 127.0.0.1
    Options: (4 bytes), Router Alert
        IP Option - Router Alert (4 bytes): Router shall examine packet (0)
            Type: 148
                1... .... = Copy on fragmentation: Yes
                .00. .... = Class: Control (0)
                ...1 0100 = Number: Router Alert (20)
            Length: 4
            Router Alert: Router shall examine packet (0)
    [Stream index: 24]
User Datagram Protocol, Src Port: 3503, Dst Port: 3503
    Source Port: 3503
    Destination Port: 3503
    Length: 72
    Checksum: 0xde86 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 34]
    [Stream Packet Number: 1]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
    UDP payload (64 bytes)
Multiprotocol Label Switching Echo
    Version: 1
    Global Flags: 0x0000
        0000 0000 0000 0... = Reserved: 0x0000
        .... .... .... ...0 = Validate FEC Stack: False
        .... .... .... ..0. = Respond only if TTL expired: False
        .... .... .... .0.. = Validate Reverse Path: False
    Message Type: MPLS Echo Request (1)
    Reply Mode: Reply via an IPv4/IPv6 UDP packet (2)
    Return Code: No return code (0)
    Return Subcode: 0
    Sender's Handle: 0x5aa0c883
    Sequence Number: 1
    Timestamp Sent: Oct 12, 2026 03:44:38.694377462 UTC
    Timestamp Received: Jan  1, 1970 00:00:00.000000000 UTC
    Vendor Private
        Type: Vendor Private (64512)
        Length: 12
        Vendor Id: ciscoSystems (9)
        Value: 0001000400000005
    Target FEC Stack
        Type: Target FEC Stack (1)
        Length: 12
        FEC Element 1: LDP IPv4 prefix
            Type: LDP IPv4 prefix (1)
            Length: 5
            IPv4 Prefix: 5.5.5.5
            Prefix Length: 32

上のtshark出力のパケット（No.856 Echo Request）のpcapをダウンロード

宛先が127.0.0.1、UDPの送信元・宛先ポートがともに3503、ラベルを積んでTTL 255で送っています。Target FEC Stackには確かめたいFEC（5.5.5.5/32）が入っています。Return Codeはリクエストなので0です。

返ってきたecho replyです。

STEP 1 No.857 MPLS Echo Reply（PE2 → PE1、tshark -V 抜粋）
Internet Protocol Version 4, Src: 10.4.5.5, Dst: 10.2.3.2
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 76
    Identification: 0x0000 (0)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 253
    Protocol: UDP (17)
    Header Checksum: 0xa0d4 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 10.4.5.5
    Destination Address: 10.2.3.2
    [Stream index: 25]
User Datagram Protocol, Src Port: 3503, Dst Port: 3503
    Source Port: 3503
    Destination Port: 3503
    Length: 56
    Checksum: 0x2bfc [unverified]
    [Checksum Status: Unverified]
    [Stream index: 35]
    [Stream Packet Number: 1]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
    UDP payload (48 bytes)
Multiprotocol Label Switching Echo
    Version: 1
    Global Flags: 0x0000
        0000 0000 0000 0... = Reserved: 0x0000
        .... .... .... ...0 = Validate FEC Stack: False
        .... .... .... ..0. = Respond only if TTL expired: False
        .... .... .... .0.. = Validate Reverse Path: False
    Message Type: MPLS Echo Reply (2)
    Reply Mode: Reply via an IPv4/IPv6 UDP packet (2)
    Return Code: Replying router is an egress for the FEC at stack depth RSC (3)

上のtshark出力のパケット（No.857 Echo Reply）のpcapをダウンロード

ラベルが付いていません。 返りはIPで戻る（Reply Mode 2）ためです。Return Codeが3になっています。

STEP 2：LSPが壊れると何が見えるか

ACLでPE1 - P1間のLDP（UDP 646とTCP 646）だけを落とします。OSPFもIPの転送も残るので、壊れるのはラベルの配布だけです。

STEP 2 PE1にcommitした設定
ipv4 access-list BLOCK-LDP
 10 deny udp any any eq ldp
 20 deny tcp any any eq ldp
 30 deny tcp any eq ldp any
 40 permit ipv4 any any
!
interface GigabitEthernet0/0/0/1
 ipv4 access-group BLOCK-LDP ingress
!

ラベルが配られなくなると、転送表の出ラベルが消えます。STEP 1では付いていました。

STEP 1 PE1 show mpls forwarding
RP/0/RP0/CPU0:PE1#show mpls forwarding
Mon Oct 12 03:41:40.838 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Pop         3.3.3.3/32         Gi0/0/0/1    10.2.3.3        168
24001  Pop         10.3.4.0/24        Gi0/0/0/1    10.2.3.3        0
24002  33001       4.4.4.4/32         Gi0/0/0/1    10.2.3.3        5644
24003  33002       10.4.5.0/24        Gi0/0/0/1    10.2.3.3        0
24004  33003       5.5.5.5/32         Gi0/0/0/1    10.2.3.3        23858
24005  Unlabelled  192.168.1.0/24[V]  Gi0/0/0/0    10.1.2.1        12400

ACLを入れると、同じエントリーがすべてUnlabelledになります。

STEP 2 PE1 show mpls forwarding
RP/0/RP0/CPU0:PE1#show mpls forwarding
Mon Oct 12 03:49:49.500 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Unlabelled  3.3.3.3/32         Gi0/0/0/1    10.2.3.3        2494
24001  Unlabelled  10.3.4.0/24        Gi0/0/0/1    10.2.3.3        0
24002  Unlabelled  4.4.4.4/32         Gi0/0/0/1    10.2.3.3        5644
24003  Unlabelled  10.4.5.0/24        Gi0/0/0/1    10.2.3.3        0
24004  Unlabelled  5.5.5.5/32         Gi0/0/0/1    10.2.3.3        11701
24005  Unlabelled  192.168.1.0/24[V]  Gi0/0/0/0    10.1.2.1        5100

LSP Pingは失敗します。Qは「リクエストを送れなかった」という意味で、積むラベルが無いためです。

STEP 2 PE1 ping mpls ipv4 5.5.5.5/32 repeat 2 verbose（凡例は省略）
RP/0/RP0/CPU0:PE1#ping mpls ipv4 5.5.5.5/32 repeat 2 verbose
Mon Oct 12 03:52:51.405 UTC
Type escape sequence to abort.

Q      size 100, Unable to send echo request packet
Q      size 100, Unable to send echo request packet

Success rate is 0 percent (0/2)

tracerouteも最初のホップで止まります。[No Label]と出ているのが、積むラベルが無いことを示しています。

STEP 2 PE1 traceroute mpls ipv4 5.5.5.5/32（凡例は省略）
RP/0/RP0/CPU0:PE1#traceroute mpls ipv4 5.5.5.5/32
Mon Oct 12 03:52:51.595 UTC
Type escape sequence to abort.

  0 0.0.0.0 MRU 0 [No Label]
Q 1 *

IPのpingでは気づけない

同じSTEPで、CE1からCE2へのVPNの通信は落ちています。

STEP 2 CE1 ping 192.168.2.1（VPNの通信）
RP/0/RP0/CPU0:CE1#ping 192.168.2.1 source 192.168.1.1 count 50 timeout 1
Mon Oct 12 03:47:05.328 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.2.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)

ところがコア内のIP疎通は無損失です。

STEP 2 PE1 ping 5.5.5.5（コア内のIP疎通）
RP/0/RP0/CPU0:PE1#ping 5.5.5.5 source 2.2.2.2 count 50 timeout 1
Mon Oct 12 03:48:01.798 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 5.5.5.5 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 10/12/32 ms

ここがこの仕組みの存在理由です。 IGPは正常なのでIPは通り、経路表にも異常は出ません。落ちているのはMPLSで運ぶ通信だけで、IPのpingをいくら打っても見つけられません。LSP Pingは積むラベルが無いことをQとして即座に示します。

STEP	CE1 → CE2（VPN）	PE1 → PE2（コアのIP）	LSP Ping
0	100%（50/50）	100%（50/50）	使えない
1	100%（50/50）	100%（50/50）	100%（5/5）
2	0%（0/50）	100%（50/50）	0%（0/5）
3	100%（50/50）	100%（50/50）	100%（5/5）
4	100%（50/50）	100%（50/50）	100%（5/5）
5	100%（50/50）	100%（50/50）	使えない

STEP 4：設定では制御プレーンと転送プレーンを食い違わせられない

LSP Pingが対象にするのは「制御プレーンは正常なのに転送が壊れている」状態です。それを設定で作れるか試します。P1に静的ラベルを入れ、LDPが配ったラベルと食い違わせます。

STEP 4 P1にcommitした設定
mpls static
 address-family ipv4 unicast
  local-label 33500 allocate per-prefix 5.5.5.5/32
   forward
    path 1 nexthop GigabitEthernet0/0/0/1 10.3.4.4 out-label 44999
   !
  !
 !
!

commitは通りますが、インストールされません。

STEP 4 P1 show mpls static local-label all
RP/0/RP0/CPU0:P1#show mpls static local-label all
Mon Oct 12 04:05:51.899 UTC
Label   VRF             Type         Prefix           RW Configured   Status
------- --------------- ------------ ---------------- --------------- --------
33500   default         Per-Prefix   5.5.5.5/32       Yes             Discrepancy

Discrepancyは「LDPがすでにそのFECのラベルを持っているので、静的ラベルと食い違っている」という意味です。転送表はLDPのラベルのままです。

STEP 4 P1 show mpls forwarding
RP/0/RP0/CPU0:P1#show mpls forwarding
Mon Oct 12 04:05:51.627 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
33000  Pop         2.2.2.2/32         Gi0/0/0/0    10.2.3.2        30693
33001  Pop         4.4.4.4/32         Gi0/0/0/1    10.3.4.4        6154
33002  Pop         10.4.5.0/24        Gi0/0/0/1    10.3.4.4        560
33003  44003       5.5.5.5/32         Gi0/0/0/1    10.3.4.4        31263

設定からは制御プレーンと転送プレーンを食い違わせられません。 LSP Pingが探す故障は、ソフトウェアの不具合やハードウェアの故障など設定の外側で起きるものです。ラボで再現するには、STEP 2のように制御プレーン側を壊すしかありません。

STEP 5：撤去

mpls oamを外すと、またSTEP 0と同じ状態に戻ります。

STEP 5 PE1 ping mpls ipv4 5.5.5.5/32（撤去後）
RP/0/RP0/CPU0:PE1#ping mpls ipv4 5.5.5.5/32
Mon Oct 12 04:12:53.319 UTC
% MPLS Embedded Management Subsystem is not running.
To enable, use 'mpls oam' global config command.

最終STEPのrunning-configは、STEP 0と一致します（6台とも差分なし。採取データを行の個数まで突き合わせて確認しています）。

設計上の注意

mpls oamは応答する側にも要ります。 起点だけに入れても、途中や出口のLSRが応答できません
LSP Pingは制御プレーンの故障も見つけます。 STEP 2のようにラベルが配られていない状態では、リクエストを送る前にQで止まります。「転送の故障だけを見る道具」ではありません
tracerouteのほうが情報量が多いです。ホップごとのラベルとMRU、どこでPHPが起きるかが分かるので、切り分けではまずこちらを使います
IPのpingが通ることは、MPLSが通ることの保証になりません。 逆も同じで、LSP Pingの失敗はIPの経路の異常を意味しません

検証Configおよびshow結果

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

ファイル	内容
`..._clear.txt`	そのSTEPでクリアしたカウンタの記録（`clear counters interface` / `clear mpls forwarding counters`）
`..._ping.txt`	そのSTEPの`ping`（50発、timeout 1秒）と`traceroute`
`..._oam.txt`	LSP Ping / LSP Traceroute の記録。操作なのでshow一式と分けています。`mpls oam`が無効なSTEPでは「使えない」という出力がそのまま入っています
`..._show.txt`	`show version` / `show interface description` / OSPF・LDP・MPLS転送の一式など
`..._log.txt`	そのSTEPの範囲だけに絞った`show logging`
`..._run.txt`	そのSTEP時点の`show running-config`（＝そのSTEPの検証Config）
`..._trace.txt`	`show mpls ldp trace` / `show mpls lsd trace`（コア4台のみ）
`..._commit.cfg`	そのSTEPで実際にcommitした設定だけ。設定を変えたルータの分のみ

STEP 0：初期状態（mpls oam 無効）

ルータ	クリア	ping	LSP Ping	show出力	syslog	running-config	trace
CE1	clear	ping	—	show	log	run	—
PE1	clear	ping	oam	show	log	run	trace
P1	clear	ping	oam	show	log	run	trace
P2	clear	ping	oam	show	log	run	trace
PE2	clear	ping	oam	show	log	run	trace
CE2	clear	ping	—	show	log	run	—

STEP 1：コア4台で mpls oam を有効化

ルータ	クリア	ping	LSP Ping	show出力	syslog	running-config	trace	投入した設定
CE1	clear	ping	—	show	log	run	—	—
PE1	clear	ping	oam	show	log	run	trace	commit
P1	clear	ping	oam	show	log	run	trace	commit
P2	clear	ping	oam	show	log	run	trace	commit
PE2	clear	ping	oam	show	log	run	trace	commit
CE2	clear	ping	—	show	log	run	—	—

STEP 2：ACLでPE1 - P1のLDPをdrop

ルータ	クリア	ping	LSP Ping	show出力	syslog	running-config	trace	投入した設定
CE1	clear	ping	—	show	log	run	—	—
PE1	clear	ping	oam	show	log	run	trace	commit
P1	clear	ping	oam	show	log	run	trace	—
P2	clear	ping	oam	show	log	run	trace	—
PE2	clear	ping	oam	show	log	run	trace	—
CE2	clear	ping	—	show	log	run	—	—

STEP 3：ACLを外す

ルータ	クリア	ping	LSP Ping	show出力	syslog	running-config	trace	投入した設定
CE1	clear	ping	—	show	log	run	—	—
PE1	clear	ping	oam	show	log	run	trace	commit
P1	clear	ping	oam	show	log	run	trace	—
P2	clear	ping	oam	show	log	run	trace	—
PE2	clear	ping	oam	show	log	run	trace	—
CE2	clear	ping	—	show	log	run	—	—

STEP 4：P1に静的ラベルを入れて転送だけ壊そうとする

ルータ	クリア	ping	LSP Ping	show出力	syslog	running-config	trace	投入した設定
CE1	clear	ping	—	show	log	run	—	—
PE1	clear	ping	oam	show	log	run	trace	—
P1	clear	ping	oam	show	log	run	trace	commit
P2	clear	ping	oam	show	log	run	trace	—
PE2	clear	ping	oam	show	log	run	trace	—
CE2	clear	ping	—	show	log	run	—	—

STEP 5：すべて撤去（最終状態）

ルータ	クリア	ping	LSP Ping	show出力	syslog	running-config	trace	投入した設定
CE1	clear	ping	—	show	log	run	—	—
PE1	clear	ping	oam	show	log	run	trace	commit
P1	clear	ping	oam	show	log	run	trace	commit
P2	clear	ping	oam	show	log	run	trace	commit
PE2	clear	ping	oam	show	log	run	trace	commit
CE2	clear	ping	—	show	log	run	—	—

パケットキャプチャーはSTEPごとに2つの区間で取得しています。

STEP	PE1 - P1間	P1 - P2間
0	pcap	pcap
1	pcap	pcap
2	pcap	pcap
3	pcap	pcap
4	pcap	pcap
5	pcap	pcap

参考

出典	参照した箇所
RFC 8029 Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures	2.1節（127/8を使う理由とECMPのための16Mアドレス）、3節（パケットフォーマット、Reply ModeとReturn Codeの値）、3.2節（Target FEC Stack）
IOS XR MPLS Configuration Guide	`mpls oam` / `ping mpls ipv4` / `traceroute mpls ipv4` / `mpls static`の構文

検証はXRd 26.1.1（Cisco Modeling Labs）で実施しました。