Understanding LDP-IGP Synchronization

LDP is often used to establish MPLS label-switched paths (LSPs) throughout a complete network domain using an IGP such as OSPF or IS-IS. In such a network, all links in the domain have IGP adjacencies as well as LDP adjacencies. LDP establishes the LSPs on the shortest path to a destination as determined by IP forwarding.

If the IGP and LDP are not synchronized, packet loss can occur. This issue is especially significant for applications such as a core network that does not employ BGP. Another example is an MPLS VPN where each provider edge (PE) router depends on the availability of a complete MPLS forwarding path to the other PE devices for each VPN that it serves. This means that along the shortest path between the PE routers, each link must have an operational hello adjacency and an operational LDP session, and MPLS label bindings must have been exchanged over each session.

LDP establishes MPLS LSPs along the shortest path to the destination as determined by IP forwarding. In a Layer 2 VPN or Layer 3 VPN scenario, if the LSP is not yet formed between the PE devices, services depending on MPLS forwarding fail. When LDP has not completed exchanging label bindings with an IGP next hop, traffic is discarded if the head end of the LSP forwards traffic because the LSP is assumed to be in place.

There are various reasons that the LSP fails to come up, as follows:

• Configuration errors and implementation issues.

• When an LDP hello adjacency or an LDP session with a peer is lost due to some error while the IGP still points to that peer. IP forwarding of traffic continues on the IGP link associated with the LDP peer rather than being shifted to another IGP link with which LDP is synchronized.

• When a new IGP link comes up, causing the next hop to a certain destination to change in the IGP’s shortest-path-first (SPF) calculations. Although the IGP might be up on the new link, LDP might not have completed label exchange for all the routes. This condition might be transient or due to a misconfiguration.

LDP-IGP synchronization discourages a link from being used while the LDP sessions are not fully established. When LDP is not fully operational on a link, the IGP advertises a maximum cost for the link, thus preventing traffic from flowing through it. The IGP does not advertise the original cost or metric for the link until either LDP label exchange has been completed with the peer on the link or a configured amount of time has passed (the holddown period). By default, LDP waits for 10 seconds after establishment of LDP session on the link before notifying IGPs to ensure label exchange has been completed. This is configurable using the igp-synchronization holdown-interval statement at the [edit protocols ldp] hierarchy level.

When synchronization is configured, LDP notifies the IGP to advertise the maximum cost for the link when one of the following triggering events takes place:

• The LDP hello adjacency goes down.

• The LDP session goes down.

• LDP is not configured on an interface.

If the holdown timer has been configured, the timer starts when the triggering event takes place. When the timer expires, LDP notifies the IGP to resume advertising the original cost.

If the holddown timer has not been configured, the IGP waits (endlessly) until LDP sessions are up and igp-snychronization holdown-interval has passed to ensure label exchanges have completed. Only after that takes place does LDP notify the IGP to bring down the cost on the interface.

LDP-IGP synchronization is supported only for directly connected peers and links with the platform label space.