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

LDPとは

目次

LDPとは

LDP（Label Distribution Protocol、RFC 5036）は、MPLSのラベルを隣のルータへ配るプロトコルです。経路そのものはOSPFやIS-ISが配り、LDPは「そのプレフィックスに私はこのラベルを使う」という対応だけを配ります。本記事ではLDPが隣を見つけてセッションを張りラベルを配るまでを解説し、IOS XR（XRd）のラボで確立の全過程をパケットで追います。ラベルの付け替えはMPLSのラベル操作（push / swap / pop）とPHPで解説しています。

LDPの3つの段階

LDPの動きは3つに分かれます。

段階使うものやること
DiscoveryUDP 646、宛先224.0.0.2Helloを撒いて隣のLSRを見つける
SessionTCP 646見つけた相手とTCPをつなぎ、パラメータを合わせる
Advertisement同じTCP接続自分のアドレスとラベルの対応を送る

Helloだけがマルチキャストで、相手が決まってからはユニキャストのTCPに移ります。TCPを先に張りにいくのは転送アドレスが大きいほうで、小さいほうは待ち受けます。

LDP識別子

LDPは相手をLDP識別子で識別します。6オクテットで、<LSRのID>:<ラベルスペース>と表記します。

前半4オクテットはルータを一意に識別する値で、ルータIDと同じ値にすることが一般的です。後半2オクテットはラベルスペースの番号で、0はプラットフォーム全体で1つのラベル空間を使うことを表します。インタフェースごとにラベル空間を分ける構成では0以外になります。

LDPのメッセージ

RFC 5036が定義するメッセージは11種類です。タイプ値は2オクテットで、種類ごとに番号が割り当てられています。

メッセージType役割
Notification0x0001エラーやセッションの終了を伝える
Hello0x0100隣を見つける。UDPで送る唯一のメッセージ
Initialization0x0200セッションのパラメータを提示する
KeepAlive0x0201セッションを維持する
Address0x0300自分が持つIPアドレスを伝える
Address Withdraw0x0301伝えたアドレスを取り消す
Label Mapping0x0400プレフィックスとラベルの対応を伝える
Label Request0x0401ラベルを要求する（Downstream-on-Demandで使う）
Label Withdraw0x0402配ったラベルを取り消す
Label Release0x0403受け取ったラベルを返す
Label Abort Request0x0404出した要求を取り消す

このうちAddress Withdraw以降の取り消し系は、経路が消えたときやセッションが切れたときに使われます。タイプ値はRFC 5036の付録A.1に一覧があります。

Addressが要る理由は、LDPの識別子とラベルを付ける宛先のIPアドレスが別物だからです。受け取った側は、Addressで教わったアドレスの一覧を使って「このネクストホップはどのLDPピアか」を対応付けます。

ラベルの配り方

IOS XRの既定はDownstream-Unsolicitedで、要求を待たずに自分のラベルを配ります。要求があってから配るDownstream-on-Demandもあり、そちらではLabel Requestを使います。配布モードの違いはLDPのラベル配布モードとラベルスペースで解説しています。

セッションが上がると、まずAddressで自分のアドレスを送り、続けて持っているプレフィックスの数だけLabel Mappingを送ります。以後は経路が増減したときに差分だけを送り、KeepAliveで接続を維持します。

DiscoveryとSessionは単位が違う

3つの段階のうち、Discoveryはリンクごと、Sessionはピアごとです。ここが対応していないため、リンクが複数あると数が一致しません。

項目DiscoverySession
数の単位インタフェースごとに1つLDPピアごとに1つ
使うアドレスインタフェースのIPアドレス転送アドレス（通常はLoopback）
トランスポートUDP 646のマルチキャストTCP 646のユニキャスト
相手の決め方マルチキャストで探すHelloで知った転送アドレスへ接続する
役割隣にどのLSRがいるかを知るラベルを運ぶ信頼できる通路を作る
切れたと判断するまでHelloのホールドタイム15秒セッションのホールドタイム180秒

PE1とP1を2本のリンクでつなぐと、Discoveryは2つ、Sessionは1本になります。LDPが相手を識別するのはLDP識別子、つまりラベルスペースの単位だからです。ラベルスペースが:0、すなわちプラットフォーム全体で1つなら、どのリンクから来ても同じラベルが有効なので、セッションを分ける理由がありません。

