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

MPLSのOAM（LSP Ping / LSP Traceroute）

目次

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はアプリケーションレベルの制御チャネル
Return Code 結果。3 = 応答したルータがそのFECの出口、4 = そのFECのマッピングが無い、8 = ラベルスイッチした

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

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-FILTERラボ
  CE1 ------ PE1 ------ P1 ------ P2 ------ PE2 ------ CE2
(AS 65101)    |          ↑STEP 2でLDPを落とす      |   (AS 65102)
           vrf CUST-A                          vrf CUST-A
              └────── iBGP vpnv4（Lo0間）──────┘
ルータ Lo0 役割
CE1 1.1.1.1 AS 65101、192.168.1.0/24
PE1 2.2.2.2 入口/出口LSR。LSP Pingの起点
P1 3.3.3.3 中継LSR
P2 4.4.4.4 中継LSR（PHP）
PE2 5.5.5.5 入口/出口LSR。確かめるFEC
CE2 6.6.6.6 AS 65102、192.168.2.0/24

検証の全体像

STEP 操作 確かめること
0 初期状態 LSP Pingが使えないこと。IOS XRでは明示的な有効化が要る
1 コア4台でmpls oamを有効化 ping mpls / traceroute mplsが成功。パケットの中身をキャプチャーで確認
2 ACLでPE1 - P1のLDPをdrop LSP Pingが失敗すること。IPのpingは通ったままであること
3 撤去（最終状態） STEP 0と同じに戻ること

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

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

STEP 0 PE1（mpls oam 無効）
RP/0/RP0/CPU0:PE1#ping mpls ipv4 5.5.5.5/32
Sat Sep 12 08:40:54.133 UTC
% MPLS Embedded Management Subsystem is not running.
To enable, use 'mpls oam' global config command.

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

STEP 1 PE1にcommitした設定
RP/0/RP0/CPU0:PE1#show configuration commit changes last 1
Sat Sep 12 08:41:28.848 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
mpls oam
!
end

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
Sat Sep 12 08:49:30.733 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 = 15/16/17 ms

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
Sat Sep 12 08:49:30.974 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: 24003 Exp: 0]
L 1 10.2.3.3 MRU 1500 [Labels: 24003 Exp: 0] 10 ms
L 2 10.3.4.4 MRU 1500 [Labels: implicit-null Exp: 0] 12 ms
! 3 10.4.5.5 13 ms

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

tracerouteも同じ凡例を出したうえで、ホップごとの行が続きます。Lがラベル付きで出て行くホップ、!が到達です。ホップ2の表示はimplicit-nullになっています。P2がPHPでラベルを外すことが、tracerouteの出力からそのまま読み取れます。MRUも各ホップで分かります。

パケットの中身

添付のキャプチャーのNo.912がPE1の送ったecho requestです。

STEP 1 No.912 MPLS Echo Request（PE1 → 127.0.0.1、tshark -V 抜粋）
    Type: MPLS label switched packet (0x8847)
MultiProtocol Label Switching Header, Label: 24003, Exp: 0, S: 1, TTL: 255
Internet Protocol Version 4, Src: 10.2.3.2, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 3503, Dst Port: 3503
    Message Type: MPLS Echo Request (1)
    Reply Mode: Reply via an IPv4/IPv6 UDP packet (2)
    Return Code: No return code (0)
        Type: Target FEC Stack (1)
        FEC Element 1: LDP IPv4 prefix
            Type: LDP IPv4 prefix (1)
            IPv4 Prefix: 5.5.5.5
            Prefix Length: 32
上のtshark出力のパケット（No.912 Echo Request）のpcapをダウンロード

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

返ってきたecho replyです（No.913）。

STEP 1 No.913 MPLS Echo Reply（PE2 → PE1、tshark -V 抜粋）
Internet Protocol Version 4, Src: 10.4.5.5, Dst: 10.2.3.2
User Datagram Protocol, Src Port: 3503, Dst Port: 3503
    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)
    Return Subcode: 1
上のtshark出力のパケット（No.913 Echo Reply）のpcapをダウンロード

replyはラベルを積まず、素のIPで返っています。 Reply Modeの2がそのとおりに効いています。Return Codeは3で、CLIのverboseが表示した値と一致します。

tracerouteのTTLも観測できます。LSP PingがTTL 255で送るのに対し、tracerouteは1, 2, 3と増やしています。

パケット TTL
No.912〜920（LSP Ping ×5） 255
No.922 1
No.924 2
No.926 3
TTL=1のecho request（No.922）のpcapをダウンロード

STEP 2：LSPが壊れるとどうなるか

PE1のP1向けインタフェースで、LDPだけをACLで落とします。OSPFもIPの疎通もそのまま残ります。

STEP 2 PE1にcommitした設定
RP/0/RP0/CPU0:PE1#show configuration commit changes last 1
Sat Sep 12 08:49:57.370 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
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
!
end

