MPLS L3VPN Lab Not Pinging? Check These Five Hops

Two customer routers, a pair of provider edge boxes, and a ping that dies without an error message. In a small MPLS L3VPN lab the fault almost always sits at one of five checkpoints, and each one has a command that either shows the dependency working or shows it missing. The mistake is to restart BGP every time the ping fails instead of testing the dependencies in order. Jump straight to the VRF configuration and you can spend an hour on a problem that began with an unresolved next hop two devices away.

Work the list from the bottom up. A checkpoint that passes stays passed, and the first failure is the one worth debugging.

Checkpoint one: the PEs can reach each other

Each PE needs a route to the other PE's loopback, and that route has to resolve through something real. An interior gateway protocol is the usual way to get there, but a static route works too as long as the recursive lookup lands on a live adjacency. On IOS-style boxes, show ip route 10.0.0.2 followed by show ip cef 10.0.0.2 tells you whether the prefix exists and whether it has a resolved adjacency. A route in the table with no adjacency behind it is not reachability.

Check both directions. Asymmetric IGP costs, a passive interface on the wrong side, or a distribute list that filters the loopback will each break one direction only, and one direction is enough to kill the session. If the loopbacks ping but the BGP session sits in Active, look at the update source before touching anything else.

Checkpoint two: a label path exists

An IP route to the remote loopback does not prove that the transport will push a label. In an LDP design, confirm that the remote loopback has a local and a remote binding, and that the outgoing label appears in the forwarding table. show mpls ldp bindings 10.0.0.2 32 shows the label pairs, and show mpls forwarding-table 10.0.0.2 shows what the line card will actually impose. When the second command shows "no label" or punts to IP, the transport is not carrying the VPN traffic the way the design assumes.

The distinction comes from how MPLS separates forwarding state from destination prefixes, which is the model described in RFC 3031. If your lab uses RSVP-TE or BGP-adjacent labels instead of LDP, check that mechanism's own state; assuming LDP distributes every underlay label is a common way to chase a phantom bug. A broken label path usually shows up later as a VPN route that is present but unusable.

Checkpoint three: the VPN route arrived intact

Look at the VPNv4 or VPNv6 route for the exact customer prefix, not at the session summary. show bgp vpnv4 unicast all 10.10.1.0/24 should show the route distinguisher, the next hop set to the remote PE loopback, and a label. If the prefix is missing, the export policy on the originating PE or the import policy on the receiving PE is the first suspect, and route targets are the usual culprit.

Read the route target check separately from the BGP receipt. A route can arrive with the right next hop and still fail to land in the VRF because the import target does not match. On the receiving PE, show ip route vrf CUSTOMER 10.10.1.0 is the test that matters; the BGP table only proves the route crossed the control plane.

Checkpoint four: the interface is in the VRF

A VRF definition with a route distinguisher and route targets does not move any interface into it. The CE-facing interface needs the VRF assignment, and show ip vrf interfaces or show ip interface brief should list it under the right instance. This is the checkpoint where a copied configuration most often goes wrong, because the VRF block looks complete while the interface still sits in the global table.

Then confirm the PE has learned the local customer prefix into that VRF, and that the CE has a route back through the attachment. A static default on the CE pointing at the PE is enough for a lab, provided the PE's VRF has a route to the CE LAN. If either half is missing, the ping fails before any label is imposed.

Checkpoint five: the reply takes a path home

Trace the forward packet and then trace the return packet, because they use different tables. On the ingress PE, the customer source should resolve inside the VRF to the remote prefix with the remote label. On the egress PE, the destination should resolve inside the same VRF to the CE-facing interface. A ping sourced from the PE itself is not evidence: it may leave through the global table or a different source address, which is why ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 is the test to run.

Host firewalls, reverse-path filtering, and CE access lists still apply. If the forward path works and the reply dies, the problem is a route or a filter on the return side, not the MPLS transport.

Keep a one-line record per checkpoint naming the first dependency that failed. That record turns "the customer cannot ping" into a specific question about reachability, label state, route import, interface membership, or the return path, and it keeps the next debugging session from repeating the same five commands in the same order.