この非対称には運用上の意味があります。片方のリンクが落ちてもセッションは切れません。Discovery Sourceが1つ減るだけで、残った経路でTCP接続が続くためです。ラベルの再配布が起きないので、リンク障害のたびにラベルが振り直されることを避けられます。逆にすべてのリンクが落ちるとDiscovery Sourceが0になり、セッションも終了します。

実機での検証

検証環境

CE1 — PE1 — P1 — P2 — P3 — PE2 — CE2 を直列につなぎ、PE1とP1の間だけ2本のリンクにしています。AS 65001のPE1 / P1 / P2 / P3 / PE2がMPLSネットワークで、OSPF（area 0、全リンクnetwork point-to-point）で経路を、LDPでラベルを配っています。CE1とCE2はPEとeBGPで経路を交換し、PE1とPE2はLoopback0間のiBGP（next-hop-self）を張っています。全台XRdです。

2本目（10.2.13.0/24）はOSPFのコストを100にしてあります。経路が1本目を向くので、LDPのTCPもそちらを通ります。

ルータLo0リンクDiscovery / Session
CE11.1.1.1/32Gi0/0/0/0 10.1.2.1（AS 65101、192.168.1.0/24）LDPなし
PE12.2.2.2/32Gi0/0/0/0 10.1.2.2 / Gi0/0/0/1 10.2.3.2 / Gi0/0/0/2 10.2.13.22 / 1
P13.3.3.3/32Gi0/0/0/0 10.2.3.3 / Gi0/0/0/1 10.3.4.3 / Gi0/0/0/2 10.2.13.33 / 2
P24.4.4.4/32Gi0/0/0/0 10.3.4.4 / Gi0/0/0/1 10.4.5.42 / 2
P35.5.5.5/32Gi0/0/0/0 10.4.5.5 / Gi0/0/0/1 10.5.6.52 / 2
PE26.6.6.6/32Gi0/0/0/0 10.5.6.6 / Gi0/0/0/1 10.6.7.61 / 1
CE27.7.7.7/32Gi0/0/0/0 10.6.7.7（AS 65102、192.168.2.0/24）LDPなし

キャプチャーはPE1 - P1の2本とも、STEPごとに取得しています。

検証のSTEP

STEP操作確かめること
0初期状態LDP識別子、Discoveryが2でSessionが1であること、配られたラベル
11本目を両端shutdownセッションが切れず、TCPが2本目へ移ること。取り消し系のメッセージが流れること
22本目もshutdownDiscovery Sourceが0になり、セッションが終了すること
32本ともno shutdown確立の全過程がキャプチャーに収まること
4PE1にだけ認証を設定Helloは流れ続け、TCPの段階で落ちること
5認証を削除（最終状態）STEP 0と同じに戻ること

LDP識別子とHello

PE1のDiscoveryです。自分のLDP識別子が2.2.2.2:0、相手が3.3.3.3:0で、2つのインタフェースが別々のDiscovery Sourceとして並びます。

PE1 show mpls ldp discovery（STEP 0）
RP/0/RP0/CPU0:PE1#show mpls ldp discovery
Mon Sep 28 01:41:35.919 UTC

Local LDP Identifier: 2.2.2.2:0
Discovery Sources:
  Interfaces:
    GigabitEthernet0/0/0/1 : xmit/recv
      VRF: 'default' (0x60000000)
      LDP Id: 3.3.3.3:0, Transport address: 3.3.3.3
          Hold time: 15 sec (local:15 sec, peer:15 sec)
          Established: Sep 28 01:35:03.119 (00:06:32 ago)

    GigabitEthernet0/0/0/2 : xmit/recv
      VRF: 'default' (0x60000000)
      LDP Id: 3.3.3.3:0, Transport address: 3.3.3.3
          Hold time: 15 sec (local:15 sec, peer:15 sec)
          Established: Sep 28 01:35:03.219 (00:06:32 ago)

xmit/recvはHelloを送受信できている状態です。ホールドタイムは15秒で、この間にHelloが届かなければ相手を失ったと判断します。転送アドレスはどちらも同じ3.3.3.3（P1のLoopback0）です。

