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 :

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):

The different MPLS LDP default parameters for the session and the discovery can be seen with this command :

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 :

Let's see if the LID or the Transport Address on R1 and R2 has not changed by using the command below,

Next, let's disable and re-enable the interface Gi0/0 on R1 and Gi2 on R2 and use the same command as before

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 :

1. Configuration
2. Highest IP address of an up and running loopback when LDP comes up
3. 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 :

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

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°:

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.

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.

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.