The MPLS Control Plane – LDP

In the last blog post, we discussed key mechanisms found in the MPLS Forwarding Plane. In this post, we are going to examine a key element of the Control Plane – LDP (Label Distribution Protocol).

The MPLS Architecture

We remember from the previous discussions that the Forwarding Equivalence Class (FEC) represents the path that packets are going to take through the MPLS cloud based on a criteria like the iBGP next-hop address (in the common case of L3 MPLS VPNs). Data moves efficiently through the MPLS tunnel thanks to the label swapping behavior of the MPLS devices. But how are these labels distributed and maintained throughout the MPLS cloud?
Well, an administrator could certainly “hand pick and assign” the labels, but this would only be in an environment where the admin is paid by the hour! It is obvious that a dynamic process is needed. There are three dynamic options that are used today:

• Label Distribution Protocol (LDP)
• Resource Reservation Protocol (RSVP)
• Border Gateway Protocol (BGP)

For R&S students, our concern here is limited to LDP (even from a Core Knowledge exam perspective). LDP is detailed in RFC 5036 and is hand-crafted to excel at the dissemination of MPLS labels. It relies 100% on the underlying IGP of the provider for all routing-related needs.
For those readers that have studied IS-IS, you will immediately appreciate LDP’s use of TLVs (Type-Length-Value triplets). Just like in IS-IS, this allows the protocol to be very easily extended to accommodate new capabilities. In the case of IS-IS, you might remember its innate ability to carry IPv6 prefixes.
LDP multicasts hello messages to a well-known UDP port (646) in order to discover neighbors. Once the discovery is accomplished, a TCP connection (port 646) is established and the LDP session begins. LDP keepalives ensure the health of the session. Thanks to the LDP session, LDP messages create the label mappings required for a FEC. Withdraw messages are used when FECs need to be torn down.
It is important to realize that LDP utilizes the underlying IGP to ensure the Label Switched Path (LSP) through the cloud is based on the shortest path, and is also loop free.
Let us “bring this protocol to life” at the command line. We also want to ensure we have some critical verifications committed to non-volatile memory.
Let me configure an LDP session between a PE router (R4) and a P router (R5).
R4 (PE):

Rack24R4#configure terminal
Rack24R4#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Rack24R4(config)#ip cef
Rack24R4(config)#mpls ip
Rack24R4(config)#mpls label protocol ldp
Rack24R4(config)#interface serial 0/1/0
Rack24R4(config-if)#mpls ip
Rack24R4(config-if)#end
Rack24R4#

R5 (P):

Rack24R5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Rack24R5(config)#ip cef
Rack24R5(config)#mpls label protocol ldp
Rack24R5(config)#interface serial 0/1/0
Rack24R5(config-if)#mpls ip
Rack24R5(config-if)#end
Rack24R5#

One of the wonderful, immediate verifications we receive is a system message (unless Cisco is silencing it!) that makes us feel all warm and fuzzy inside. For example, on R4:

Feb 26 14:25:51.723: %LDP-5-NBRCHG: LDP Neighbor 150.24.5.5:0 (1) is UP

In fact, in the CCIE lab exam – this is all I need to see at this stage of a much larger configuration exercise (full-blown L3 MPLS VPN). But here, for learning purposes, let us run some additional verifications. You can immediately envision how valuable these would be on a Trouble Ticket in the Troubleshooting section:

Rack24R4#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
Serial0/1/0            Yes (ldp)     No       No  No     Yes
Rack24R4#
Rack24R4#
Rack24R4#show mpls ldp neighbor
    Peer LDP Ident: 150.24.5.5:0; Local LDP Ident 150.24.4.4:0
 TCP connection: 150.24.5.5.23572 - 150.24.4.4.646
 State: Oper; Msgs sent/rcvd: 20/19; Downstream
 Up time: 00:09:11
 LDP discovery sources:
   Serial0/1/0, Src IP addr: 173.24.45.5
        Addresses bound to peer LDP Ident:
          173.24.39.5     173.24.45.5     150.24.5.5

Understanding the show output is pretty straightforward, although at this stage, one thing that might jump out at you is the Tunnel – No section of show mpls interfaces. This is not relevant for us in R&S as it indicates that we have not enabled the MPLS Traffic Engineering tunnel feature and that RSVP labels are not in use.
Well, I hope you are enjoying the latest blog series. Like solving the exam itself, sometimes studying a complex topic is much easier when we break it down into “baby steps.”