Discoveryはリンクごと、Sessionはピアごと

show mpls ldp summaryに両方の数が並びます。PE1はHello Adjが2でNeighborsが1、同じ相手と2本のリンクで向かい合っているためです。一方のP2は2台の別々の相手と1本ずつなので、Hello Adjが2でNeighborsも2になります。P1はPE1へ2本、P2へ1本で、Hello Adjが3、Neighborsが2です。

PE1 show mpls ldp summary（STEP 0）
RP/0/RP0/CPU0:PE1#show mpls ldp summary
Mon Sep 28 01:41:35.678 UTC

  AFIs      : IPv4
  Routes    : 11 prefixes
  Bindings  : 11 prefixes
      Local     : 11
      Remote    : 10
  Neighbors : 1
  Adj Groups: 1
  Hello Adj : 2
  Addresses : 4
  Interfaces: 2 LDP configured
P1 show mpls ldp summary（STEP 0）
RP/0/RP0/CPU0:P1#show mpls ldp summary
Mon Sep 28 01:42:47.550 UTC

  AFIs      : IPv4
  Routes    : 10 prefixes
  Bindings  : 11 prefixes
      Local     : 10
      Remote    : 21
  Neighbors : 2
  Adj Groups: 2
  Hello Adj : 3
  Addresses : 4
  Interfaces: 3 LDP configured
P2 show mpls ldp summary（STEP 0）
RP/0/RP0/CPU0:P2#show mpls ldp summary
Mon Sep 28 01:43:22.186 UTC

  AFIs      : IPv4
  Routes    : 10 prefixes
  Bindings  : 10 prefixes
      Local     : 10
      Remote    : 20
  Neighbors : 2
  Adj Groups: 2
  Hello Adj : 2
  Addresses : 3
  Interfaces: 2 LDP configured

PE1のネイバーの詳細です。Peer LDP Identifierは1つ、TCP connectionも1本で、その下にLDP Discovery Sources: IPv4: (2)として2つのインタフェースが並びます。2つのDiscoveryが1つのSessionに集約されていることがこの1画面で読めます。

PE1 show mpls ldp neighbor detail（STEP 0、先頭18行）
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor detail
Mon Sep 28 01:41:36.555 UTC

Peer LDP Identifier: 3.3.3.3:0
  TCP connection: 3.3.3.3:17769 - 2.2.2.2:646
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 21/20; Downstream-Unsolicited
  Up time: 00:06:19
  LDP Discovery Sources:
    IPv4: (2)
      GigabitEthernet0/0/0/1
      GigabitEthernet0/0/0/2
    IPv6: (0)
  Addresses bound to this peer:
    IPv4: (4)
      3.3.3.3        10.2.3.3       10.2.13.3      10.3.4.3
    IPv6: (0)

セッションの実体はTCPです。show tcp briefに646番の接続が出ます。転送アドレスが大きいほうのP1（3.3.3.3）が接続し、PE1が646で待ち受けています。

PE1 show tcp brief（STEP 0）
RP/0/RP0/CPU0:PE1#show tcp brief
Mon Sep 28 01:41:42.659 UTC
   PCB             VRF-ID     Recv-Q Send-Q Local Address          Foreign Address        State
0x00007da7f8008bc0 0x60000000      0      0  :::179                 :::0                   LISTEN
0x00007da7f8003520 0x00000000      0      0  :::179                 :::0                   LISTEN
0x0000641354700120 0x60000000      0      0  :::0                   :::0                   CLOSED
0x00007da7f4003050 0x00000000      0      0  :::0                   :::0                   CLOSED
0x00007da83c008010 0x60000000      0      0  2.2.2.2:646            3.3.3.3:17769          ESTAB
0x00007da83c00dae0 0x60000000      0      0  2.2.2.2:179            6.6.6.6:38014          ESTAB
0x00007da7f80093b0 0x60000000      0      0  10.1.2.2:28215         10.1.2.1:179           ESTAB
0x00007da804002e70 0x60000000      0      0  0.0.0.0:646            0.0.0.0:0              LISTEN
0x00007da7fc003520 0x00000000      0      0  0.0.0.0:646            0.0.0.0:0              LISTEN
0x00007da7ec0489a0 0x60000000      0      0  0.0.0.0:179            0.0.0.0:0              LISTEN
0x00007da7ec0431d0 0x00000000      0      0  0.0.0.0:179            0.0.0.0:0              LISTEN
0x00007da8040036a0 0x00000000      0      0  0.0.0.0:0              0.0.0.0:0              CLOSED

