Cart
– The following is an excerpt from the upcoming edition of the:
IPexpert MPLS Operation and Troubleshooting book.
Introduction to Label Distribution
Thus far in this book we have discussed the values and characteristics of labels, we have dealt with their meaning and how they affect the creation of both the control and forwarding planes used in MPLS. Throughout this entire process we have only loosely referred to the exchange of labels between label switching devices. Now it is time to discuss the process and mechanism behind this exchange or advertising process.
There are two methods at our disposal to exchange labels and their associated bindings between devices that are peered. The key word here is “peered”. Whether we are using the Cisco proprietary Tag Switching or the industry standard Label Distribution Protocol (LDP) as the mechanism of choice to communicate label information, it all still boils down simply to peering relationships and the rules governing those peers. For the purpose of our discussion we will deal specifically with LDP from this point forward.
When MPLS is enabled on an integrated services router (ISR) LDP is the default label distribution protocol. It is this protocol that dynamically creates and governs the label switched path in our network. So it must be noted that everything we have discussed up to this point regarding label generation, assignment, and exchange is maintained by this single protocol. Additionally LDP is also responsible for the formation of the peering relationships we mentioned earlier. It is these relationships that facilitate the exchange of our local label bindings between peers.
At this time we should define and innumerate the major operational roles this protocol will be responsible for in terms our discussions in this chapter. Primarily we can outline three such functions:
- Dynamic discovery of adjacent LDP Peers
- Peering and session establishment
- Regulation of peer-to-peer communication and label exchange
We will now initiate an introduction to the concepts associated with these major operational functions in their own individual sections.
Dynamic Discovery of Adjacent LDP Peers
To learn more about the operation and detailed functions associated with LDP you can read RFC 3036, where the process of peer discovery and adjacency formation is discussed in depth. However, for the purposes of our discussions and the application of this knowledge toward the goal of fault isolation and remediation we will make specific references to only a portion of the information in the RFC in this chapter.
For the purposes of our discussion we are going to look at LDP using the same context as that used to understand a link state protocol like say OSPF. We know that an OSPF or even EIGRP enabled device will first attempt to form a peering relationship with neighboring devices with whom it shares a network segment. We also know that once this process produces an adjacency between devices these adjacencies are constantly probed to determine if they are still up and operational via things like HELLO packets. The good news here is that LDP performs much the same way. There are rules governing each phase of these processes that relate specifically to LDP but we will be careful to point them out as we progress through this discussion.
We have effectively defined three operational phases in this section, first a neighbor discovery phase, then a session establishment phase, and lastly a session maintenance phase. We will look closely at the first of these three phases to better understand the process that is taking place.
Neighbor Discovery
When it comes to neighbor discovery LDP relies on using traffic destined to the well-known UDP port 646. This process describes the discovery HELLO mechanism used by LDP to find neighbors. However, there are actually two mechanisms used to do this. Method one is referred to as the basic neighbor discovery mechanism. With basic neighbor discovery the LSR uses multicast hellos to communicate with directly connected neighbors. However, there is another mechanism used to allow peering between non-directly connected devices using a unicast discovery HELLO. This non-directly connected peering is known as extended neighbor discovery. It must be pointed out that whether basic or extended neighbor discovery mechanisms are in play the discovery communication in LDP is always going to be via UDP port 646.
We can see this process clearly if we configure R1 to run mpls in the topology as seen in Figure 3-1.
Figure 3-1: Basic MPLS topology
In this demonstration we will configure R1 such that we will capture all ip packets inbound our outbound that use UDP port 646. We will accomplish this via an access-list to filter our debug ip packet command.
R1(config)#access-list 100 permit udp any any eq 646 R1(config)#access-list 100 permit udp any eq 646 any R1(config)#exit R1#debug ip packet detail 100 IP packet debugging is on (detailed) for access list 100
Now we will enable MPLS on R1 and observe the results as they transpire.
R1(config)#interface FastEthernet0/0 R1(config-if)#mpls ip
This will immediately result in output associated with the debug operation:
IP: s=172.16.15.1 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending broad/multicast UDP src=646, dst=646 IP: s=172.16.15.1 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending full packet UDP src=646, dst=646 IP: s=172.16.15.1 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending broad/multicast UDP src=646, dst=646 IP: s=172.16.15.1 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending full packet UDP src=646, dst=646 IP: s=172.16.15.1 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending broad/multicast UDP src=646, dst=646 IP: s=172.16.15.1 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending full packet UDP src=646, dst=646 IP: s=172.16.15.1 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending broad/multicast UDP src=646, dst=646 IP: s=172.16.15.1 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending full packet UDP src=646, dst=646
Observe how R1 is now sending ip packets destined to the multicast address 224.0.0.2 both sourced and destined to the UDP port 646. First the router sends what it calls a “broad/multicast” packet then it subsequently sends a “full” packet. The point here is that LDP is attempting to find a neighbor that is running LDP. Can we see these packets arrive on R5 in our topology?
We can see what happens on R5 by using the same filter and the same debug:
R5>en R5#conf t Enter configuration commands, one per line. End with CNTL/Z. R5(config)#access-list 100 permit udp any any eq 646 R5(config)#access-list 100 permit udp any eq 646 any R5(config)#end R5#debug ip packet detail 100 IP packet debugging is on (detailed) for access list 100 R5#
As packets arrive on R5 we see some interesting behavior:
IP: s=172.16.15.1 (FastEthernet0/0), d=224.0.0.2, len 62, rcvd 0 UDP src=646, dst=646 FIBipv4-packet-proc: route packet from FastEthernet0/0 src 172.16.15.1 dst 224.0.0.2 FIBfwd-proc: Default:224.0.0.0/24 receive entry FIBipv4-packet-proc: packet routing failed pak 47D578D4 consumed in input feature , packet consumed, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Observe that the packet sourced from R1 (172.16.15.1) arrives and R5 does not know what to do with it. Note the “packet routing failed” message. What would happen if we activated MPLS on R5’s FastEthernet0/0 interface?
R5#conf t Enter configuration commands, one per line. End with CNTL/Z. R5(config)#interface FastEthernet0/0 R5(config-if)#mpls ip R5(config-if)#end
We see now that R5 sends its own packets out.
IP: s=172.16.15.5 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending broad/multicast UDP src=646, dst=646 IP: s=172.16.15.5 (local), d=224.0.0.2 (FastEthernet0/0), len 62, sending full packet UDP src=646, dst=646
Observe that on R1 we see the following message:
R1(config)# *Jun 19 16:38:50.534: %LDP-5-NBRCHG: LDP Neighbor 192.1.5.5:0 (1) is UP
According to this output we now have a neighbor adjacency between R1 and R5. We can verify this via the use of the show mpls ldp neighbor command:
R1#show mpls ldp neighbor Peer LDP Ident: 192.1.5.5:0; Local LDP Ident 192.1.1.1:0 TCP connection: 192.1.5.5.21288 - 192.1.1.1.646 State: Oper; Msgs sent/rcvd: 10/11; Downstream Up time: 00:04:24 LDP discovery sources: FastEthernet0/0, Src IP addr: 172.16.15.5 Addresses bound to peer LDP Ident: 172.16.15.5 192.1.5.5
We have just observed the natural behavior of LDP. The moment two neighbors exchange LDP Discovery Hello messages these devices will attempt to establish an LDP session. Unfortunately, this mechanism happens to fast for us to truly be able to observe the two step process used to establish LDP sessions, but we will discuss the actual process involved with peer and session establishment.
Peering establishment
Up to this point we have described the exchange of UDP messages using multicast, but now we need to look at the next phase of LDP communication. Here TCP will be used to establish peering sessions between LDP neighbors. In the demonstration above we clearly observed this process. But we can take a closer look at this fact via the show tcp brief command on each of our peers:
R1#show tcp brief TCB Local Address Foreign Address (state) 498D80D8 192.1.1.1.646 192.1.5.5.21288 ESTAB R5#show tcp brief TCB Local Address Foreign Address (state) 47C08A40 192.1.5.5.21288 192.1.1.1.646 ESTAB
This output clearly demonstrates that we have a TCP peering session that is in the established state. We will use this output to look at the first part of this two-step process we have been describing. We will call this initial phase the transport connection phase, and during this operation one of two actions can transpire.
If the two peers (in this case R1 and R5) have never previously established a TCP session then they will attempt do so immediately. During this process the two devices must decide with of them will be the active device in the relationship. The active device will use a TCP port from the ephemeral (high random) range and is more commonly referred to as the client. Where the server will be the device that will be listening for connections on the well-known TCP port of 646. In this situation the device with the highest ip address will play the role of the client and the lower will be the server. We can see this by again looking at the output of the show tcp brief:
R1#show tcp brief TCB Local Address Foreign Address (state) 498D80D8 192.1.1.1.646 192.1.5.5.21288 ESTAB
We see that R1 is the server in this peering, by virtue of the local TCP port being 646, this again is mandated because of the lower IP address. This begs the question, “what happens when a previous peering exists?” The answer is if the two LSRs already have a TCP session between them, possibly one over another interface, a new TCP session will not be created. The key element to this phase of the process is the creation of the transport connection. Which immediately brings us to the second phase of this process.
Session Establishment
Immediately after the establishment of the transport connection our devices will begin to negotiate session parameters across the newly created session. LDP messages will be used to negotiate a number of variables that extend to the LDP protocol version, the label exchange method, and the operational timer values. Immediately after this negotiation process the LDP TCP peering session will be fully established.
If some element fails in this process, possibly due to incompatible configurations, the routers will exchange special messages called Error Negotiation Messages. These Error messages are then used to signal that the devices should attempt to renegotiate the session. The issue with this particular connection dynamic is the possibility of constantly repeating a series of renegotiation attempts. One tool created to attempt to address this “looping” process of failed negotiations involves the deployment of an exponential initiation and backoff values. By default Cisco IOS will use 15 seconds for the LDP initial backoff value, and 120 seconds for the LDP maximum backoff value.
We can clearly see the values assigned to these timers via the show mpls ldp parameters command.
R1#show mpls ldp parameters Protocol version: 1 Session hold time: 180 sec; keep alive interval: 60 sec Discovery hello: holdtime: 15 sec; interval: 5 sec Discovery targeted hello: holdtime: 90 sec; interval: 10 sec Downstream on Demand max hop count: 255 Downstream on Demand Path Vector Limit: 255 LDP for targeted sessions LDP initial/maximum backoff: 15/120 sec LDP loop detection: off
We have addressed the meaning and purpose of the LDP initial/maximum backoff value but please note there are other timers also specified in this output. These values come into play after the TCP session has been established and are a vital part in the care and maintenance of the operational connection between peers. This brings us to our third and final primary function of LDP.
Regulation of Peer-to-Peer Communication and Label Exchange
We have observed the process used to dynamically discover LDP neighbors. We actually monitored the establishment of the TCP session used to manage the LDP communication process. Now we are going to look critically at the actual process employed by Cisco IOS to maintain LDP sessions. We have seen how the label distribution protocol works to allow neighbor discovery and session establishment, and it should come as no surprise that the maintenance mechanisms built into LDP also work to maintain and verify the LDP process at both of these levels as well. Hello Adjacency messages are used to maintain the neighbor peering states, while LDP session maintenance is accomplished by sending and receiving keep-alive messages between peers to maintain the connection at a session level.
We have looked at the processes involved in LDP and we have mentioned that these process are directly governed at various levels in the protocol architecture by timers. Before we look at the benefits and advantages of manipulating these timers we should take a closer look at what they do and how they do it.
Timers
The timers that we are describing regulate the transmission and anticipated arrival of both discovery messages and keep-alives. Based on these timer values, LDP will isolate a failed session, reset an existing session or bring up a new session. These values allow us to manipulate these processes and criteria from the command line.
As an example LDP relies on the regular arrive of HELLO Adjacency messages to determine a peer’s intent to use a defined label space. The label space in question is identified within the hello. All label switch routers will therefore maintain a hold timer value for each HELLO Adjacency which gets reset as a new HELLO arrives from that given peer. If this timer expires before a new HELLO Adjacency arrives then it is assumed that the peer no longer wants to participate in the session. This means that the peer will not take part in label switching and the existing label space for that peer will be considered invalid and a notification message will be sent to terminate the LDP session. This also will result in the actual TCP session being closed as well.
Timers that affect LDP neighbor discovery include:
(G) mpls ldp discovery hello interval <sec>
- Default every 5 seconds
(G) mpls ldp discovery hello holdtime <sec>
- Default every 15 seconds
We have discussed the timers that work with discovery but now we need to move to the timers that are used to maintain the actual LDP sessions themselves. It must be noted that these timers only come into play once an LDP session has been established. It may be easiest to think of these timers as those that affect session integrity or what is referred to colloquially as session “housekeeping”.
Where HELLO Adjacency messages where used previously, we are now looking at keep-alive messages. These messages are typically sent every 60 seconds by default. The keep-alive timer for each peer session resets whenever it receives any packet on that session. If the keep-alive timer expires, LDP treats that session as if the TCP connection is down.
The timer that affect LDP Session maintenance is:
(G) mpls ldp holdtime <sec>
- Keep-alive time is reset every time LDP packets or keep-alive (60 sec) are received.
- Default is 180 sec
- Keep-alive values are automatically adjusted to 1/3 of the configured holdtime
The command that we will use to determine the assigned values for these timers on a local basis is:
R1#show mpls ldp parameters Protocol version: 1 Session hold time: 180 sec; keep alive interval: 60 sec Discovery hello: holdtime: 15 sec; interval: 5 sec Discovery targeted hello: holdtime: 90 sec; interval: 10 sec Downstream on Demand max hop count: 255 Downstream on Demand Path Vector Limit: 255 LDP for targeted sessions LDP initial/maximum backoff: 15/120 sec LDP loop detection: off
But to see what values have been negotiated during the peering process described in the previous section we will rely on show mpls ldp neighbor detail:
R1#show mpls ldp neighbor detail Peer LDP Ident: 192.1.5.5:0; Local LDP Ident 192.1.1.1:0 TCP connection: 192.1.5.5.21288 - 192.1.1.1.646 Password: not required, none, in use State: Oper; Msgs sent/rcvd: 261/265; Downstream; Last TIB rev sent 6 Up time: 03:45:12; UID: 2; Peer Id 0; LDP discovery sources: FastEthernet0/0; Src IP addr: 172.16.15.5 holdtime: 15000 ms, hello interval: 5000 ms Addresses bound to peer LDP Ident: 172.16.15.5 192.1.5.5 Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab
Be mindful of the fact that the neighbor detail output will provide values in measurements of milliseconds, and if values differ between peers the lowest timer will be selected during this negotiation process. Furthermore, should the need arise to change timers those values affecting keep-alive timers will require a session reset to take effect. We can observe this in output provided below:
R1(config)#mpls ldp holdtime 100 %Previously established sessions may not use the new holdtime. R1(config)#
This entire discussion has brought us to the point where we can now cover the actual exchange and advertisement of labels that is handled via LDP. We will begin by taking a comprehensive look at the standard behavior of LDP, and then at the tools and mechanisms we have at our disposal to manipulate this underlying processes involved.
This section was been taken from the upcoming IPexpert MPLS Operation and Troubleshooting book where the topic is explored in much deeper detail. If MPLS is a topic of concern in your preparation for the CCIE R&S exam you may want to add this valuable reference to your library.
Terry Vinson
CCIE# 35347 (R&S)
Tags: CCIE, ccie exam, CCIE R&S, ccie r&s written, Troubleshooting
Really nice description for LDP.
Thanks.