What Is LDP
LDP (Label Distribution Protocol, RFC 5036) distributes MPLS labels to neighbouring routers. The routes themselves come from OSPF or IS-IS; LDP carries only the mapping that says “this is the label I use for that prefix”. This article explains how LDP finds a neighbour, builds a session and advertises labels, then follows a full establishment packet by packet in an IOS XR (XRd) lab. Label operations are covered in MPLS Label Operations (push / swap / pop) and PHP.
The three stages of LDP
LDP works in three stages.
| Stage | Transport | What happens |
|---|---|---|
| Discovery | UDP 646, sent to 224.0.0.2 | Hellos find neighbouring LSRs |
| Session | TCP 646 | A TCP connection is opened to the peer and parameters are agreed |
| Advertisement | The same TCP connection | Addresses and label mappings are sent |
Only the Hello is multicast. Once the peer is known, everything moves to a unicast TCP connection. The side with the higher transport address opens the connection; the lower one listens.
The LDP Identifier
LDP identifies a peer by its LDP Identifier, six octets written as <LSR Id>:<label space>.
The first four octets identify the router and are normally set to the same value as the router ID. The last two are the label space number, where 0 means a single label space for the whole platform. A non-zero value is used when label spaces are kept per interface.
LDP messages
RFC 5036 defines eleven messages. The Type is two octets and each message has its own number.
| Message | Type | Role |
|---|---|---|
| Notification | 0x0001 | Reports an error or the end of a session |
| Hello | 0x0100 | Finds neighbours. The only message sent over UDP |
| Initialization | 0x0200 | Proposes the session parameters |
| KeepAlive | 0x0201 | Keeps the session alive |
| Address | 0x0300 | Announces the IP addresses the router owns |
| Address Withdraw | 0x0301 | Withdraws an announced address |
| Label Mapping | 0x0400 | Announces a prefix-to-label mapping |
| Label Request | 0x0401 | Requests a label (used by Downstream-on-Demand) |
| Label Withdraw | 0x0402 | Withdraws a label that was advertised |
| Label Release | 0x0403 | Returns a label that was received |
| Label Abort Request | 0x0404 | Cancels an outstanding request |
The withdraw and release messages are used when a route disappears or a session goes down.
Address is needed because the LDP Identifier and the IP address a label is attached to are different things. The receiver uses the list learned from Address to work out which LDP peer a given next hop belongs to.
How labels are advertised
The IOS XR default is Downstream-Unsolicited: a router advertises its labels without waiting to be asked. The alternative, Downstream-on-Demand, advertises only on request and uses Label Request. The difference between the modes is covered in LDP Label Distribution Modes and Label Spaces.
When a session comes up, the router first sends Address with its own addresses, then one Label Mapping for every prefix it holds. After that only changes are sent, and KeepAlive maintains the connection.
Discovery and Session are counted differently
Of the three stages, Discovery is per link and Session is per peer. The two do not correspond, so the numbers diverge as soon as there is more than one link.
| Item | Discovery | Session |
|---|---|---|
| Unit | One per interface | One per LDP peer |
| Address used | The interface IP address | The transport address, normally a loopback |
| Transport | UDP 646 multicast | TCP 646 unicast |
| How the peer is chosen | Found by multicast | Connect to the transport address learned from Hello |
| Role | Learn which LSR is next door | Build a reliable channel for carrying labels |
| Time before it is declared down | Hello hold time, 15 seconds | Session hold time, 180 seconds |
Connect PE1 and P1 with two links and there are two Discoveries but one Session. LDP identifies a peer by its LDP Identifier, which is a label space. When the label space is :0, one per platform, the same label is valid whichever link it arrived on, so there is no reason to split the session.
The asymmetry matters operationally. Losing one link does not bring the session down. One Discovery Source disappears and the TCP connection continues over what remains, so labels are not redistributed on every link failure. Conversely, when every link goes down the Discovery Sources reach zero and the session ends.
Lab verification
Lab setup
CE1, PE1, P1, P2, P3, PE2, and CE2 are connected in a row, with two links between PE1 and P1. PE1 / P1 / P2 / P3 / PE2 in AS 65001 form the MPLS network, with OSPF (area 0, every link network point-to-point) distributing routes and LDP distributing labels. CE1 and CE2 exchange routes with the PEs over eBGP, and PE1 and PE2 peer over iBGP between their Loopback0 addresses (next-hop-self). Every router is XRd.
The second link (10.2.13.0/24) carries an OSPF cost of 100, so the route points at the first link and LDP’s TCP connection follows it.
| Router | Lo0 | Links | Discovery / Session |
|---|---|---|---|
| CE1 | 1.1.1.1/32 | Gi0/0/0/0 10.1.2.1 (AS 65101, 192.168.1.0/24) | No LDP |
| PE1 | 2.2.2.2/32 | Gi0/0/0/0 10.1.2.2 / Gi0/0/0/1 10.2.3.2 / Gi0/0/0/2 10.2.13.2 | 2 / 1 |
| P1 | 3.3.3.3/32 | Gi0/0/0/0 10.2.3.3 / Gi0/0/0/1 10.3.4.3 / Gi0/0/0/2 10.2.13.3 | 3 / 2 |
| P2 | 4.4.4.4/32 | Gi0/0/0/0 10.3.4.4 / Gi0/0/0/1 10.4.5.4 | 2 / 2 |
| P3 | 5.5.5.5/32 | Gi0/0/0/0 10.4.5.5 / Gi0/0/0/1 10.5.6.5 | 2 / 2 |
| PE2 | 6.6.6.6/32 | Gi0/0/0/0 10.5.6.6 / Gi0/0/0/1 10.6.7.6 | 1 / 1 |
| CE2 | 7.7.7.7/32 | Gi0/0/0/0 10.6.7.7 (AS 65102, 192.168.2.0/24) | No LDP |
Both PE1 - P1 links were captured in every STEP.
Verification steps
| STEP | Action | What to confirm |
|---|---|---|
| 0 | Initial state | The LDP Identifier, two Discovery sources and one Session, the labels distributed |
| 1 | shutdown both ends of link 1 | The session stays up and the TCP connection moves to link 2. The withdraw messages flow |
| 2 | shutdown link 2 as well | The Discovery sources drop to zero and the session ends |
| 3 | no shutdown on both links | The whole establishment fits in one capture |
| 4 | Configure authentication on PE1 only | Hellos keep flowing but the TCP stage fails |
| 5 | Remove the authentication (final state) | Back to the same state as STEP 0 |
The LDP Identifier and Hellos
Here is PE1’s discovery. Its own LDP Identifier is 2.2.2.2:0 and the peer’s is 3.3.3.3:0, and the two interfaces appear as separate discovery sources.
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 means Hellos are being sent and received. The hold time is 15 seconds; if no Hello arrives within it, the peer is considered lost. The transport address is 3.3.3.3 (P1’s Loopback0) on both.
Discovery is per link, a session is per peer
show mpls ldp summary puts both counts on screen. PE1 has two hello adjacencies and one neighbour, because the same peer faces it over two links. P2 instead faces two different peers over one link each, so it has two hello adjacencies and two neighbours. P1 has two links to PE1 and one to P2: three hello adjacencies and two neighbours.
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 configuredRP/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 configuredRP/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 configuredPE1’s neighbour detail shows one Peer LDP Identifier and one TCP connection, with LDP Discovery Sources: IPv4: (2) listing the two interfaces under it. Two discoveries collapsing into one session is readable in this single screen.
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)The session itself is a TCP connection. show tcp brief lists port 646: P1 (3.3.3.3), which has the higher transport address, connects, and PE1 listens on 646.
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 CLOSEDThe distributed labels are in show mpls ldp bindings. For PE2’s Loopback0 (6.6.6.6/32), PE1 holds its own 24006 and 24005 received from P1.
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 24005Losing one link does not end the session
Both ends of the first link are shut down.
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
!
endRP/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
!
endThe syslog shows the OSPF adjacency going down and the hello adjacency (HELLO_ADJ_CHANGE), but no LDP neighbour-down message (NBR_CHANGE).
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)In the neighbour detail, both the TCP port numbers and the Up time continue from STEP 0. Only the discovery sources went from two to one.
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:In the captures the TCP traffic disappears from link 1 and appears on link 2, and Hellos flow only on the remaining link. The addresses and labels of the lost link are withdrawn, so Address Withdraw, Label Withdraw and Label Release travelled over the session on link 2.
$ 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 Messageshow mpls ldp statistics msg-counters shows the same events as counts.
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 25Traffic from CE1 to CE2 keeps flowing throughout (50 of 50). Because the session never drops, the labels are not reassigned and forwarding simply continues over the second link.
Losing every link ends the session
With the second link down as well, the discovery sources drop to zero, and only then does the LDP neighbour go down.
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)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:Nothing is listed under Discovery Sources:. Traffic from CE1 to CE2 fails too (0%), because the route to P1 itself is gone.
The whole establishment
Bringing both links back with no shutdown puts the entire establishment, starting from the TCP three-way handshake, into a single capture.
$ 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=0After SYN, SYN-ACK and ACK, Initialization flows both ways, KeepAlive confirms it, and Address and Label Mapping follow. From the handshake to the labels takes 0.08 seconds.
No.37 is the Initialization sent by P1, carrying the LDP Identifier and the session parameters.
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: 0Session KeepAlive Time: 180 is the hold time being proposed. RFC 5036 only specifies that the lower of the two proposed values is used; the sending interval is left to the implementation. IOS XR sends a KeepAlive every third of that value, 60 seconds here. Session Max PDU Length: 0 proposes the maximum PDU length, and a value of 255 or less means the default of 4096 octets (RFC 5036 section 3.5.3).
No.40 is one TCP segment holding the Address message and 11 Label Mapping messages that PE1 sent. ldp.msg.type lists the message type values (0x300 = Address, 0x400 = Label Mapping).
$ 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,23A mismatched password fails at the TCP stage
LDP authentication (TCP MD5) is configured on PE1 only.
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
!
!
endHellos are not authenticated, so discovery stays at xmit/recv and the peer’s LDP Identifier is still visible.
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)And yet there are no neighbours.
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief
Mon Sep 28 04:37:53.440 UTCThe syslog gives the reason: TCP checks the MD5 signature and rejects the segment.
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)The capture holds nothing but retransmitted SYNs. Not a single LDP message flows.
$ 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=1Traffic from CE1 to CE2 fails at this point as well. The links and OSPF are healthy, but without labels P1 / P2 / P3 cannot decide where to forward (they carry no BGP, so they cannot look up a customer prefix as IP). When LDP stops, the data plane stops with it. Configuring the authentication itself is covered in LDP Session Authentication (TCP MD5).
The messages observed
Eight message types appeared in this lab, and their type values match the definitions in RFC 5036.
| Message | Type | Where it was observed |
|---|---|---|
| Notification | 0x0001 | Session teardown (STEP 2 / 4) |
| Hello | 0x0100 | Every STEP (UDP 646, every 5 seconds) |
| Initialization | 0x0200 | Establishment (STEP 3) |
| KeepAlive | 0x0201 | Every STEP (every 60 seconds) |
| Address | 0x0300 | Right after establishment (STEP 3) |
| Address Withdraw | 0x0301 | Link failure (STEP 1) |
| Label Mapping | 0x0400 | After establishment and on route changes (STEP 1 / 3) |
| Label Withdraw | 0x0402 | Link failure (STEP 1) |
| Label Release | 0x0403 | Answering the withdraw at link failure (STEP 1) |
The lab runs Downstream-Unsolicited, so Label Request (0x0401) and Label Abort Request (0x0404) never appear.
Traffic per link and reachability
For each STEP, here are the Hello (UDP 646) and TCP 646 packet counts on the two links, together with reachability from CE1 to CE2.
| STEP | Link 1 Hello | Link 1 TCP 646 | Link 2 Hello | Link 2 TCP 646 | CE1 to CE2 |
|---|---|---|---|---|---|
| 0 | 119 | 20 | 118 | 0 | 100%（50/50） |
| 1 | 6 | 3 | 182 | 42 | 100%（50/50） |
| 2 | 0 | 0 | 6 | 4 | 0%（0/50） |
| 3 | 190 | 39 | 191 | 0 | 100%（50/50） |
| 4 | 265 | 77 | 267 | 0 | 0%（0/50） |
| 5 | 189 | 40 | 188 | 0 | 100%（50/50） |
| Hellos always flow on both links while TCP uses only one. Shutting link 1 in STEP 1 moves the TCP connection to link 2; restoring the links in STEP 3 puts the route, and with it the TCP connection, back on link 1. STEP 4 is the state where only retransmitted SYNs are left. |
Packets lost while the path switched
The reachability above was measured after each change had converged. How many packets were lost during the switch itself comes from a ping started before the change and left running across it (count 150 interval 100 timeout 1).
| STEP | Operation | Ping across the change |
|---|---|---|
| 1 | shutdown both ends of link 1 (PE1 Gi0/0/0/1 - P1 Gi0/0/0/0) | 149/150 (1 lost) |
| 2 | shutdown both ends of link 2 (PE1 Gi0/0/0/2 - P1 Gi0/0/0/2) as well | 60/150 (90 lost) |
| 3 | no shutdown on both links | 127/150 (23 lost) |
| 4 | Configure LDP authentication on PE1 only | 62/150 (88 lost) |
| 5 | Remove the authentication (final state) | 133/150 (17 lost) |
| STEP 1, which shut link 1, lost a single packet. The session never dropped and forwarding simply moved to link 2, so all that can be said is that the outage was shorter than the ping interval of 100 ms. STEP 2, which shut both links, lost 90: that is how long there was no LSP at all. STEP 4, with authentication on one end only, lost 88 — a session that cannot come up shows up directly in reachability. |
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 msRP/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 *Verification config and show output
For every STEP the following files were collected from all seven routers, one file per router. The verification config is the ..._run.txt (the final state is the one from STEP 5). Each STEP was collected in the order “clear the counters, ping, then show”.
| File | Contents |
|---|---|
..._clear.txt | The counters cleared at the start of the STEP (clear counters interface and clear mpls forwarding counters) |
..._ping.txt | ping (50 packets) and traceroute: CE1 - CE2 and PE1 - PE2 (between Loopback0, the core LSP) |
..._show.txt | show version / show interface description / show route / OSPF, the LDP set (parameters / summary / discovery / neighbor / bindings / forwarding / statistics msg-counters / capabilities), show tcp brief, MPLS forwarding, and BGP on the PEs |
..._log.txt | show logging limited to the range of that STEP |
..._run.txt | show running-config at that STEP (that is, the verification config for the STEP) |
..._trace.txt | The five core routers only: show mpls ldp trace peer / discovery / binding and show mpls lsd trace |
..._commit.cfg | The configuration actually committed in that STEP (only the routers that were changed) |
STEP 0: Initial state
| Router | show | ping | clear | syslog | running-config | trace | committed config | outage ping |
|---|---|---|---|---|---|---|---|---|
| CE1 | show | ping | clear | log | run | — | — | — |
| PE1 | show | ping | clear | log | run | trace | — | — |
| P1 | show | — | clear | log | run | trace | — | — |
| P2 | show | — | clear | log | run | trace | — | — |
| P3 | show | — | clear | log | run | trace | — | — |
| PE2 | show | ping | clear | log | run | trace | — | — |
| CE2 | show | ping | clear | log | run | — | — | — |
STEP 1: shutdown both ends of link 1 (PE1 Gi0/0/0/1 - P1 Gi0/0/0/0)
| Router | show | ping | clear | syslog | running-config | trace | committed config | outage ping |
|---|---|---|---|---|---|---|---|---|
| CE1 | show | ping | clear | log | run | — | — | outage |
| PE1 | show | ping | clear | log | run | trace | cfg | — |
| P1 | show | — | clear | log | run | trace | cfg | — |
| P2 | show | — | clear | log | run | trace | — | — |
| P3 | show | — | clear | log | run | trace | — | — |
| PE2 | show | ping | clear | log | run | trace | — | — |
| CE2 | show | ping | clear | log | run | — | — | — |
STEP 2: shutdown both ends of link 2 (PE1 Gi0/0/0/2 - P1 Gi0/0/0/2) as well
| Router | show | ping | clear | syslog | running-config | trace | committed config | outage ping |
|---|---|---|---|---|---|---|---|---|
| CE1 | show | ping | clear | log | run | — | — | outage |
| PE1 | show | ping | clear | log | run | trace | cfg | — |
| P1 | show | — | clear | log | run | trace | cfg | — |
| P2 | show | — | clear | log | run | trace | — | — |
| P3 | show | — | clear | log | run | trace | — | — |
| PE2 | show | ping | clear | log | run | trace | — | — |
| CE2 | show | ping | clear | log | run | — | — | — |
STEP 3: no shutdown on both links
| Router | show | ping | clear | syslog | running-config | trace | committed config | outage ping |
|---|---|---|---|---|---|---|---|---|
| CE1 | show | ping | clear | log | run | — | — | outage |
| PE1 | show | ping | clear | log | run | trace | cfg | — |
| P1 | show | — | clear | log | run | trace | cfg | — |
| P2 | show | — | clear | log | run | trace | — | — |
| P3 | show | — | clear | log | run | trace | — | — |
| PE2 | show | ping | clear | log | run | trace | — | — |
| CE2 | show | ping | clear | log | run | — | — | — |
STEP 4: Configure LDP authentication on PE1 only
| Router | show | ping | clear | syslog | running-config | trace | committed config | outage ping |
|---|---|---|---|---|---|---|---|---|
| CE1 | show | ping | clear | log | run | — | — | outage |
| PE1 | show | ping | clear | log | run | trace | cfg | — |
| P1 | show | — | clear | log | run | trace | — | — |
| P2 | show | — | clear | log | run | trace | — | — |
| P3 | show | — | clear | log | run | trace | — | — |
| PE2 | show | ping | clear | log | run | trace | — | — |
| CE2 | show | ping | clear | log | run | — | — | — |
STEP 5: Remove the authentication (final state)
| Router | show | ping | clear | syslog | running-config | trace | committed config | outage ping |
|---|---|---|---|---|---|---|---|---|
| CE1 | show | ping | clear | log | run | — | — | outage |
| PE1 | show | ping | clear | log | run | trace | cfg | — |
| P1 | show | — | clear | log | run | trace | — | — |
| P2 | show | — | clear | log | run | trace | — | — |
| P3 | show | — | clear | log | run | trace | — | — |
| PE2 | show | ping | clear | log | run | trace | — | — |
| CE2 | show | ping | clear | log | run | — | — | — |
Packet captures were taken per STEP on both PE1 - P1 links.
| STEP | Link 1 (10.2.3.0/24) | Link 2 (10.2.13.0/24) |
|---|---|---|
| 0 | pcap | pcap |
| 1 | pcap | pcap |
| 2 | pcap | pcap |
| 3 | pcap | pcap |
| 4 | pcap | pcap |
| 5 | pcap | pcap |
References
| RFC | Title | Summary |
|---|---|---|
| RFC 5036 | LDP Specification | Discovery (section 2.4), the session establishment state machine (2.5.4), port 646 for both TCP and UDP (3.10.1) and the message Type values. |
| RFC 3031 | Multiprotocol Label Switching Architecture | Where a label distribution protocol fits. |
Book: Luc De Ghein, MPLS Fundamentals (Cisco Press, 2006), Chapter 4
Related articles
- What Is MPLS
- MPLS Labels and the Label Stack
- MPLS Label Operations (push / swap / pop) and PHP
- MPLS TTL Processing and MTU
- What Is LDP
- LDP Label Distribution Modes and Label Spaces
- LDP-IGP Synchronization and LDP Session Protection
- LDP label advertisement control (filtering)
- LDP session authentication (TCP MD5)
- MPLS OAM (LSP ping and LSP traceroute)
- What Is MPLS TE (RSVP-TE)
- MPLS TE CSPF and Path Constraints (Bandwidth, Affinity, TE Metric)
- Steering Traffic into MPLS TE Tunnels
- MPLS TE Fast Reroute (Link and Node Protection)
- MPLS TE Fast Reroute (Auto-Tunnel Backup and SRLG)
- MPLS QoS (EXP and Uniform / Pipe / Short-Pipe)
- MPLS QoS Rate Control and Queuing (policer / shaper / priority)