配られたラベルはshow mpls ldp bindingsに並びます。PE2のLoopback0（6.6.6.6/32）には、自分が付けた24006と、P1から受け取った24005が入っています。

PE1 show mpls ldp bindings 6.6.6.6/32（STEP 0）
RP/0/RP0/CPU0:PE1#show mpls ldp bindings 6.6.6.6/32
Mon Sep 28 01:41:38.736 UTC
6.6.6.6/32, rev 22
	Local binding: label: 24006
	Remote bindings: (1 peers)
	    Peer                Label
	    -----------------   ---------
	    3.3.3.3:0           24005

片方のリンクが落ちてもセッションは切れない

1本目の両端をshutdownします。

STEP 1 PE1にcommitした設定
RP/0/RP0/CPU0:PE1#show configuration commit changes last 1
Mon Sep 28 04:04:46.474 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
interface GigabitEthernet0/0/0/1
 shutdown
!
end
STEP 1 P1にcommitした設定
RP/0/RP0/CPU0:P1#show configuration commit changes last 1
Mon Sep 28 04:04:54.143 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
interface GigabitEthernet0/0/0/0
 shutdown
!
end

syslogにはOSPFの隣接断とHelloの隣接（HELLO_ADJ_CHANGE）が出ますが、LDPのネイバーが落ちたログ（NBR_CHANGE）は出ません。

STEP 1 PE1 show logging（抜粋）
RP/0/RP0/CPU0:Sep 28 04:04:45.655 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0/0/1 in area 0 from FULL to DOWN, Neighbor Down: interface down or detached, vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep 28 04:04:45.657 UTC: mpls_ldp[1178]: %ROUTING-LDP-5-HELLO_ADJ_CHANGE : VRF 'default' (0x60000000), Link hello adjacency (10.2.3.3, GigabitEthernet0/0/0/1) with Nbr 3.3.3.3:0 is DOWN (Interface state down)

ネイバーの詳細を見ると、TCP接続のポート番号もUp timeもSTEP 0から続いています。Discovery Sourceだけが2つから1つに減りました。

STEP 1 PE1 show mpls ldp neighbor detail（先頭14行）
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor detail
Mon Sep 28 04:08:12.888 UTC

Peer LDP Identifier: 3.3.3.3:0
  TCP connection: 3.3.3.3:53056 - 2.2.2.2:646
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 26/25; Downstream-Unsolicited
  Up time: 00:09:04
  LDP Discovery Sources:
    IPv4: (1)
      GigabitEthernet0/0/0/2
    IPv6: (0)
  Addresses bound to this peer:

キャプチャーでも、TCPは1本目から消えて2本目に現れます。Helloは残った2本目だけに流れます。落ちたリンクのアドレスとラベルは取り消され、Address Withdraw / Label Withdraw / Label Releaseが2本目のセッション上を流れました。

STEP 1 2本目のリンクのLDPメッセージ（TCP上のもの）
$ tshark -r - -Y 'ldp && tcp' -T fields -e frame.number -e frame.time_relative -e ip.src -e _ws.col.info \
    < mpls-ldp-step1-link2.pcap
147	14.863650000	3.3.3.3	Address Withdrawal Message
156	15.169564000	2.2.2.2	Label Withdrawal Message
157	15.173744000	3.3.3.3	Label Release Message
158	15.177509000	2.2.2.2	Label Mapping Message
206	18.587109000	3.3.3.3	Keep Alive Message

show mpls ldp statistics msg-countersにも同じものが数として出ます。

STEP 1 PE1 show mpls ldp statistics msg-counters
RP/0/RP0/CPU0:PE1#show mpls ldp statistics msg-counters
Mon Sep 28 04:08:13.777 UTC

