In
Luc de Ghein's « MPLS fundamentals », at page 72, we learn that
« In Cisco IOS, the MPLS LDP router ID needs to be present in the routing table of the LDP neighboring routers. If it is not, the LDP session is not formed. °»
We want to verify this assertion.
Software used in this scenario :
-
Hypervisor : VMware ESXi 6.0.0 build-2494585
-
Virtual router : IOS XE version 03.14.01.S, IOS version 15.5(1)S1
-
Cisco 3825 : Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9-M), Version 12.3(11)T7, RELEASE SOFTWARE (fc3)
-
Sniffer : Wireshark 2.0.1

Figure
1 : Network Topology Diagram
Find below the starting configuration of R1 and R2 :
=================================== R1 =================================== ! ! to enable LDP because the default on IOS 12.3(11)T7 is TDP ! mpls label protocol ldp ! interface GigabitEthernet0/0 ip address 192.168.10.1 255.255.255.0 no shutdown mpls ip ! ! =================================== R2 =================================== ! interface GigabitEthernet2 ip address 192.168.10.2 255.255.255.0 no shutdown mpls ip ! |
First we need to understand how the LDP session is formed, to do that let's fire up wireshrak on Gi2 of R2
We see that R2 is trying to discover another LDP peer by sending « Hello Message ». Let' take a closer look at one of these frames, for example the frame numbered one
As you can see on the capture above, R2 (192.168.10.2) is trying to establish a LDP connection with a neighbor, by sending a « Hello Message » to the multicast group 224.0.0.2 (all routers on the same network segment) using the source and destination port UDP 646. You can also see that with no loopback or static LDP router ID configured, the LDP session uses the IP address of interface Gi2.
Digression :
Before the IETF standardized LDP for exchanging labels between LSR, Cisco routers used a protocol developped by Cisco called TDP for « Taggued Distribution Protocol ». TDP uses the UDP port 711 to the broadcast address 255.255.255.255.
With the command below, we can see that the LDP identifier (4 bytes) on R2 is indeed Gi2, notice the platform-wide label space (2 bytes) after the LDP ID and also the Transport IP address (which we will discuss later):
R2#show mpls ldp discovery detail Local LDP Identifier:
192.168.10.2:0 Discovery Sources: Interfaces: GigabitEthernet2 (ldp): xmit Enabled: Interface config Hello interval: 5000 ms; Transport IP addr:
192.168.10.2 Clients: IPv4, mLDP |
The different MPLS LDP default parameters for the session and the discovery can be seen with this command :
R1#show mpls ldp parameters Protocol version: 1 No label generic region for downstream label distribution Session hold time: 180 sec; keep alive interval: 60 sec Discovery hello: holdtime: 15 sec; interval: 5 sec Discovery targeted hello: holdtime: 90 sec; interval: 10 sec Downstream on Demand max hop count: 255 LDP for targeted sessions LDP initial/maximum backoff: 15/120 sec LDP loop detection: off |
R2#show mpls ldp parameters LDP Feature Set Manager: State Initialized LDP features: Auto-Configuration Basic ICPM IP-over-MPLS IGP-Sync LLAF TCP-MD5-Rollover TDP NSR Protocol version: 1 Session hold time: 180 sec; keep alive interval: 60 sec Discovery hello: holdtime: 15 sec; interval: 5 sec Discovery targeted hello: holdtime: 90 sec; interval: 10 sec Downstream on Demand max hop count: 255 LDP for targeted sessions LDP initial/maximum backoff: 15/120 sec LDP loop detection: off LDP NSR: Disabled |
Let's take a closer look at the wireshark capture
As you can see on the screenshot above, the LSR R2 sends a TCP SYN to the LSR R1 using its interface GigaEthernet 2 (192.168.10.2) plus the destination port 646. The LSR R1 responds with a SYN/ACK using its interface GigaEthernet 0/0, as we configured. The LDP TCP connection is initiated by the highest LDP ID (LID), here R2 with the LID 192.168.10.2.
We now add a loopback on each LSR R1 and R2 :
=================================== R1 =================================== interface Loopback0 ip address 1.1.1.1 255.255.255.255 =================================== R2 =================================== interface Loopback0 ip address 2.2.2.2 255.255.255.255 |
Let's see if the LID or the Transport Address on R1 and R2 has not changed by using the command below,
R1#show mpls ldp discovery detail Local LDP Identifier:
192.168.10.1:0 Discovery Sources: Interfaces: GigabitEthernet0/0 (ldp): xmit/recv Hello interval: 5000 ms; Transport IP addr:
192.168.10.1 LDP Id: 192.168.10.2:0 Src IP addr: 192.168.10.2; Transport IP addr: 192.168.10.2 Hold time: 15 sec; Proposed local/peer: 15/15 sec |
R2#show mpls ldp discovery detail Local LDP Identifier: 192.168.10.2:0 Discovery Sources: Interfaces: GigabitEthernet2 (ldp): xmit/recv Enabled: Interface config Hello interval: 5000 ms; Transport IP addr:
192.168.10.2 LDP Id: 192.168.10.1:0 Src IP addr: 192.168.10.1; Transport IP addr: 192.168.10.1 Hold time: 15 sec; Proposed local/peer: 15/15 sec Reachable via 192.168.10.0/24 Password: not required, none, in use Clients: IPv4, mLDP |
Next, let's disable and re-enable the interface Gi0/0 on R1 and Gi2 on R2 and use the same command as before
R1#show mpls ldp discovery detail Local LDP Identifier:
1.1.1.1:0 Discovery Sources: Interfaces: GigabitEthernet0/0 (ldp): xmit/recv Hello interval: 5000 ms; Transport IP addr:
1.1.1.1 LDP Id: 2.2.2.2:0; no route to transport addr Src IP addr: 192.168.10.2; Transport IP addr: 2.2.2.2 Hold time: 15 sec; Proposed local/peer: 15/15 sec |
R2#show mpls ldp discovery detail Local LDP Identifier:
2.2.2.2:0 Discovery Sources: Interfaces: GigabitEthernet2 (ldp): xmit/recv Enabled: Interface config Hello interval: 5000 ms; Transport IP addr:
2.2.2.2 LDP Id: 1.1.1.1:0; no route to transport addr Src IP addr: 192.168.10.1; Transport IP addr: 1.1.1.1 Hold time: 15 sec; Proposed local/peer: 15/15 sec Password: not required, none, in use Clients: IPv4, mLDP |
Look at the result above, the LID and the transport address are now equal to the value of the loopback.
As you migth know, the LDP ID is determined by the three rules below, in order of precedence :
-
Configuration
-
Highest IP address of an up and running loopback when LDP comes up
-
Highest IP address of an up and running nonloopback when LDP comes up
We see in Wireshark that the LSR ID and the Transport Address on R1 and R2 are now equal to their respective Loopback0.


