I85PREP
⌘ K
JNCIP-SP study materials
JNCIP-SP study resources

LDP Session Stuck in Connecting After an IS-IS Level Change

JNCIP-SP · Put your knowledge to work in context.

All case studies

LDP Session Stuck in Connecting After an IS-IS Level Change

PE-1 (lo0 10.255.0.1) and PE-2 (lo0 10.255.0.2) are directly connected over ge-0/0/0/0.0 in 10.0.12.0/30 and both run IS-IS plus LDP. During a maintenance window an engineer set the IS-IS level on PE-2's core-facing interface to level 1 only; PE-1's interface is still level 2 only. LDP discovery still works - show ldp neighbor on PE-1 lists 10.0.12.2 - but show ldp session sits in Connecting indefinitely. show isis adjacency on PE-1 lists nothing for that interface, yet the two routers still ping each other's interface addresses and the link itself is clean (no CRCs, no flaps). Traffic that used to ride the LDP label for 10.255.0.2 now falls back to IP forwarding, cutting throughput on that path. Customer-facing SLAs are unaffected so far, and the NOC wants the fastest safe fix without a full maintenance window.

1. The neighbor is discovered but the session never leaves Connecting. Explain the mechanism and name the commands and fields you would check to prove the cause before touching the configuration.

Read the worked answer

LDP discovery and session setup use different transports, which is why the symptoms look contradictory:

  • Discovery uses UDP 224.0.0.5:646 over the directly connected link and only needs interface addresses, so it succeeds regardless of routing.
  • Session establishment opens TCP 646 to the LDP transport address, which by default is the router ID (the lo0 address). TCP cannot open unless 10.255.0.2 is in inet.0.

Verification sequence:

  1. show ldp neighbor detail - confirm the transport address field shows 10.255.0.2, not 10.0.12.2.
  2. show route 10.255.0.2 - expected result is no route; this is the proof, not the interface ping that succeeds via the connected route.
  3. show isis adjacency and show isis interface ge-0/0/0/0.0 detail - no adjacency because an L1-only interface and an L2-only interface never form an adjacency.
  4. show configuration protocols isis on both PEs to see the level restrictions.

Root cause: the level mismatch kills the adjacency, the lo0 /32 never enters the L2 database, TCP 646 to the transport address fails, and LDP stays in Connecting while the link addresses still ping.

2. Give the two remediation options available, state the risk of each, and say which you would choose and why.

Read the worked answer

Option A - restore a common IS-IS level. Put PE-2's interface back to level 2 (or make both level 1/level 2). The adjacency forms, 10.255.0.2 returns to inet.0, and TCP 646 completes. All FECs come back, including the /32 label that VPN next hops need. Risk: the adjacency and the LDP session re-establish, so label bindings for 10.255.0.2 are withdrawn and re-advertised and traffic re-routes briefly. Mitigate with commit confirmed 5 and a short window.

Option B - change the transport address. set protocols ldp interface ge-0/0/0/0.0 transport-address interface on both PEs makes the session use 10.0.12.x, which is reachable via the connected route. Risks: it must be applied on both ends simultaneously or the session never comes up; changing the transport address tears the session down; and the /32 loopback stops being the LDP FEC, so label bindings for 10.255.0.2 disappear. VPN next hops that resolve over this link would then need RSVP or LDP tunneling, and the config diverges from the rest of the network.

Choose A. Option B trades a five-minute reconvergence for a permanent design inconsistency and a possible VPN blackhole.

3. After the change, how do you prove LDP is actually usable for VPN next-hop resolution and not just 'up'?

Read the worked answer

Session state alone is not sufficient - an Operational session with no label for the loopback still cannot resolve a VPN next hop.

  1. show ldp session detail - state must read Operational and the transport address must be the loopback you expect.
  2. show route table inet.3 10.255.0.2 - must show an LDP entry with a label (for example >to 10.0.12.2 via ge-0/0/0/0.0, label 299776). If the route exists with no label, resolution is still broken.
  3. show route table mpls.0 | match 299776 - confirm the label is programmed in the forwarding table, not only in the routing table.
  4. show route table <vrf>.inet.0 <prefix> extensive - the protocol next hop should now be resolvable and the route should show as active, not hidden with reason Nexthop Unusable.
  5. ping mpls ldp 10.255.0.2/32 - an end-to-end check that the LSP for the /32 is usable.

Finally watch show ldp session for a few minutes: a session that bounces after the fix usually indicates a remaining transport-address or MTU problem rather than a solved one.