Troubleshooting MPLS: LDP Neighbors, Label Bindings, and Broken LSPs

MPLS has a signature failure mode, and once you have seen it you never forget it: every IP test passes, the IGP is fully converged, you can ping every loopback in the core, and the customer's traffic is going nowhere. The reason is that MPLS forwarding does not run on IP reachability. It runs on labels, and labels come from LDP. Break LDP and the control plane looks perfect while the data plane is dead.

This article is a structured way to troubleshoot the label plane: LDP neighbors, label bindings, and the LSPs they build. Every capture comes from a live five-router IOS XE lab where LDP was deliberately broken on one core link. For MPLS L3VPN-specific route problems, see the companion piece Troubleshooting MPLS L3VPN: where VPN routes go missing, and the MPLS cluster guide for the whole series.

Troubleshoot in Layers, Bottom Up

MPLS is a stack, and each layer depends entirely on the one below. Do not start in the middle:

Layer 2 being healthy tells you nothing about layer 4. That is the entire trap. Work up the stack and stop at the first layer that is wrong.

What Healthy Looks Like

You need a reference before you can spot a deviation. On PE1 in the lab, the LDP session to the P router:

PE1#show mpls ldp neighbor
    Peer LDP Ident: 10.255.0.3:0; Local LDP Ident 10.255.0.1:0
	TCP connection: 10.255.0.3.60695 - 10.255.0.1.646
	State: Oper; Msgs sent/rcvd: 8/8; Downstream
	Up time: 00:00:34
	LDP discovery sources:
	  Ethernet0/1, Src IP addr: 10.30.30.2
        Addresses bound to peer LDP Ident:
          10.255.0.3      10.30.30.2      10.30.31.1

Four things to read every time:

• State: Oper. Anything else and no labels are being exchanged. There is no partial credit.
• The LDP identifiers (10.255.0.3:0, 10.255.0.1:0). These should be loopbacks. If you see a physical interface address here, someone forgot mpls ldp router-id Loopback0 force and the session will reset the next time that interface flaps.
• TCP connection on port 646. LDP sessions are TCP; discovery is UDP 646 multicast. If discovery works but the session never establishes, look for an ACL blocking TCP 646, or for the router-id being an address the peer cannot reach.
• Addresses bound to peer. The peer's full interface list. Useful for confirming you are talking to the router you think you are.

And show mpls interfaces, which tells you whether MPLS is actually on:

PE1#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
Ethernet0/1            Yes (ldp)     No       No  No     Yes

One line, and only the core-facing interface. Ethernet0/0 (the PE-CE link) is correctly absent: the customer does not speak MPLS. If you see a CE-facing interface in this output, someone put mpls ip where it does not belong.

Reading Label Bindings

The Label Information Base (LIB) is every label your router knows about for a prefix: the one it allocated locally, plus the ones its neighbors advertised. This is the raw material the forwarding table is built from.

P#show mpls ldp bindings 10.255.0.2 32
  lib entry: 10.255.0.2/32, rev 10
	local binding:  label: 17
	remote binding: lsr: 10.255.0.2:0, label: imp-null
	remote binding: lsr: 10.255.0.1:0, label: 18

Read it as a conversation. The P router says "for PE2's loopback, I will accept traffic on label 17." PE2 itself says "I am the owner of this prefix, send it to me with imp-null (implicit null), meaning pop the label before you send it." PE1 says "I use 18 for that prefix."

imp-null is what drives penultimate hop popping. Because PE2 advertised it, P knows to pop the transport label instead of swapping it. You can see the result:

P#show mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         Pop Label  10.255.0.1/32    4146          Et0/0      10.30.30.1
17         Pop Label  10.255.0.2/32    3665          Et0/1      10.30.31.2

The forwarding table (the LFIB) is the subset of the LIB that is actually in use: for each prefix, the label advertised by the neighbor that the IGP says is the best next hop. Labels the LIB holds from other neighbors sit there unused until the IGP changes its mind, which is why MPLS reconverges as fast as the IGP does.

The label format itself, including what "Pop Label" is doing to the stack, is covered in MPLS Labels Explained. LDP's discovery and advertisement modes are in LDP and MPLS label distribution.

The Classic: LDP Down, IGP Up

Now break it. On the P router, one core-facing interface loses its MPLS configuration. The link stays up. The IP address stays. Only mpls ip is removed:

P(config)# interface Ethernet0/0
P(config-if)#  no mpls ip

Here is what a network engineer sees on PE1 when the customer calls. Start with the tests that people instinctively run first:

PE1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.0.3        1   FULL/DR         00:00:31    10.30.30.2      Ethernet0/1

PE1#ping 10.255.0.2 source Loopback0
Sending 5, 100-byte ICMP Echos to 10.255.0.2, timeout is 2 seconds:
Packet sent with a source address of 10.255.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/4 ms

PE1#show ip bgp vpnv4 all summary
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.20.1.2       4        65001      10      19       53    0    0 00:05:23        2
10.255.0.2      4        65000      34      23       53    0    0 00:11:26        3

OSPF adjacency FULL. Loopback-to-loopback ping across the core: 100 percent success. The MP-BGP VPNv4 session is up, established for eleven minutes, and has received three prefixes. Every green light you would normally check is green.

And yet:

PE1#ping vrf CUST-A 10.20.20.1 source Ethernet0/0
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
Packet sent with a source address of 10.20.1.1
.....
Success rate is 0 percent (0/5)

