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:

  1. To auto discover the peers that want to use label switching on this link.
  2. 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.


No related posts.


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

AddThis Social Bookmark Button

13 Responses to “LDP neighbor discovery, session establishment and maintenance”

  1. Very useful – thanks. There is one basic point I can’t ever understand. Why is it said that label distribution is opposite to data flow? For example, in downstream on demand, the egress router becomes the laber manager/controller. Unlike in RSVP-TE, the headend router know all routes and initiates all TE.

    An LDP session is supposed to be bi-direction, hence my confusion. Any explanation as to the reason for the opposite flow for dala and label would be most appreciated.

    P.S.
    You wrote,
    “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.”

    If you could continue with label distribution, that would be great. Write a book! you guys explain well. I think “targetted” books would be well received in the marketplace, e.g. LDP Operation, RSVP & TE ook, etc.

  2. Hi,

    First of all thank you very much, actually writing a large scale networks design book is one of my life time goals, let’s see :)

    Regarding the label distribution being opposite to the data flow, this is a typical networking behavior, the control plane always correlates to the data plane in an opposite direction, to explain this with a simple approach, imagine two routers having a dynamic routing protocol between each others, R2 has a certain subnet connected to it and thus it advertises this subnet to R1 (this is the control plane – the job of the routing protocol), and thus when R1 needs to forward packets to this subnet (the destination) it uses R2 as the next-hop (this is the forwarding/data plane – done according to the information learned from the control plane), this is the typical behavior of any control and forwarding plane, let it be a routing protocol or a label distribution protocol (LDP or RSVP – Actually RSVP follows the same logic, yes the head-end initiates the LSP via the PATH message, but the labels are signaled in an opposite direction from the tail-end to the head-end via the RESV message – again egress to ingress).

    I promise that we are going to try to cover most of the interesting topics, we might start doing this via a requesting system, we’ll see.

    I am glade that you are enjoying our posts, and I hope that we are informative.

    BR,
    Mohammed Mahmoud.

  3. Hi Mahmoud,

    Another excellent explanation. Many thanks!!! Really appreciate you taking the time to contrast LDP and RSVP in explaining this.

    It’s one of those things where the basics bug you. Take FEC as an example. I think if you ask 10 different people (who knows MPLS) what FEC means, you will get 10 different answers :-)

    Thanks again.

  4. Hi Mac,

    Thank you very much, you are very welcomed, I am glade that I was informative.

    I agree with you regarding the basics issue, and I believe that you’ll have 10 correct answers ;) right and wrong are very relative, I enjoy understanding things from different prospectives, for example if we were talking about a protocol, I do care about the facts from the standards point of view, from the vendors point of view, from the end-user point of view and from any other point of view I can find out, in this way I can build my understanding.

    Please do take care, enjoy and have a nice day.

    BR,
    Mohammed Mahmoud.

  5. This is a very clear discussion of LDP discovery, thank you.

    I have a related question concerning order of LDP Discovery Sources. Sometimes a link will show the “hard” (Interface when there is an LDP Adjacency) as the first Discovery and the “soft” (Targeted Hello) and sometimes they are reversed. My team was interested in why this is AND how we can change the order. We have been able to consistently make the “hard” second in the list by toggling the interface, but we have not been able to consistently move the “hard” discovery to the “top”. The most consistent method has been rebooting the router which a very disruptive method for a less than 75% probability of success.

  6. thanks , very nice post :)

  7. [...] LDP neighbor discovery, session establishment and maintenance. [...]

  8. Oscar Jimenez Says:

    hi guys

    under which condition could the LDP session fall down if there is not failures on the hello adjacencies?

  9. Ankit Jain Says:

    Guys its really helpful information….

    Apart from this info i have a doubt regarding BGP establishment…can anybody please help?

    How can we differentiate that Established BGP session is IBGP, EBGP or MBGP…..on which BGP message type or during establisment process (FSM) we can differnetiate whether its IBGP, EBGP or MBGP.

  10. Wael Osama Says:

    @ Ankit,

    If I get your question right, the answer is the open message. The open message contains a field for My AS number which is used to identify if this is going to be an iBGP or eBGP. MPBGP is a different story because iBGP and eBGP can be MPBGP this depends on AFI/SAFI negotiations.

    Let me know if you need more information….

  11. hi guys

    under which condition could the LDP session fall down if there is not failures on the hello adjacencies?

  12. very nice explanation from Mohammed Mahmoud pls keep posting like this

  13. Dear Team,

    I’m facing strange issue on our network, where we are able to create IGP neighbour ship via OSPF,but on the same link LDP session is not forming…

    what can be the reason…thx in advance for solutions

Leave a Reply