Peer LDP Identifier: 3.3.3.3:0

                            Sent    Rcvd
                           ------  ------
   Initialization               1       1
   Address                      1       1
   Address-Withdraw             1       1
   Label-Mapping               12      10
   Label-Withdraw               1       0
   Label-Release                0       1
   Label-Request                0       0
   Label-Abort-Request          0       0
   Notification                 0       0
   KeepAlive                   10      11

   Total                       26      25

このあいだもCE1からCE2への疎通は保たれています（50発すべて成功）。セッションが切れないのでラベルは振り直されず、転送は2本目を通って続きます。

すべてのリンクが落ちるとセッションも終了する

2本目も落とすと、Discovery Sourceが0になります。ここで初めてLDPのネイバーが落ちます。

STEP 2 PE1 show logging（抜粋）
RP/0/RP0/CPU0:Sep 28 04:11:52.034 UTC: mpls_ldp[1178]: %ROUTING-LDP-5-HELLO_ADJ_CHANGE : VRF 'default' (0x60000000), Link hello adjacency (10.2.13.3, GigabitEthernet0/0/0/2) with Nbr 3.3.3.3:0 is DOWN (Interface state down)
RP/0/RP0/CPU0:Sep 28 04:11:52.040 UTC: mpls_ldp[1178]: %ROUTING-LDP-5-NBR_CHANGE : VRF 'default' (0x60000000), Neighbor 3.3.3.3:0 is DOWN (Interface state down)
STEP 2 PE1 show mpls ldp discovery
RP/0/RP0/CPU0:PE1#show mpls ldp discovery
Mon Sep 28 04:20:12.730 UTC

Local LDP Identifier: 2.2.2.2:0
Discovery Sources:

Discovery Sources:の下には何も並びません。CE1からCE2への疎通も落ちます（0%）。PE1からP1への経路自体が無くなるためです。

セッション確立の全過程

2本ともno shutdownで戻すと、TCPの3ウェイハンドシェイクから始まる確立の全過程が1本のキャプチャーに収まります。

STEP 3 1本目のリンクのTCP 646
$ tshark -r - -Y 'tcp.port==646' -T fields -e frame.number -e frame.time_relative -e ip.src -e _ws.col.info \
    < mpls-ldp-step3-link1.pcap
34	13.735328000	3.3.3.3	48796 → 646 [SYN] Seq=0 Win=16384 Len=0 MSS=1240 WS=1
35	13.738370000	2.2.2.2	646 → 48796 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1240 WS=1
36	13.741024000	3.3.3.3	48796 → 646 [ACK] Seq=1 Ack=1 Win=16384 Len=0
37	13.741743000	3.3.3.3	Initialization Message
38	13.799841000	2.2.2.2	Initialization Message Keep Alive Message
39	13.803906000	3.3.3.3	Keep Alive Message
40	13.807741000	2.2.2.2	Address Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message
41	13.809839000	3.3.3.3	Address Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message Label Mapping Message
42	14.012545000	2.2.2.2	646 → 48796 [ACK] Seq=424 Ack=406 Win=15979 Len=0

SYN → SYN,ACK → ACK のあとにInitializationが両方向に流れ、KeepAliveで確認し、AddressとLabel Mappingが続きます。確立からラベル配布までが0.08秒です。

No.37がP1から送られたInitializationです。LDP識別子とセッションのパラメータが入っています。

STEP 3 No.37 Initialization（P1 → PE1）tshark -V 抜粋
Internet Protocol Version 4, Src: 3.3.3.3, Dst: 2.2.2.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: 112
    Identification: 0x9bf5 (39925)
    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: 255
    Protocol: TCP (6)
    Header Checksum: 0x14c9 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 3.3.3.3
    Destination Address: 2.2.2.2
    [Stream index: 5]