LDPセッションが落ちてラベルを失うので、LSP Pingはecho requestを送ることすらできません。

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
Sat Sep 12 09:00:01.017 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.

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)

Qは凡例の「request not sent」です。同じ時刻に、IPのpingは無損失で通っています。

STEP 2 PE1 IPのping（同じ宛先）
RP/0/RP0/CPU0:PE1#ping 5.5.5.5 source 2.2.2.2 count 50 timeout 1
Sat Sep 12 08:54:03.788 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 = 9/21/76 ms

同じ宛先に対して、IPのpingは100%、LSP Pingは0%です。 MPLSで運ぶVPNの通信（CE1 - CE2）もこのとき全ロスになります。

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

転送プレーンだけの故障はラボで作れない

この検証で作れたのは制御プレーンの故障です。LDPセッションが落ちているので、show mpls ldp neighborを見れば原因が分かります。LSP Pingが本来対象とする「制御プレーンは正常なのに転送だけ壊れている」状態は、設定では作れませんでした。

IOS XRで静的ラベルを使い、LDPが割り当てたラベル（P1の24003）を上書きしようとすると、commitは通るものの状態がDiscrepancyになり、LFIBには反映されません。

mpls static で LDP のラベルを上書きしようとした結果
Label   VRF             Type         Prefix           RW Configured   Status   
------- --------------- ------------ ---------------- --------------- -------- 
24003   default         X-Connect    N/A              Yes             Discrepancy

XRはLDPが管理するラベルとの衝突を検出して拒否します。 つまり設定ミスで制御プレーンと転送プレーンを食い違わせることはできません。LSP Pingが見つける故障は、ハードウェアの転送エントリーの書き込み失敗など、設定の外側で起きるものです。だからこそ、showでは分からない故障を検出する手段が要ります。

設計上の注意

  • IOS XRではmpls oamを入れておかないと、障害時に使えません。 必要になってから入れるのでは遅いので、コアの標準設定に含めます
  • 応答する側にも要ります。 起点だけに入れても、途中のLSRやegressが応答しません
  • Q（request not sent）は自分の側にラベルが無いことを示します。相手まで届いていないので、まず自分のshow mpls ldp neighborとshow mpls forwardingを見ます
  • LSP Pingが通ってもVPNの疎通は保証されません。 LSP Pingが確かめるのはトランスポートLSPで、VPNラベルは別に積まれます

検証Configおよびshow結果

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

ファイル 内容
..._show.txt show version / show mpls forwarding / show mpls ldp 系一式
..._log.txt そのSTEPの範囲だけに絞ったshow logging
..._run.txt そのSTEP時点のshow running-config（＝そのSTEPの検証Config）
..._ping.txt そのSTEPのping（50発、timeout 1秒）とtraceroute
..._oam.txt そのSTEPのping mpls / traceroute mplsの結果（PE1・PE2・P1・P2）
..._trace.txt show mpls ldp trace 系（コア4台のみ）
..._commit.cfg そのSTEPで実際にcommitした設定だけ。 設定を変えたルータの分のみ

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

ルータ show出力 syslog running-config ping OAM trace commit
CE1 show log run ping - - -
PE1 show log run ping oam trace -
P1 show log run ping oam trace -
P2 show log run ping oam trace -
PE2 show log run ping oam trace -
CE2 show log run ping - - -

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

ルータ show出力 syslog running-config ping OAM trace commit
CE1 show log run ping - - -
PE1 show log run ping oam trace cfg
P1 show log run ping oam trace cfg
P2 show log run ping oam trace cfg
PE2 show log run ping oam trace cfg
CE2 show log run ping - - -

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

ルータ show出力 syslog running-config ping OAM trace commit
CE1 show log run ping - - -
PE1 show log run ping oam trace cfg
P1 show log run ping oam trace -
P2 show log run ping oam trace -
PE2 show log run ping oam trace -
CE2 show log run ping - - -

STEP 3：撤去（最終状態）

ルータ show出力 syslog running-config ping OAM trace commit
CE1 show log run ping - - -
PE1 show log run ping oam trace cfg
P1 show log run ping oam trace cfg
P2 show log run ping oam trace cfg
PE2 show log run ping oam trace cfg
CE2 show log run ping - - -

PE1 - P1間のキャプチャー全体です。全STEPのMPLS echo request / replyが入っています。

PE1 - P1間のキャプチャー全体をダウンロード

参考

出典 参照した箇所
RFC 8029 Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures 2.1節（127/8を使う理由）、2.2節（Router Alert Option）、3節（Target FEC Stack、Reply Mode、Return Code）、3.4.2節と4節（TTLを増やすtraceroute）。RFC 4379 / 6424 / 6829 / 7537 を廃止

UDPポート3503はキャプチャーでの実測値です（RFC本文からは引用していません）。検証はXRd 26.1.1（Cisco Modeling Labs）で実施しました。