LDP

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:

Configuration

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

Packets

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 3.3.3.3 which is R3’s Loopback0 address. The destination of the packet is 224.0.0.2 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 3.3.3.3/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).

Verification

We can verify LDP by looking at R2:

R2#sh mpls ldp bindings 3.3.3.3 32
  lib entry: 3.3.3.3/32, rev 6
        local binding:  label: 200
        remote binding: lsr: 3.3.3.3:0, label: imp-null
R2#

This is the LRIB (Label Routing Information Base) of R2 for prefix 3.3.3.3/32. Here we see the label that we (R2) has allocated for 3.3.3.3/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 3.3.3.3 32 
Local      Outgoing   Prefix         Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id   Switched      interface              
200        Pop Label  3.3.3.3/32     0             Gi1.23     10.0.23.3   
R2#

If R2 had received multiple remote bindings for 3.3.3.3/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 3.3.3.3
Routing entry for 3.3.3.3/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 3.3.3.3, 3d20h ago, via GigabitEthernet1.23
      Route metric is 10, traffic share count is 1
R2#

We have a route for 3.3.3.3/32 received from R3 (3.3.3.3). 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 3.3.3.3/32. We do so by looking at all our LDP neighbors:

R2#sh mpls ldp neighbor
    Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0
        TCP connection: 3.3.3.3.18131 - 2.2.2.2.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       3.3.3.3         
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 3.3.3.3/32.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.