Transmission Control Protocol, Src Port: 48796, Dst Port: 646, Seq: 1, Ack: 1, Len: 72
    Source Port: 48796
    Destination Port: 646
    [Stream index: 0]
    [Stream Packet Number: 4]
    [Conversation completeness: Incomplete, ESTABLISHED (7)]
        ..0. .... = RST: Absent
        ...0 .... = FIN: Absent
        .... 0... = Data: Absent
        .... .1.. = ACK: Present
        .... ..1. = SYN-ACK: Present
        .... ...1 = SYN: Present
        [Completeness Flags: ···ASS]
    [TCP Segment Len: 72]
    Sequence Number: 1    (relative sequence number)
    Sequence Number (raw): 3004366313
    [Next Sequence Number: 73    (relative sequence number)]
    Acknowledgment Number: 1    (relative ack number)
    Acknowledgment number (raw): 1904021865
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Accurate ECN: Not set
        .... 0... .... = Congestion Window Reduced: Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······AP···]
    Window: 16384
    [Calculated window size: 16384]
    [Window size scaling factor: 1]
    Checksum: 0x8456 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    [Timestamps]
        [Time since first frame in this TCP stream: 6.415000 milliseconds]
        [Time since previous frame in this TCP stream: 719.000 microseconds]
    [SEQ/ACK analysis]
        [iRTT: 5.696000 milliseconds]
        [Bytes in flight: 72]
        [Bytes sent since last PSH flag: 72]
    [Client Contiguous Streams: 1]
    [Server Contiguous Streams: 1]
    TCP payload (72 bytes)
Label Distribution Protocol
    Version: 1
    PDU Length: 68
    LSR ID: 3.3.3.3
    Label Space ID: 0
    Initialization Message
        0... .... = U bit: Unknown bit not set
        Message Type: Initialization Message (0x200)
        Message Length: 58
        Message ID: 0x00000056
        Common Session Parameters
            00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
            TLV Type: Common Session Parameters (0x500)
            TLV Length: 14
            Parameters
                Session Protocol Version: 1
                Session KeepAlive Time: 180
                0... .... = Session Label Advertisement Discipline: Downstream Unsolicited proposed
                .0.. .... = Session Loop Detection: Loop Detection Disabled
                Session Path Vector Limit: 0
                Session Max PDU Length: 0
上のtshark出力のパケット（No.37 Initialization）のpcapをダウンロード

Session KeepAlive Time: 180が提示したホールドタイムです。RFC 5036が定めているのは両者が出した値の小さいほうを採用するところまでで、送信間隔は実装に委ねられています。IOS XRは採用した値の3分の1、ここでは60秒ごとにKeepAliveを送ります。Session Max PDU Length: 0はPDUの最大長の提案で、255以下は既定の4096オクテットを意味します（RFC 5036の3.5.3節）。

No.40は、PE1が送ったAddressとLabel Mapping 11個が1つのTCPセグメントに入ったものです。ldp.msg.typeにメッセージのタイプ値が並びます（0x300 = Address、0x400 = Label Mapping）。

STEP 3 No.40 Address + Label Mapping ×11（PE1 → P1）
$ tshark -r - -Y 'frame.number==40' -T fields -e frame.number -e frame.len -e ldp.msg.type -e ldp.msg.len \
    < mpls-ldp-step3-link1.pcap
40	396	0x0300,0x0400,0x0400,0x0400,0x0400,0x0400,0x0400,0x0400,0x0400,0x0400,0x0400,0x0400	26,24,23,23,23,24,24,24,24,23,23,23
上のtshark出力のパケット（No.40 Address + Label Mapping ×11）のpcapをダウンロード

認証が合わないとTCPの段階で落ちる

PE1にだけLDPの認証（TCP MD5）を設定します。

STEP 4 PE1にcommitした設定
RP/0/RP0/CPU0:PE1#show configuration commit changes last 1
Mon Sep 28 04:31:10.841 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
mpls ldp
 neighbor
  3.3.3.3:0 password encrypted 132E36283E202B0D
 !
!
end

Helloは認証の対象ではないのでxmit/recvのままで、相手のLDP識別子も見えています。

STEP 4 PE1 show mpls ldp discovery
RP/0/RP0/CPU0:PE1#show mpls ldp discovery
Mon Sep 28 04:37:53.140 UTC

Local LDP Identifier: 2.2.2.2:0
Discovery Sources:
  Interfaces:
    GigabitEthernet0/0/0/1 : xmit/recv
      VRF: 'default' (0x60000000)
      LDP Id: 3.3.3.3:0, Transport address: 3.3.3.3
          Hold time: 15 sec (local:15 sec, peer:15 sec)
          Established: Sep 28 04:23:56.820 (00:13:56 ago)

    GigabitEthernet0/0/0/2 : xmit/recv
      VRF: 'default' (0x60000000)
      LDP Id: 3.3.3.3:0, Transport address: 3.3.3.3
          Hold time: 15 sec (local:15 sec, peer:15 sec)
          Established: Sep 28 04:23:56.816 (00:13:56 ago)

