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 :
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 18.104.22.168 (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.
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 :
R1#show mpls ldp parametersProtocol version: 1No label generic region for downstream label distributionSession hold time: 180 sec; keep alive interval: 60 secDiscovery hello: holdtime: 15 sec; interval: 5 secDiscovery targeted hello: holdtime: 90 sec; interval: 10 secDownstream on Demand max hop count: 255LDP for targeted sessionsLDP initial/maximum backoff: 15/120 secLDP loop detection: off
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 :
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.
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.