A VPN route that won't cross to the far PE, two VPNs that leak into each other, or a network that takes two minutes to reconverge after a PE reboot — most L3VPN tickets fall into a handful of repeatable shapes once the PE-PE BGP session itself is confirmed healthy. This is the diagnostic order that finds the fault fastest, the exact display commands for each stage, and the root causes that account for most of these cases.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Half of what looks like an L3VPN fault is actually a BGP or LDP fault wearing a VPN costume.
If PE-PE IBGP itself won't reach Established, that's a BGP fault tree problem before it's an L3VPN problem — see BGP Neighbor Won't Establish & Route Flapping: A Complete Checklist first. Once that session is confirmed healthy, L3VPN faults split into a few repeatable shapes: a route that never crosses to the far PE at all (local VPN-Target mismatches, IP collisions between VPN instances, missing labels, cross-domain relay problems, or a route reflector filtering it out silently), and a route that does cross but something is still wrong (physical-layer flapping riding underneath an otherwise-correct VPN, or convergence that takes minutes instead of seconds after a PE failure).
What follows is the fault tree this is built on, the checks for each stage with the exact commands to run, the root causes that show up again and again once you're past the first few checks, and a handful of real FAQ answers pulled from actual field cases.
L3VPN failures split into exactly two shapes: the route never crosses to the far PE, or it does and something still isn't right.
Placing the symptom on this tree first saves a lot of backtracking later — it tells you which of the sections below actually applies to what you're looking at.
Diagram labels are kept in English for engineering clarity.
Once you know which branch applies, almost every check below is a single display command away from a confirmed cause — the trap is troubleshooting the VPN layer when the actual fault is sitting one layer down, in IGP, LDP or the physical link underneath it.
Four stages, four different sets of things to look at — and the command that tells you exactly where a route stops being visible.
Before touching RT or label configuration, confirm the route is even present in the local VPN routing table on the near PE.
<PE> display ip routing-table vpn-instance vpna
// confirm the CE-advertised prefix is present before looking at RT, labels, or the far PE at allThe route is in the local VPN table, the PE-PE BGP session is Established, but the far PE still doesn't have it — check the RT match itself, and a less obvious local one.
<PE> display ip vpn-instance verbose
VPN-Instance Name and ID : vpn1, 1
Route Distinguisher : 100:1
Export VPN Targets : 100:1
Import VPN Targets : 1:1
// Export/Import Targets compared directly against the far PE's own values
<PE1> display ip interface brief
Interface IP Address/Mask Physical Protocol VPN
10GE0/0/1 10.1.1.2/30 up up VPN-A
10GE0/0/2 10.1.1.2/30 up up VPN-B
// same IP bound to two different VPN instances -- local crossing picks the wrong routeThe route shows up in the BGP VPNv4 table on the far PE, but it never gets installed — the reason is almost always the next hop, the tunnel, or a missing label.
<HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1
Relay IP Nexthop : 10.1.1.2
Original nexthop : 3.3.3.3
..., valid, internal, best, select, active, pre 255
<HUAWEI> display bgp vpnv4 all routing-table 10.2.1.2
Label information (Received/Applied): 13316/NULL
Relay IP Out-Interface: 10GE0/0/1
Relay Tunnel Out-Interface: 10GE0/0/1
// both fields present -- route can reach a real LSP with a real label
// cross-domain Option-B fix: ASBR Loopback was 1.1.1.2 255.255.255.252 (/30)
[ASBR1] interface loopback 0
[ASBR1-LoopBack0] ip address 1.1.1.2 32
[ASBR1] reset mpls ldpBoth PEs' configuration looks correct in isolation — the filtering is happening on the RR sitting between them.
<RR> display ip extcommunity-filter
Extended Community filter Number 1
index: 10 deny rt : 100:1
index: 20 permit rt : 200:1
// RT 100:1 is being denied -- this PE's Export VPN Target never gets reflected
[RR] ip extcommunity-filter 1 permit rt 100:1
[RR] bgp 100
[RR-bgp] ipv4-family vpnv4
[RR-bgp-af-vpnv4] undo rr-filter
[RR-bgp-af-vpnv4] rr-filter 1The VPN configuration is correct — the fault is one layer down, or in how failover actually happens.
<DeviceA> display mpls lsp include 1.1.1.1 32
LSP Information: RSVP LSP ... TimeStamp: 1825411sec // stable for a long time
LSP Information: LDP LSP ... TimeStamp: 10sec // this one keeps resetting
[PE3] ip vpn-instance vpn-access
[PE3-vpn-instance-vpn-access] route-distinguisher 22:1
// distinct RD per PE turns the equal-cost VPNv4 paths into two independently comparable routesOnce the stages above have told you where the problem sits, these six account for most of what's actually wrong.
SYMPTOMA deliberately shared-RT VPN, set up so two VPN instances can reach each other, only works in one direction.
CAUSELocal cross-import picks the wrong route when two VPN instances on the same PE happen to bind their interfaces to identical IP addresses. The PE prefers the local direct route over the imported BGP route during local route crossing, so the crossed VPN never actually resolves in that direction, even though the RTs match correctly.
FIXGive each VPN instance distinct local IP addressing, then rebuild the affected BGP peer once the addressing changes.
<PE1> display ip interface brief
10GE0/0/1 10.1.1.2/30 up up VPN-A
10GE0/0/2 10.1.1.2/30 up up VPN-B // duplicate -- rebind to a distinct subnetSYMPTOMTwo PEs behind a redundant pair of route reflectors can't see each other's VPNv4 routes at all, with nothing obviously wrong at either PE.
CAUSEpolicy vpn-target under ipv4-family vpnv4 tells the RR to apply VPN-Target filtering to what it accepts. If the RR itself has no VPN instance configured for that RT, it silently accepts nothing carrying that Import Target — a filtering feature that only makes sense on a PE, quietly misapplied to a pure route-reflector role.
FIXEither remove policy vpn-target on the RR so it accepts and reflects everything (the common approach for a pure RR), or add a matching VPN instance on the RR purely to give it the RT to match against.
[RR] bgp 100
[RR-bgp] ipv4-family vpnv4
[RR-bgp-af-vpnv4] undo policy vpn-targetSYMPTOMAn Option-B VPNv4 route works in one direction across the domain boundary but not the other.
CAUSELDP only allocates labels for /32 host routes by default. If an intermediate ASBR's Loopback is configured with a shorter mask, LDP can't build a label for that FEC, the LSP toward it never completes, and the far PE's otherwise-present VPNv4 route is never installed — because its underlying LSP isn't valid, not because anything in the VPN configuration is wrong.
FIXCorrect the Loopback mask to /32 on the affected ASBR and reset mpls ldp to force re-signaling.
[ASBR1] interface loopback 0
[ASBR1-LoopBack0] ip address 1.1.1.2 32
[ASBR1] reset mpls ldpSYMPTOMThe route reflector accepts a VPNv4 route from one PE, but only some of the RR's other clients ever learn it.
CAUSEAn ip extcommunity-filter referenced by rr-filter under the RR's BGP-VPNv4 view denies that specific RT — often left behind from an earlier, narrower reflection policy that was never revisited when new VPN instances were added to the network.
FIXAdd a permit entry for the RT (or remove the filter reference entirely) and reapply rr-filter.
<RR> display ip extcommunity-filter
index: 10 deny rt : 100:1
[RR] ip extcommunity-filter 1 permit rt 100:1
[RR-bgp-af-vpnv4] undo rr-filter
[RR-bgp-af-vpnv4] rr-filter 1SYMPTOMA specific VPN prefix flaps continuously even though the VPN configuration, RT and BGP session all check out clean.
CAUSEThe private route rides an LSP whose IGP neighbor and TE tunnel are stable, but the LDP session underneath is bouncing because the physical interface it runs over is repeatedly flapping up and down — something no amount of VPN-layer troubleshooting will ever surface.
FIXWork down from the route type — BGP, then IGP, then LDP/RSVP, then the physical interface — rather than assuming the fault sits in the layer where the symptom is visible; once found, treat it as a physical or optics fault, not a VPN one.
<DeviceA> display mpls ldp session
// LDP session itself shows as bouncing
<DeviceA> display interface 10GE0/0/0
Last physical up time : 2010-05-20 21:33:42
Last physical down time : 2010-05-20 21:31:58
// physical layer is where the flap actually originatesSYMPTOMAfter a PE reboot, downstream PEs take roughly two minutes to relearn a CE's business subnet through the surviving PE, instead of failing over immediately.
CAUSEWhen redundant PEs advertising the same CE prefix all use an identical Route Distinguisher, their VPNv4 routes are treated as the same BGP path rather than two independent equal-cost paths. The route reflectors only forward a new path once they've confirmed the old PE's IGP/BGP session is actually gone, so MPLS VPN convergence rides behind full IGP convergence.
FIXAssign each PE a distinct RD for the VPN instance so both routes exist as independent, comparable paths — one active, one immediately available — or deploy VPN FRR.
[PE3] ip vpn-instance vpn-access
[PE3-vpn-instance-vpn-access] route-distinguisher 22:1
// PE4 keeps its own distinct RD -- PE5/PE6 now hold two independent, comparable pathsPulled straight from the field — the ones worth having an answer ready for.
Work the chain in order rather than guessing: is the route valid and best in display bgp vpnv4 vpn-instance routing-table (if not, the BGP next hop probably isn't reachable); if valid but not shown as sent, check the outbound policy at the sender and the inbound policy at the receiver; if it's been sent and received, check whether it iterates to a real tunnel (Relay Tunnel Out-Interface) and actually got a private label (Label information); if all of that is clean, the RT Export/Import match is the next and most common place it dies quietly.
This almost always means the two directions are actually using different underlying mechanisms that happen to look symmetric in the configuration — a cross-domain Option-B path where only one ASBR's Loopback has the wrong mask, or an IBGP session where only one side is missing peer connect-interface loopback for the session's source interface. Check each direction's path independently rather than assuming a shared root cause.
Confirm the RT match isn't being filtered somewhere between the two PEs rather than at either PE itself — most often a route reflector with policy vpn-target enabled but no local VPN instance for that RT, or a leftover extcommunity-filter tied to rr-filter that predates the current VPN. Both silently drop the route with nothing visible at either PE.
Below the VPN layer. Confirm the IGP neighbor and the tunnel (LDP or RSVP-TE) carrying that route are themselves stable before assuming anything is wrong with BGP or the VPN instance — an LSP with a short uptime almost always traces back to a flapping physical interface or optics issue one layer further down.
Not if the redundant PEs are supposed to offer two independent equal-cost paths. Check whether they're using the same Route Distinguisher for the VPN instance — if so, their VPNv4 routes are indistinguishable as a single BGP path, and failover has to wait for full IGP convergence before a new path is even visible. Distinct RDs per PE, or VPN FRR, turn that into a near-instant switchover.
This note is built around the Huawei AR-series router's BGP/MPLS L3VPN fault-classification model and its display bgp vpnv4 / display ip vpn-instance / display mpls lsp commands, plus the field cases behind them. If your PE is a different vendor, the exact commands change, but the underlying logic — RT Export/Import matching, tunnel iteration, route-reflector filtering, RD-driven convergence — carries over directly. It doesn't cover EVPN-based VPN overlays, Option-A/Option-C inter-AS variants in depth, or IPv6 VPN (L3VPNv6) specifics beyond what's noted inline.
Tell us which PE the route is missing from, or how long failover is actually taking, and we'll help you read the display bgp vpnv4 output.