What if we want to influence this behavior by specifying a physical interface, according to the previous rules, we can. Let's say we desire to use the interface Gi0/0 as a LID on R1, we just have to use this command :
mpls ldp router-id GigabitEthernet 0/0 force |
Note : the command above will break any LDP connection already established on the link.
Let's do the same on R2 and check the results with the previous command on R1 and R2
R1#show mpls ldp discovery detail Local LDP Identifier: 192.168.10.1:0 Discovery Sources: Interfaces: GigabitEthernet0/0 (ldp): xmit/recv Hello interval: 5000 ms; Transport IP addr:
192.168.10.1 LDP Id: 192.168.10.2:0 Src IP addr: 192.168.10.2; Transport IP addr: 192.168.10.2 Hold time: 15 sec; Proposed local/peer: 15/15 sec
|
R2#show mpls ldp discovery detail Local LDP Identifier: 192.168.10.2:0 Discovery Sources: Interfaces: GigabitEthernet2 (ldp): xmit/recv Enabled: Interface config Hello interval: 5000 ms; Transport IP addr:
192.168.10.2 LDP Id: 192.168.10.1:0 Src IP addr: 192.168.10.1; Transport IP addr: 192.168.10.1 Hold time: 15 sec; Proposed local/peer: 15/15 sec Reachable via 192.168.10.0/24 Password: not required, none, in use Clients: IPv4, mLDP |
According to the RFC 5036, the Transport Address is an optional field defined as such :
IPv4 Transport Address
Specifies the IPv4 address to be used for the sending LSR when
opening the LDP session TCP connection. If this optional TLV
is not present, the IPv4 source address for the UDP packet
carrying the Hello SHOULD be used.
In summary, if the Transport Address is configured, it is used to establish the LDP TCP connection.
In Cisco IOS Version 12.3(11)T7 of R1 (platform 3825), we have the command below to configure the Transport Address using the Loopback0°:
mpls ldp discovery transport-address 1.1.1.1 |
Note : Virtual router : IOS XE version 03.14.01.S, IOS version 15.5(1)S1 does not support the command above.
Let's switch to the Wireshark capture
LSR R1 is now using its Loopback0 interface as its Transport Address though the LSR ID of R1 is still its interface GigabitEthernet 0/0.
R1#show mpls ldp discovery detail Local LDP Identifier: 192.168.10.1:0 Discovery Sources: Interfaces: GigabitEthernet0/0 (ldp): xmit/recv Hello interval: 5000 ms; Transport IP addr:
1.1.1.1 LDP Id: 192.168.10.2:0 Src IP addr: 192.168.10.2; Transport IP addr: 192.168.10.2 Hold time: 15 sec; Proposed local/peer: 15/15 sec |
Notice that in the Wireshark capture, the LDP session is down

Now, if we add a static route to the Loopback0 of R1 on R2, the LDP session should be up again.
ip route 1.1.1.1 255.255.255.255 192.168.10.1 |
Indeed, we observe the LDP session is established in the Wireshark capture below. R1 is now using its transport address to establish the LDP session.

Conclusion,
Luc de Ghein's assertion « In Cisco IOS, the MPLS LDP router ID needs to be present in the routing table of the LDP neighboring routers. If it is not, the LDP session is not formed. °» is verified but it is a particular case. It is Mr de Ghein's assumes that the value of the LDP ID is equal to the transport address, this is true in most MPLS cases but as we learned in this lab, you can customize your LDP session to use the transport address instead of the LDP router ID to establish the LDP session. If you do you will have to configure a static route or advertise the address using an IGP because the neighboring LSR needs to know how to reach the transport address you configured.