Total blackhole. Here is the layer everyone skips:

PE1#show mpls ldp neighbor
PE1#

Empty. No LDP session at all. And that has one consequence that explains everything:

PE1#show mpls forwarding-table 10.255.0.2
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
18         No Label   10.255.0.2/32    0             Et0/1      10.30.30.2

PE1#show ip cef vrf CUST-A 10.20.20.0
10.20.20.0/24
  nexthop 10.30.30.2 Ethernet0/1 unusable: no label

unusable: no label. That string is the whole diagnosis. PE1 knows the route. It knows the BGP next hop is 10.255.0.2. It can ping 10.255.0.2 all day. But an L3VPN packet needs a two-label stack (transport label to reach PE2, VPN label to identify the customer), and PE1 has no transport label for PE2's loopback, because the LDP session that would have supplied it is gone. CEF refuses to forward a packet it cannot label, so it drops it.

Note also that show mpls forwarding-table did not go blank. The entry is still there, with the outgoing label replaced by No Label. If you skim that output looking for a missing line, you will miss it. Read the Outgoing Label column.

Why the VPN dies but plain IP does not

This confuses people, so it is worth stating explicitly. Ordinary IP traffic across the core does not need a label; if the IGP has a route, the packet forwards. But a VPN packet must be labelled, because that is how PE2 knows which customer it belongs to. There is no unlabelled fallback. MPLS Flags: MPLS Required, as the routing table puts it:

PE1#show ip route vrf CUST-A 10.20.20.0 255.255.255.0
Routing entry for 10.20.20.0/24
  Known via "bgp 65000", distance 200, metric 0, type internal
  * 10.255.0.2 (default), from 10.255.0.2
      MPLS label: 22
      MPLS Flags: MPLS Required

So: IP works, VPN does not. Every time you see that combination, go straight to LDP.

The fix, in this case, is one line:

P(config)# interface Ethernet0/0
P(config-if)#  mpls ip

The LDP Failure Checklist

When show mpls ldp neighbor is empty or the session will not reach Oper, the cause is almost always one of these:

When the Session Is Up but the LSP Is Broken

A subtler class of failure: LDP is Oper on every link, but traffic still fails somewhere in the middle. The tools:

Labelled traceroute is the fastest way to see where the stack falls apart. Healthy, from CE1 across the VPN:

CE1#traceroute 10.20.20.1 source Ethernet0/0
  1 10.20.1.1 2 msec
  2 10.30.30.2 [MPLS: Labels 17/22 Exp 0] 5 msec
  3 10.20.2.1 [MPLS: Label 22 Exp 0] 5 msec
  4 10.20.2.2 6 msec

Hop 2 carries two labels (transport 17, VPN 22). Hop 3 carries one, because the P router popped the transport label (PHP). If a hop that should be labelled shows no label, the LSP breaks there. If the labels stop changing when they should be swapping, you have found your router.

MPLS ping and traceroute test the LSP itself rather than IP:

PE1#ping mpls ipv4 10.255.0.2/32
PE1#traceroute mpls ipv4 10.255.0.2/32

These use LSP echo (RFC 4379) and will tell you the LSP is broken even when the IP path is fine. When you have an IP-works-MPLS-does-not situation, this is the tool that names the hop.

Byte counters in show mpls forwarding-table are underrated. Run the command twice with traffic flowing. If the Bytes Switched column is not incrementing on the entry you expect, traffic is not taking the LSP you think it is.

FAQ

My LDP neighbor is up but I have no labels for some prefixes. Why?

LDP only allocates labels for prefixes in the IGP, and by default IOS does not allocate labels for BGP-learned prefixes. If the prefix is not in your IGP, there is no label. Check with show mpls ldp bindings <prefix> <mask>.

Should I filter which prefixes get labels?

In a large core, yes. You only need labels for the PE loopbacks. mpls ldp label allocate global host-routes (or an explicit prefix list) cuts the LIB down dramatically and is standard practice in production.

Does LDP need its own adjacency, or does it follow the IGP?

Both, in a sense. LDP discovers neighbors on directly connected links with UDP hellos, then builds a TCP session to the peer's router ID. But the labels it installs in the forwarding table are chosen based on the IGP's best next hop, so LDP follows the IGP. This is also why an IGP/LDP synchronisation problem after a link comes back can blackhole traffic, and why mpls ldp sync exists.

Can I run MPLS without LDP?

Yes. Segment routing distributes labels in the IGP itself and removes LDP entirely. See Segment Routing (SR-MPLS).

Key Takeaways

• Troubleshoot bottom up: interface, IGP, mpls interfaces, LDP session, bindings, forwarding table.
• A working IGP proves nothing about MPLS. Loopback pings can succeed at 100 percent while the VPN is completely down.
• State: Oper is the only acceptable LDP neighbor state.
• show ip cef vrf <name> <prefix> returning unusable: no label is the definitive fingerprint of a broken transport LSP.
• In the forwarding table, a broken LSP shows as No Label in the Outgoing Label column, not as a missing row.
• imp-null in the bindings is what triggers penultimate hop popping. It is normal and expected.
• Pin the LDP router ID to a loopback with force, or an interface flap will reset your sessions.

Next: Troubleshooting MPLS L3VPN for the VPN-layer failures (missing RTs, missing redistribution), or back to the MPLS cluster guide.