それでもネイバーは0件です。

STEP 4 PE1 show mpls ldp neighbor brief
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief
Mon Sep 28 04:37:53.440 UTC

理由はsyslogに出ます。TCPがMD5署名を検証して弾いています。

STEP 4 PE1 show logging（抜粋）
RP/0/RP0/CPU0:Sep 28 04:31:10.507 UTC: config[67965]: %MGBL-SYS-5-CONFIG_I : Configured from console by cisco on vty0 (10.20.1.1)
RP/0/RP0/CPU0:Sep 28 04:31:11.622 UTC: tcp[134]: %IP-TCP-3-BADAUTH : Invalid MD5 digest from 3.3.3.3:64996 to 2.2.2.2:646 for vrf:default (0x60000000)

キャプチャーにはSYNの再送だけが並びます。LDPのメッセージは1つも流れません。

STEP 4 1本目のリンクのSYN
$ tshark -r - -Y 'tcp.port==646 && tcp.flags.syn==1' -T fields -e frame.number -e frame.time_relative -e _ws.col.info \
    < mpls-ldp-step4-link1.pcap
143	9.904506000	64996 → 646 [SYN] Seq=0 Win=16384 Len=0 MSS=1240 WS=1
147	11.904957000	[TCP Retransmission] 64996 → 646 [SYN] Seq=0 Win=16384 Len=0 MSS=1240 WS=1
155	15.905741000	[TCP Retransmission] 64996 → 646 [SYN] Seq=0 Win=16384 Len=0 MSS=1240 WS=1
169	23.906356000	[TCP Retransmission] 64996 → 646 [SYN] Seq=0 Win=16384 Len=0 MSS=1240 WS=1

このときCE1からCE2への疎通も落ちます。リンクもOSPFも正常なままですが、ラベルが無くなるとコアのP1 / P2 / P3は転送先を決められません（BGPを持たないため、顧客のプレフィックスをIPとして引けない）。LDPが止まると制御だけでなくデータも止まります。認証の設定そのものはLDPのセッション認証（TCP MD5）で解説しています。

観測したメッセージ

この検証で観測できたのは8種類で、タイプ値はRFC 5036の定義と一致しました。

メッセージType観測した場面
Notification0x0001セッションの終了（STEP 2 / 4）
Hello0x0100全STEP（UDP 646、5秒ごと）
Initialization0x0200確立（STEP 3）
KeepAlive0x0201全STEP（60秒ごと）
Address0x0300確立の直後（STEP 3）
Address Withdraw0x0301リンク断（STEP 1）
Label Mapping0x0400確立の直後と経路の変化（STEP 1 / 3）
Label Withdraw0x0402リンク断（STEP 1）
Label Release0x0403リンク断で受け取った取り消しへの応答（STEP 1）

Downstream-Unsolicitedで動かしているため、Label Request（0x0401）とLabel Abort Request（0x0404）は流れません。

リンクごとのトラフィックと疎通

STEPごとに、2本のリンクを流れたHello（UDP 646）とTCP 646のパケット数、CE1からCE2への疎通を並べます。

STEP1本目 Hello1本目 TCP 6462本目 Hello2本目 TCP 646CE1 → CE2
0119201180100%（50/50）
16318242100%（50/50）
200640%（0/50）
3190391910100%（50/50）
42657726700%（0/50）
5189401880100%（50/50）
Helloは常に両方のリンクに流れ、TCPは1本だけに流れます。 STEP 1で1本目を落とすとTCPが2本目へ移り、STEP 3で戻すと経路が1本目に戻るのでTCPも1本目へ戻ります。STEP 4はSYNの再送だけが並んでいる状態です。

切り替えの間に落ちたパケット

上の疎通は、設定を変えて収束したあとに測ったものです。切り替えの最中に何発落ちたかは、設定変更の前に流し始めて変更をまたいだpingで測っています（count 150 interval 100 timeout 1）。

