MPLS LDP IGP Synchronization

Routing & Switching MPLS
1

Hello, everyone.

I didn’t find a lesson for this so I am creating a new topic if you don’t mind

I’ll do my best to keep this brief.

Cisco and some resources state this regarding IGP synchronization with LDP:

IGPs do not form an adjacency across a link if the LDP session is not established first across that link. (OSPF does not send out Hellos on the link.)

This part is only true under two circumstances. First of all, if we already have an IGP session and the LDP session goes down, the adjacency does not go down, it remains up with max-metric

Cisco:
When an IGP adjacency is established on a link but LDP IGP synchronization is not yet achieved or is lost, the IGP advertises the max-metric on that link.

Second of all, if we don’t have an IGP adjacency yet and are waiting for LDP to come up, if the local router realizes that it has no route for the peer’s transport address, it will bring the IGP adjacency up regardless in the hope that it will provide it with a route.

If the LDP peer is not reachable, the IGP will then establish the adjacency regardless of LDP session state after the timeout has occurred.

(it will of course increase the metric on this path to prevent it from being used until LDP syncs).

The highlighted part above makes sense. If we have just a single connection to our LDP peer, we won’t learn about any routes regarding this peer until the IGP adjacency comes up. Without this, we would never establish the adjacency and never learn any routes at all.

My question is about the holddown timer. In the common cases I’ve mentioned above, the IGP adjacency establishes and we learn routes which is great. However, at what point could we end up stuck with no adjacency at all, only to rely on the holddown timer to fix this issue?

I can only think of one possible scenario.

  1. If the LDP peer is reachable, the IGP won’t build the adjacency unless LDP synchronizes. This is the opposite behavior of when the LDP peer is unreachable. If the LDP session here doesn’t establish due to some kind of problem, the IGP adjacency will never come up. So after the holddown timer expires, the IGP adjacency comes up (although the link is still advertised as max metric to prevent blackholes)

If the LDP peer is unreachable, the IGP brings the adjacency up which makes sense so I don’t see much use for it here.

Thank you.
David

2

Hello David

Thanks for the detailed information in setting up your question, it was useful.

Yes, the holddown timer is genuinely necessary. The key reason is this: by default, if LDP’s reachability check succeeds (the peer’s transport address is found in the routing table), the IGP will wait indefinitely for LDP synchronization to complete before bringing up the adjacency at all. Without a configured holddown value, there is no upper bound on how long the adjacency stays withheld.

The scenario you’re describing with the phrase: “stuck with no adjacency until the holddown fires” happens exactly when LDP considers the peer reachable, but the actual LDP session negotiation never completes, even though both routers can route to each other. There are various scenarios that can cause this including LDP authentication (MD5) mismatch between peers, an ACL or firewall blocking TCP/646 while the transport address is still routable, as well as others.

In these cases, the link is IP-reachable but MPLS forwarding is broken. Without the holddown timer, that link’s IGP adjacency would never form on IOS or IOS-XE (see below for details), converting a “suboptimal” situation into a complete neighbor-loss, potentially partitioning your IGP domain if that’s the only path. So the holddown timer acts as a safety net against indefinite convergence loss when LDP gets stuck but the peer isn’t truly unreachable.

Based on RFCs 5443 and 5919, the holddown timer is actually not part of the process. I won’t go into details of why here, you can look at the RFCs in detail for that. However, most operators still configure a holddown as a safety net.

Note that Cisco IOS-XR behaves in strict accordance with the RFCs: it allows the adjacency to form immediately but advertises the link with max-metric until LDP syncs, so it doesn’t have this problem and doesn’t offer an MPLS LDP sync holddown timer. The “stuck without adjacency” issue is specific to classic IOS/IOS-XE because of the way it functions.

In practice, it is advisable to configure a reasonable holddown (e.g., mpls ldp igp sync holddown 30000) on your LDP-synced interfaces to bound the convergence impact if LDP ever gets stuck.

I hope this has been helpful!

Laz

1 Like