LDP neighbor discovery, session establishment and maintenance
Team working is all about producing results with a group of people you love working with … Being part of the same team, working together all day long we decided to extend this level of team working from being members of the same team and writing in the same blog to even write this post together.
In this post we are transferring our daily team work interaction from our office to the blog. The case was simply manipulating the LDP timers at a node suffering from connectivity issues. To be able to master this arena you need to perfectly understand the underlying mechanisms, accordingly in this post we will try to effectively describe the mechanisms behind LDP discovery, session establishment and maintenance.
LDP neighbor discovery, session establishment and maintenance as described in RFC 3036 is accomplished in many phases, in the following section we are going to describe the neighbor discovery and session establishment, and in the second section we are going to describe maintaining the Hello adjacency and the LDP session.
LDP neighbor discovery and session establishment
First the neighbors discover each other as LDP neighbors via one of two methods (this circumvents the need for manually configuring LDP neighbors):
- Basic Discovery Mechanism - Using multicast UDP hellos in the case of direct connected neighbors.
- Extended Discovery Mechanism - Using targeted UDP hellos in the case of non-directly connected neighbors.
NOTE In both cases the traffic is destined to the LDP well-known port number 646.
The exchange of LDP Discovery Hellos between two LSRs triggers LDP session establishment, which is a two step process:
Transport connection establishment (The TCP session using the well know port number 646 - Client-Server TCP operation).
During this process we have two probabilities:
- If the two LSRs already had a TCP session between each other (an already established LDP session over another interface), thus it won't create a new TCP session.
- If the two LSRs had no established TCP session between each other, thus they attempt to open a new TCP connection, and they decide which of them takes the active (acting as the TCP session client using a random source port) and which takes the passive role (acting as the TCP session server listening on the well-known LDP port 646) by comparing the transport address (exchanged in the discovery hellos), and the LSR with the higher address plays the active role and the other plays the passive role.
Session initialization
After the LSRs establish a transport connection they negotiate the session parameters by exchanging LDP Initialization messages, the parameters negotiated include LDP protocol version, label distribution method, timer values, etc. After the negotiation is successful the LDP session is successfully established.
If the negotiation was not successful (most probably due to incompatible configuration) Error Notification messages are exchanged, and the LSRs retries the session initialization, but since this can result in an endless loop of negotiation, thus an exponential backoff throttling procedure should take effect, Cisco IOS for example is using an exponential backoff with default LDP initial/maximum backoff values of 15/120 sec, and these values are tunable.
After the session is established, now the LSRs can proceed in label distribution. But still there resides a need to maintain the session, which is done on two levels; the maintenance of the Hello Adjacencies (on the discovery level) and the maintenance of the LDP session (on the session level), both are discussed in the following section.
Hello adjacency and LDP session maintenance
Two LDP peers can have one or more Hello adjacency sessions over multiple links directly connecting between them. Hello messages are used to discover LDP neighbors on each link.
After discovering any LDP neighbor using multicast UDP hello messages, a TCP session must be established for LDP to exchange labels over a reliable connection.
The maintenance of the LDP operation is done on two levels; the hello adjacency level and LDP session level. Both of them are described below
Maintaining Hello adjacencies
Its frequent in MPLS networks to see two LSRs connected by multiple links and running label switching over all the links. In this case LDP hello messages are sent on all links with the same LDP identifier. These Hello messages serve two purposes:
- To auto discover the peers that want to use label switching on this link.
- To detect peers failures and problems on this link.
If the discovery hold down timer expires without receiving hello messages from the neighbor on one of the links the LSR concludes that the peer no longer wants to run label switching over this link.
When the last hello adjacency (last LDP enabled link between the peers) is deleted (hold down timer expired) the LDP session is terminated by sending a notification message and closing the transport connection.
The expiration of the discovery hold time results in neighbor going down with the following error message:
*Jan 18 21:49:58.244: %LDP-5-NBRCHG: LDP Neighbor x.x.x.x:0 (1) is DOWN (Discovery Hello Hold Timer expired)
Maintaining LDP session
After neighbor discovery, LDP transport session establishment takes place using TCP. LDP maintains this session by sending/receiving keepalive messages and using a hold down timer. Every time an LDP message is received over the session the timer is reset. If the hold down timer expired without receiving LDP messages or keepalives from the peer the transport session is terminated.
The expiration of the session hold time results in the neighbor going down with the following error message:
*Jan 18 21:51:50.844: %LDP-5-NBRCHG: LDP Neighbor x.x.x.x:0 (1) is DOWN (Session KeepAlive Timer expired)
Timers manipulation
Before getting to configuration We need to define the default timers for both discovery and transport sessions.
Transport session: Keepalive: 60 seconds Hold time: 180 seconds Discovery: Hello Interval : 5 seconds Hold time: 15 seconds Discovery Targeted: Hello Interval: 10 seconds Hold time: 90 seconds
LSRs will negotiate the hold time and select the lower timer to use, which means changing the timer should be done on both peers to take effect.
The command show mpls ldp parameters can be used to review the locally configured timers and the command show mpls ldp neighbor details can be used to show the final negotiated timers as shown in the example below:
Router#sh 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 !--- output omitted------
Manipulating Discovery timers
Changing these timers will take effect without the need for resetting the active sessions.
Router(config)#mpls ldp discovery hello interval 20
Router(config)#mpls ldp discovery hello holdtime 60
!-- confirmation---
Router(config)#do sh mpls ldp param
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 60 sec; interval: 20 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Router#show mpls ldp neighbor details
Peer LDP Ident: 100.100.253.9:0; Local LDP Ident 100.100.253.1:0
TCP connection: 100.100.253.9.11057 - 100.100.253.1.646
Password: not required, none, in use
State: Oper; Msgs sent/rcvd: 18/20; Downstream; Last TIB rev sent 14
Up time: 00:08:22; UID: 1; Peer Id 0;
LDP discovery sources:
Serial1/1; Src IP addr: 100.100.19.2
holdtime: 60000 ms, hello interval: 20000 ms
Addresses bound to peer LDP Ident:
100.100.19.2 100.100.253.9 100.100.29.2
Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab
Manipulating the session timers
Keepalive messages interval is calculated automatically by dividing the hold time by 3 without manual configuration. Changing this timer will not take effect for an active session unless the session re-established.
Router(config)#mpls ldp holdtime 400
%Previously established sessions may not use the new holdtime.
Router(config)#do sh mpls ldp param
Protocol version: 1
Session hold time: 400 sec; keep alive interval: 133 sec
Discovery hello: holdtime: 60 sec; interval: 30 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Router#show mpls ldp neighbor detail
Peer LDP Ident: 100.100.253.9:0; Local LDP Ident 100.100.253.1:0
TCP connection: 100.100.253.9.34124 - 100.100.253.1.646
Password: not required, none, in use
State: Oper; Msgs sent/rcvd: 9/10; Downstream; Last TIB rev sent 14
Up time: 00:00:04; UID: 3; Peer Id 0;
LDP discovery sources:
Serial1/1; Src IP addr: 100.100.19.2
holdtime: 60000 ms, hello interval: 20000 ms
Addresses bound to peer LDP Ident:
100.100.19.2 100.100.253.9 100.100.29.2
Peer holdtime: 400000 ms; KA interval: 133333 ms; Peer state: estab
We hope that we have been informative.
Mounir, Wael and Mohammed.
Check Also
