Lesson Contents
This packet capture shows two Cisco routers bringing up an MPLS LDP session, from the first hello to the first label bindings, in about 80 milliseconds. It answers three questions that come up a lot: which router opens the TCP session (the one with the higher transport address), what gets negotiated in the Initialization message, and what a Label Mapping message actually contains, including the implicit null label.
The routers use LSR IDs 1.1.1.1 and 2.2.2.2. The hellos at the start are covered field by field in the MPLS LDP Hello Packet Capture, and the labels exchanged here show up again in the MPLS L3VPN Label Stack Packet Capture. If you want to control which bindings a router advertises, see MPLS LDP label filtering. More captures are in the Packet Capture Library.
Want to open this capture in Wireshark yourself? The pcap file is free with a NetworkLessons account. Your free account also unlocks all our free lessons and every capture in the Packet Capture Library.
Create a free account to download the pcap
Already have an account? Log in and the download button appears here.
Capture overview
| File | mpls-ldp-neighbor-adjacency.pcapng |
| Packets | 20 |
| Protocol | LDP (RFC 5036) |
| Transport | UDP 646 for hellos, TCP 646 for the session |
| Devices | Cisco IOS routers, LSR IDs 1.1.1.1 and 2.2.2.2 |
| Wireshark filter | ldp || tcp.port == 646 |
Packets in this capture
No. Time Source Destination Protocol Info
1 0.000000 192.168.12.1 224.0.0.2 LDP Hello Message
2 0.002329 2.2.2.2 1.1.1.1 TCP 28423 → 646 [SYN]
3 0.004154 192.168.12.2 224.0.0.2 LDP Hello Message
4 0.028900 192.168.12.1 224.0.0.2 LDP Hello Message
5 0.031213 2.2.2.2 1.1.1.1 TCP 46288 → 646 [SYN]
6 0.033052 1.1.1.1 2.2.2.2 TCP 646 → 46288 [SYN, ACK]
7 0.033995 2.2.2.2 1.1.1.1 TCP 46288 → 646 [ACK]
8 0.044225 2.2.2.2 1.1.1.1 LDP Initialization Message
9 0.045026 1.1.1.1 2.2.2.2 TCP 646 → 46288 [ACK]
10 0.055797 1.1.1.1 2.2.2.2 LDP Initialization Message Keep Alive Message
11 0.068280 2.2.2.2 1.1.1.1 LDP Address Message Label Mapping Message (x5)
12 0.080067 192.168.12.2 224.0.0.2 LDP Hello Message
13 0.081328 1.1.1.1 2.2.2.2 LDP Address Message Label Mapping Message (x5)
14 0.280233 2.2.2.2 1.1.1.1 TCP 46288 → 646 [ACK]
15+ ... LDP Hello Message (every ~4-5 seconds)Packet walkthrough
Hellos and the TCP session (packets 1-7)
Both routers send link hellos to 224.0.0.2 on UDP 646. Each hello carries the router’s transport address: 1.1.1.1 and 2.2.2.2, the loopbacks.
Look at who sends the TCP SYN: 2.2.2.2 opens the session to 1.1.1.1 on TCP 646. That isn’t random. Once the routers have discovered each other, the router with the higher transport address is the active LSR and opens the TCP session. The other router is passive and waits. The session is built between loopbacks, not between the interface addresses the hellos came from, so each router needs a route to the other’s loopback.
Initialization message (packet 8)
The active router speaks first with an Initialization message. It proposes the session parameters:
Label Distribution Protocol
Version: 1
PDU Length: 50
LSR ID: 2.2.2.2
Label Space ID: 0
Initialization Message
0... .... = U bit: Unknown bit not set
Message Type: Initialization Message (0x200)
Message Length: 40
Message ID: 0x000000d8
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
Session Receiver LSR Identifier: 1.1.1.1
Session Receiver Label Space Identifier: 0
Cryptographic Authentication TLV
10.. .... = TLV Unknown bits: Unknown TLV, do not Forward (0x2)
TLV Type: Cryptographic Authentication TLV (0x405)
TLV Length: 4
TLV Value: 80000100
Dynamic Capability Announcement
10.. .... = TLV Unknown bits: Unknown TLV, do not Forward (0x2)
TLV Type: Dynamic Capability Announcement (0x506)
TLV Length: 1
TLV Value: 80
Typed Wildcard FEC Capability
10.. .... = TLV Unknown bits: Unknown TLV, do not Forward (0x2)
TLV Type: Typed Wildcard FEC Capability (0x50B)
TLV Length: 1
TLV Value: 80- Session KeepAlive Time 180: if no LDP message arrives within 180 seconds, the session goes down. Both routers use the lower of the two proposed values.
- Downstream Unsolicited: routers advertise labels to every neighbor without being asked. This is what Cisco IOS uses on Ethernet interfaces. The alternative is Downstream on Demand, where a router has to request a label first.
- Loop Detection Disabled: LDP relies on the IGP for loop-free paths, so the path vector loop detection is off.
- Session Receiver LSR Identifier 1.1.1.1:0: the LDP identifier of the router this message is meant for. If it doesn’t match, the receiver rejects the session.
- The last three TLVs are optional capability TLVs, two of them standard LDP capabilities (RFC 5561 and RFC 5918). Wireshark marks them “Unknown” because their U bit is set, which tells a receiver to silently ignore them if it doesn’t support them. They’re not malformed.
In packet 10, 1.1.1.1 answers with its own Initialization message and a KeepAlive in the same TCP segment. The KeepAlive accepts the session parameters. Once each side has received an Initialization and a KeepAlive, the session is operational.
Address and Label Mapping messages (packet 11)
Now the routers advertise their bindings. 2.2.2.2 sends a KeepAlive, an Address message and five Label Mapping messages in one segment. The KeepAlive travels in its own LDP PDU at the start of the segment. Wireshark’s Info column doesn’t list it, and the output below starts after it, at the Address message:
Label Distribution Protocol
LSR ID: 2.2.2.2
Label Space ID: 0
Address Message
Message Type: Address Message (0x300)
Address List
TLV Type: Address List (0x101)
Address Family: IPv4 (1)
Addresses
Address 1: 192.168.23.2
Address 2: 2.2.2.2
Address 3: 192.168.12.2
Label Mapping Message
Message Type: Label Mapping Message (0x400)
FEC
FEC Elements
FEC Element 1
FEC Element Type: Prefix FEC (2)
Prefix: 1.1.1.1
Generic Label
Generic Label: 16 (0x00010)
Label Mapping Message
Message Type: Label Mapping Message (0x400)
FEC
FEC Elements
FEC Element 1
FEC Element Type: Prefix FEC (2)
Prefix: 2.2.2.2
Generic Label
Generic Label: 3 (0x00003)
Label Mapping Message
Message Type: Label Mapping Message (0x400)
FEC
FEC Elements
FEC Element 1
FEC Element Type: Prefix FEC (2)
Prefix: 3.3.3.3
Generic Label
Generic Label: 17 (0x00011)
Label Mapping Message
FEC Element 1: Prefix 192.168.12.0/24
Generic Label: 3 (0x00003)
Label Mapping Message
FEC Element 1: Prefix 192.168.23.0/24
Generic Label: 3 (0x00003)I shortened the output a bit (TLV type and length lines) to keep it readable. The full detail is in the pcap.
- Address message: 2.2.2.2 lists all of its interface addresses. 1.1.1.1 uses this list to map an IGP next hop (192.168.12.2) to an LDP neighbor (2.2.2.2:0). Without it, a router can’t tell which neighbor’s label to use for a given next hop.
- Label Mapping, FEC 1.1.1.1/32 → label 16: “if you send me traffic for 1.1.1.1, use label 16”. 2.2.2.2 advertises this binding to 1.1.1.1 as well, the router that owns the prefix, because Downstream Unsolicited sends every binding to every neighbor.
- FEC 3.3.3.3/32 → label 17: a prefix behind 2.2.2.2 (its neighbor on 192.168.23.0/24). This is the binding 1.1.1.1 uses to label-switch traffic to 3.3.3.3.
- Label 3 for 2.2.2.2/32, 192.168.12.0/24 and 192.168.23.0/24: label 3 is the implicit null label. 2.2.2.2 advertises it for its own connected prefixes. It tells the upstream router to pop the label before forwarding (penultimate hop popping), so 2.2.2.2 receives a plain IP packet. You never see label 3 in a data packet.
Packet 13 is the same exchange in the other direction: 1.1.1.1 sends its address list and bindings to 2.2.2.2.