STEP操作切り替えをまたいだping
11本目（PE1 Gi0/0/0/1 - P1 Gi0/0/0/0）を両端shutdown149/150（ロス1発）
22本目（PE1 Gi0/0/0/2 - P1 Gi0/0/0/2）も両端shutdown60/150（ロス90発）
32本ともno shutdown127/150（ロス23発）
4PE1にだけLDPの認証を設定62/150（ロス88発）
5認証を削除（最終状態）133/150（ロス17発）
1本目を落としたSTEP 1は1発だけです。 セッションが切れず、転送が2本目へ移っただけなので、断はpingの粒度（100ミリ秒）より短いということしか言えません。2本とも落としたSTEP 2は90発で、こちらはLSPそのものが無い時間の長さです。片側だけ認証を入れたSTEP 4も88発で、セッションが張れない状態がそのまま疎通に出ています。
CE1 → CE2（STEP 0）
RP/0/RP0/CPU0:CE1#ping 192.168.2.1 source 192.168.1.1 count 50 timeout 1
Mon Sep 28 01:40:56.188 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.2.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 16/20/46 ms
CE1 traceroute（STEP 0）
RP/0/RP0/CPU0:CE1#traceroute 192.168.2.1 source 192.168.1.1 timeout 1 probe 2 maxttl 7
Mon Sep 28 01:40:58.079 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 5 msec  4 msec
 2  10.2.3.3 [MPLS: Label 24005 Exp 0] 16 msec  14 msec
 3  10.3.4.4 [MPLS: Label 24006 Exp 0] 14 msec  15 msec
 4  10.4.5.5 [MPLS: Label 24006 Exp 0] 16 msec  16 msec
 5  10.5.6.6 17 msec  14 msec
 6  10.6.7.7 17 msec  *

検証Configおよびshow結果

各STEPで7台すべてから、次の種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態はSTEP 5のもの）。各STEPは「カウンタのクリア → ping → show」の順に採っています。

ファイル内容
..._clear.txtそのSTEPの最初にクリアしたカウンタ（clear counters interfaceとclear mpls forwarding counters）
..._ping.txtping（50発）とtraceroute。CE1 - CE2とPE1 - PE2（Loopback0間、コアのLSP）
..._show.txtshow version / show interface description / show route / OSPF と、LDPの一式（parameters / summary / discovery / neighbor / bindings / forwarding / statistics msg-counters / capabilities）、show tcp brief、MPLS転送、PEはBGP
..._log.txtそのSTEPの範囲だけに絞ったshow logging
..._run.txtそのSTEP時点のshow running-config（＝そのSTEPの検証Config）
..._trace.txtコア5台のみ。show mpls ldp trace peer / discovery / bindingとshow mpls lsd trace
..._commit.cfgそのSTEPで実際にcommitされた設定（変更したルータのみ）

STEP 0：初期状態

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun———
PE1showpingclearlogruntrace——
P1show—clearlogruntrace——
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 1：1本目（PE1 Gi0/0/0/1 - P1 Gi0/0/0/0）を両端shutdown

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntracecfg—
P1show—clearlogruntracecfg—
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 2：2本目（PE1 Gi0/0/0/2 - P1 Gi0/0/0/2）も両端shutdown

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntracecfg—
P1show—clearlogruntracecfg—
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 3：2本ともno shutdown

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntracecfg—
P1show—clearlogruntracecfg—
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 4：PE1にだけLDPの認証を設定

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntracecfg—
P1show—clearlogruntrace——
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 5：認証を削除（最終状態）

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntracecfg—
P1show—clearlogruntrace——
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

パケットキャプチャーはSTEPごとに、PE1 - P1の2本のリンクで取得しています。

STEP1本目（10.2.3.0/24）2本目（10.2.13.0/24）
0pcappcap
1pcappcap
2pcappcap
3pcappcap
4pcappcap
5pcappcap

参考

RFCタイトル概要
RFC 5036LDP SpecificationDiscovery（2.4節）、セッション確立の状態遷移（2.5.4節）、TCP / UDPとも646番（3.10.1節）、メッセージのタイプ値。
RFC 3031Multiprotocol Label Switching Architectureラベル配布プロトコルの位置づけ。

書籍: Luc De Ghein『MPLS Fundamentals』（Cisco Press, 2006）Chapter 4

関連記事