Label Distribution Protocol (LDP) is one of the protocols that can be used for MPLS to distribute labels. Other protocols are RSVP-TE, BGP, and IGPs (ISIS and OSPF). This short post addresses LDP and how it works.
I’m using two routers to talk about LDP in this post. R2 and R3 that are connected like this:
LDP is very simple to configure. It is basically just one command needed.
! R2 (IOS-XE) interface GigabitEthernet1.23 encapsulation dot1Q 23 ip address 10.0.23.2 255.255.255.0 ip router isis 1 mpls ip isis network point-to-point
For IOS XR the configuration is this:
mpls ldp interface GigabitEthernet0/0/0/0.23
LDP establishes adjacencies between directly connected routers. It does so by using a multicast hello packet that looks like this:
This is an LDP Hello Message sent by LSR (Label Switching Router) R3. This we can see by looking at the IP header which is sourced from 10.0.23.3. We can also look inside the MPLS header and find the LSR ID of 188.8.131.52 which is R3’s Loopback0 address. The destination of the packet is 184.108.40.206 which is the link local all routers multicast address. And the TTL (not shown) is set to 1. So this truly is a link local discovery message asking to see if any other LDP enabled routers are available on the link. The UDP port numbers are 646 both for the source and destination ports. Finally, in the LDP header, we see an IPv4 transport address. This lets other LDP enabled routers known to which address they should form a TCP session once they’ve discovered each other. So this address has to be routable.
Next in the process of establishing an adjacency the routers send LDP Initialization Messages:
These messages are sent after the three way TCP handshake and lets each know the capabilities of each other along with an authentication TLV.
Finally LDP exchanges labels using Address packets:
First (not expanded) is an LDP header that contains a keepalive. The last LDP header contains the addresses bound to ourselves (essentially all our interface addresses). Here we also see the various Label Mapping Messages that contains the actual labels to be used by the neighbor (R2). I’ve expanded one of them listing the prefix 220.127.116.11/32 which is the loopback of R3 (the advertising router). The label value is 3 which is actually referred to as an implicit-null label. This means that the router receiving this label (R2) should pop (remove) the label before sending the packet to this router (R3). We call this process PHP (Penultimate Hop Popping).
We can verify LDP by looking at R2:
R2#sh mpls ldp bindings 18.104.22.168 32 lib entry: 22.214.171.124/32, rev 6 local binding: label: 200 remote binding: lsr: 126.96.36.199:0, label: imp-null R2#
This is the LRIB (Label Routing Information Base) of R2 for prefix 188.8.131.52/32. Here we see the label that we (R2) has allocated for 184.108.40.206/32 (200) and also we see the received binding from R3 which is the imp-null label.
The LFIB (Label Forwarding Information Base) also verifies this:
R2#sh mpls forwarding-table 220.127.116.11 32 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 200 Pop Label 18.104.22.168/32 0 Gi1.23 10.0.23.3 R2#
If R2 had received multiple remote bindings for 22.214.171.124/32 it would pick the label advertised by the LDP neighbor found by looking at the routing table and the LDP neighbor table. Let me demonstrate this. Again looking at R2:
R2#sh ip route 126.96.36.199 Routing entry for 188.8.131.52/32 Known via "isis", distance 115, metric 10, type level-2 Redistributing via isis 1 Last update from 10.0.23.3 on GigabitEthernet1.23, 3d20h ago Routing Descriptor Blocks: * 10.0.23.3, from 184.108.40.206, 3d20h ago, via GigabitEthernet1.23 Route metric is 10, traffic share count is 1 R2#
We have a route for 220.127.116.11/32 received from R3 (18.104.22.168). The next hop is 10.0.23.3 out Gi1.23. This information, in particular the next hop, can be used to decided from which neighbor we should pick a label for 22.214.171.124/32. We do so by looking at all our LDP neighbors:
R2#sh mpls ldp neighbor Peer LDP Ident: 126.96.36.199:0; Local LDP Ident 188.8.131.52:0 TCP connection: 184.108.40.206.18131 - 220.127.116.11.646 State: Oper; Msgs sent/rcvd: 84/83; Downstream Up time: 01:04:08 LDP discovery sources: GigabitEthernet1.23, Src IP addr: 10.0.23.3 Addresses bound to peer LDP Ident: 10.0.23.3 10.0.34.3 18.104.22.168 R2#
The important piece of information here is the Addresses bound to peer LDP Ident. This is where we correlate the next hop to the LDP neighbor. In this case R3 as the LDP neighbor. Now we know that R2 must use the imp-null (pop) action when sending packets to 22.214.171.124/32.