Theoretical foundations and architecture
Laboratory session: eliminating MPLS blackholing via LDP-IGP Synchronization and prefix label filtering. When a failed core link recovers, OSPF/IS-IS brings the adjacency up quickly and directs traffic onto the newly restored link. However, LDP requires several seconds to establish TCP handshakes and synchronize Label Mappings. During this window, labeled packets traversing the link encounter missing bindings and are dropped (the classic MPLS black hole). LDP-IGP Synchronization resolves this: as long as the link LDP session is non-operational, the IGP advertises the link with maximum metric (Cisco OSPF: 65535; IS-IS and other platforms use other values). Traffic remains safely on the alternate path until LDP synchronization completes, after which OSPF restores normal operational metric. The lab also configures outbound label filtering to suppress unnecessary bindings for /30 transit links.
The problem: the IGP is faster than LDP
After a link is restored, OSPF or IS-IS brings up the adjacency and recomputes SPF within tens of milliseconds, while LDP has to go through discovery again, open a TCP session (a three-segment handshake, then Initialization and KeepAlive) and exchange Label Mapping for all FECs: in practice from fractions of a second to tens of seconds. During that time the IGP already considers the link best and sends traffic over it. There are no labels for the FECs on that link yet, so on the transit node packets carrying a VPN label are lost: an LDP black hole. Parallel plain IP traffic may pass (the LFIB gives No Label and the packet leaves as IP), but L3VPN, pseudowires and everything that depends on the transport LSP disappear until the labels are installed.
The solution: LDP-IGP synchronization (RFC 5443)
As long as the interface has no "ready" LDP, the IGP advertises the link with the maximum metric. Traffic stays on the backup path, and the link itself remains a "last resort": if there is no backup path, the IGP will still use it. When LDP on this link is ready (the session is Operational and the binding exchange has started), the metric returns to normal and SPF moves traffic over smoothly. Cisco advertises the maximum metric 65535 in OSPF; the exact value depends on the platform and protocol.
States on Cisco (show mpls ldp igp sync): LDP is not configured or IGP sync is disabled on the interface; LDP is configured and waiting for the session; sync achieved (the metric is normal); sync not achieved (the metric is maximum). Two timers control the behavior: holddown - the maximum time to wait while the session is not up, after which the IGP restores the normal metric anyway (by default on Cisco the limit is off: wait forever), and delay - a short pause after the session comes up so that the bindings reach the LFIB (IOS-XE: mpls ldp igp sync delay). It is configured in the IGP process (mpls ldp sync under router ospf), while exceptions are made on the interface (no mpls ldp igp sync).
One-sided enablement does not work
A link metric is a per-direction property. If sync is enabled on PE1 and disabled on P1, then after the restore PE1 advertises the maximum metric while P1 immediately advertises the normal one: traffic from P1 to PE1 goes over the restored link where PE1 has not yet issued labels. Sync must be enabled on both ends of every link, and both ends must be checked in show mpls ldp igp sync.
When sync hurts: LDP never comes up
If for some reason LDP does not come up on a given link (MD5, an ACL on TCP 646, MTU), the link stays at the maximum metric forever and traffic moves to the backup route: this is a good failure mode (traffic is not lost), but sync status monitoring is mandatory, otherwise the degradation goes unnoticed. Holddown limits this state but brings the losses back, so it must be chosen deliberately. On Junos the equivalent is ldp-synchronization on the interface in the IGP block with the hold-time parameter; on Huawei it is ldp-sync in OSPF and hold-down timers on the interface.
LDP session protection
When the only direct link fails, the adjacency and session disappear, and with them all the neighbor's bindings: after the link returns, all labels must be learned again. Session protection keeps a parallel targeted adjacency to the neighbor over any available path: the session survives the loss of the direct link, the bindings stay in the LIB, and when the link returns the labels are already in place and sync completes almost instantly. On Cisco: mpls ldp session protection [for ACL] [duration seconds], on Junos session-protection with an optional timeout. The price is an additional targeted adjacency and state for every protected neighbor.
Label filtering in the core
Labels are needed only for addresses used as BGP next hops (PE loopbacks and the RR if necessary); labels for link /30 subnets and especially for customer prefixes are useless and increase the LFIB and the attack surface. In practice: restrict allocation (Cisco allocate global host-routes or a prefix-list) or distribution (Junos export with route-filter .../16 prefix-length-range /32-/32, MikroTik advertise-filter). Working rule: every address that a VPN route next hop points to must stay in the list. Control test: remove PE2 from the list and make sure the LSP to PE2 disappears, then restore it.
Order of the lab
- Basic connectivity: IGP, LDP, labels for all FECs; record a ping to 10.255.0.2 from the PE1 loopback. 2) Enable sync on both ends of the primary and backup links. 3) Enable session protection. 4) Start a continuous ping 10.255.0.2 source Loopback0 at 5 per second, shut the primary link, wait until traffic runs over the backup. 5) Bring the link up and observe: IGP adjacency up, sync not achieved, LDP Oper, sync achieved, the metric is back; compare the number of lost packets with a run without sync. 6) As a separate change enable label filtering and check that all PE FECs remain.
What to check first
show mpls ldp igp sync on both ends of the link, show ip ospf mpls ldp interface (sync state on the OSPF interface), show mpls ldp neighbor (which adjacencies and targeted ones), show mpls forwarding-table 10.255.0.2 before and after, show ip route 10.255.0.2 (cost 20 over the primary, 60 over the backup link).
Architecture Diagram & Topology
+-----------+ [Primary Link: Restored / Metric 65535] +-----------+
| PE-1 | ====================================================> | P-1 |
| | ---------------- [Backup Link: Metric 50] ----------> | |
+-----------+ +-----------+Traffic Flow & Label Stack Scheme
LDP-IGP Synchronization Sequence (RFC 5443):
1. Primary physical link restores; the IGP adjacency comes up.
2. The IGP advertises the link with maximum metric (Cisco OSPF: 65535; IS-IS and other platforms use their own maximum).
3. Transit traffic stays on the backup path (metric 50) while LDP is not Operational on that link.
4. LDP discovers the neighbor, opens the TCP session and exchanges label bindings.
5. The IGP restores the configured metric (10) and SPF moves traffic back to the primary link.
A hold-down timer, if configured, bounds the wait when LDP never comes up.