MPLS LDP-IGP Synchronization Configuration - 夜莺博客

MPLS LDP-IGP Synchronization Configuration

There is a short but painful window in every MPLS network where the IGP has converged, traffic is being forwarded, and the label bindings for the new link are not yet exchanged. Packets arrive at a router with no outgoing label for the next hop and are dropped. LDP-IGP synchronization closes that window by making the IGP hold back the adjacency until LDP is ready. This article covers the configuration, the two timer knobs that decide how long the wait lasts, and the verification that proves synchronization reached its goal.

The race condition in one paragraph

OSPF or IS-IS converges in tens of milliseconds after a link comes up. LDP needs a TCP session, a label exchange and a distribution of bindings — typically a second or more. In the gap, the IGP installs the link in the forwarding table, the data plane points traffic at it, and the control plane is not ready. Synchronization inverts the order: the IGP does not advertise the link until LDP says it is operational.

Configuring it on Cisco IOS and IOS XE

! enable LDP on the interface
interface GigabitEthernet0/0/0
 mpls ip
 mpls ldp igp sync          ! IOS: enable sync on this interface
!
! IOS XE: enable synchronisation for the IGP process
router ospf 1
 mpls ldp sync
!
! how long the IGP may wait for LDP before advertising anyway
mpls ldp igp sync holddown 60
!
! per-interface delay before the IGP considers the link ready
interface GigabitEthernet0/0/0
 mpls ldp igp sync delay 30

By default, if the LDP peer is reachable, the IGP waits indefinitely for synchronization. The holddown timer is the escape hatch: after the timeout expires the IGP establishes the adjacency anyway, on the assumption that forwarding without labels is better than not forwarding at all. If the LDP peer is simply unreachable, the IGP does not wait for the full holddown — it proceeds once it knows LDP will not come up.

Exempting individual interfaces

interface GigabitEthernet0/0/1
 no mpls ldp igp sync

There are legitimate cases for exemption: a link where the peer runs a different label distribution method, or a stub interface that carries no labelled traffic. Exempt deliberately and document it — an exempted core link is a silent drop zone during convergence.

Verifying that synchronization actually completed

show mpls ldp igp sync
! GigabitEthernet0/0/0: LDP configured; SYNC enabled.
!  SYNC status: sync achieved; peer reachable.
!  IGP holddown time: infinite.
!  Peer LDP Ident: 10.0.0.1:0
!  IGP enabled: OSPF 1

show ip ospf mpls ldp interface
! GigabitEthernet0/0/0 Process ID 1, Area 0
!  LDP is configured through LDP autoconfig
!  LDP-IGP Synchronization: Yes
!  Holddown timer is not configured
!  Timer is not running

Read the status line literally. sync achieved; peer reachable is the healthy state. sync not achieved with a timer running means the IGP is deliberately withholding the link — traffic is being forwarded by another path, and if there is no other path, you have an outage that the holddown timer is about to resolve the hard way.

Positive confirmation from the IGP side is more useful than the sync status alone:

show ip ospf interface GigabitEthernet0/0/0 | include LDP
!  LDP is configured through LDP autoconfig
!  LDP-IGP Synchronization: Yes
show mpls ldp discovery
show mpls ldp neighbor | include Peer LDP Ident|State

Failure modes worth knowing

  • Synchronization never completes on one link while its neighbours are fine — LDP transport address unreachable. LDP forms its TCP session to a loopback-derived router ID by default; if that address is not reachable over the link, sync will not achieve. Check show mpls ldp discovery detail.
  • Link flaps cause a longer-than-expected outage — a holddown longer than your convergence budget. Size it against the time the worst LDP session needs to re-establish, typically 10–60 seconds on a loaded router.
  • Sync achieved but traffic still drops — the problem is not synchronization; check the label stack with show mpls forwarding-table and verify the MPLS MTU across the path.
  • Holddown timers that differ per interface — they are fine, but a single long holddown on a critical link is a configuration time bomb during an LDP process restart.

Configuration sanity check before you change anything

show run | section mpls ldp
show mpls ldp igp sync | include SYNC status
show ip ospf interface | include LDP-IGP Synchronization

For the label distribution side of the same platform, see MPLS LDP configuration guide; for verifying the resulting data plane once labels are exchanged, MPLS LSP ping and traceroute is the tool that proves the forwarding path rather than the control plane.

原文链接:https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/mpls/b-mpls/m_mp-ldp-igp-synch.html