Label Distribution Protocol (LDP) is a protocol used within MPLS for exchanging label bindings with other MPLS routers within the AS. These labels are then used to negotiate LSP’s throughout the network.
LDP uses an adjacency discovery technique by sending an LDP discovery packet, UDP 646, to the all-routers multicast address of 126.96.36.199. Once an adjacency is discovered, one of the LSRs will take the active roll and the other takes the passive roll. The passive LSR waiting for the active to initiate the connection. This is done via the comparison of unsigned integers but I’m not going to get into the granulars behind that, you’re welcome to read RFC3036 if you’re interested.
If the routers are not directly connected, as with TE tunnels sometimes spanning discontiguous LSRs within the MPLS domain, there is the ability to utilize the LDP Extended Discovery mechanism that is defined within RFC3036. This will allow the LSR to produce a Targeted Hello message toward a defined target LSR. Instead of using the all-routers (188.8.131.52) address, the router will send a unicast discovery packet to the target LSR.
As the RFC states, the basic LDP discovery process is symmetrical, with both LSRs discovering each other and negotiating their role of in the establishment of the LDP session. With LDP Extended Discovery, the process is asymmetrical with one LSR initiating the connection and the targeted LSR deciding whether or not it wants to respond or ignore the request to establish an LDP session. Should the targeted LSR decide it wants to respond, it will do so by sending periodic Targeted Hellos in return.
We’ll start with the following topology :
Routers PE1 and PE2 are not directly connected, therefore they will not establish an LDP adjacency, as seen here in the show mpls ldp neighbors output from PE1.
PE1 has successfully established LDP adjacencies with P1 and P2, but not with PE2. If we were to want to establish LDP adjacency with these two LSRs, the following process would have to be followed :
First, we would need to define a targeted neighbor within the LDP process on one of the PE routers. For this example, we’ll go ahead and define PE1 as the active LSR by issuing the mpls ldp neighbor neighbor-ID targeted ldp command :
By enabling the debug mpls ldp targeted-neighbors, we can see the LDP process kick up and start to attempt to discovery the defined target LSR, on PE1 :
Once PE1 has been setup to target PE2, we can then configure PE2 to accept targeted LDP messages by issuing the mpls ldp discovery targeted-hello accept command :
Once PE2 has been configured to respond to the targeted hellos it is receiving, we can see the adjacency establish through the same debugs :
We can also verify the adjacency by issuing the show mpls ldp neighbor command again – and here we see that 184.108.40.206 is now listed as a valid adjacency :