A VXLAN tunnel that never comes up at all is a different fault from one that's up and flapping, or up and missing one route. This is the layer-by-layer order that finds it — the BGP EVPN neighbor, the route that actually builds the tunnel, and the VPN Target cross-match that decides whether that route is accepted.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A tunnel that never establishes fails at exactly one of three layers, and the layer depends on whether it's an L2 tunnel or an L3 tunnel.
In a BGP EVPN VXLAN distributed-gateway fabric, the tunnel between two VTEPs isn't configured directly — it's built dynamically once the right route is received. An L2 tunnel is built from a Type 3 Inclusive Multicast route; an L3 tunnel is built from a Type 5 IP Prefix route (also called an IRB route). Either route only gets accepted if the local VPN Target import list overlaps with what the remote side exported. A tunnel that won't establish at all, then, is failing at one of exactly three layers: the BGP EVPN neighbor itself, the route that builds that specific tunnel type, or the VPN Target cross-match that decides whether the route is let in.
This is different from a tunnel that comes up and later drops, or one where the tunnel exists but a specific route inside it is missing — those are their own faults, cross-referenced at the end of this note. What follows here is the three-layer split, the display bgp evpn checks for L2 and L3 tunnels side by side, the root causes behind each layer, and field-tested answers.
VXLAN tunnel-establishment failures split first by tunnel type — L2 or L3 — and then by the same three layers underneath both.
An L2 and an L3 tunnel share layer 1 (the BGP EVPN neighbor) but diverge at layer 2, because they're built from two different EVPN route types with two different configuration commands to check.
Diagram labels are kept in English for engineering clarity.
Layer 1 is shared — fix the neighbor once and both tunnel types benefit. Layers 2 and 3 are specific to which tunnel type you're chasing, and the commands genuinely differ between them.
One shared layer, then two tunnel-specific layers with their own route type and their own VPN Target command.
Neither tunnel type can build anything before this layer is solid — check it first regardless of whether you're chasing an L2 or L3 fault.
<VTEP2> display bgp evpn peer
BGP local router ID : 10.3.3.3
Local AS number : 100
Total number of peers : 2 Peers in established state : 2
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
10.1.1.1 4 100 4010 4016 0 0066h46m Established 1
10.2.2.2 4 100 4009 4010 0 0066h40m Established 4
<VTEP2> ping -a 10.2.2.2 10.3.3.3
Reply from 10.3.3.3: bytes=32 time=1ms TTL=126
Ping statistics for 10.3.3.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
// loopback-to-loopback reachable -> if peer still isn't Established, check TCP session state next
<VTEP2> display tcp status
TCPCB Tid/Soid Local Add:port Foreign Add:port VPNID State
49f3370c 262/8 10.2.2.2:53342 10.3.3.3:179 0 Established
49f339f4 262/7 10.2.2.2:55160 10.1.1.1:179 0 Established
// clean Established state here -> the neighbor layer is not the problemAn L2 tunnel between two VTEPs is built entirely from this one route type — if it isn't there, the tunnel isn't either.
<VTEP2> display current-configuration interface nve 1
interface Nve1
source 10.2.2.2
vni 10 head-end peer-list protocol bgp
<VTEP2> display bgp evpn all routing-table inclusive-route 0:32:10.2.2.2
Total routes of Route Distinguisher(1:10): 1
BGP routing table entry information of 0:32:10.2.2.2:
Imported route.
From: 0.0.0.0 (0.0.0.0)
Ext-Community: RT <1 : 100>, RT <10 : 1>, Tunnel Type <VxLan(8)>
Route Type: 3 (Inclusive Multicast Route)
Advertised to such 2 peers:
10.3.3.3
10.1.1.1
// From: 0.0.0.0 = generated locally; check the same prefix for the remote VTEP's source address nextAn L3 tunnel is built from the gateway's IP Prefix route instead — same idea, different route type and a different command.
<VTEP2> display current-configuration interface vbdif 10
interface Vbdif10
ip binding vpn-instance vpn1
ip address 192.168.10.1 255.255.255.0
<VTEP2> display bgp evpn all routing-table prefix-route 0:24:192.168.20.0
Total routes of Route Distinguisher(3:100): 1
BGP routing table entry information of 0:192.168.20.0:24:
Ext-Community: RT <1 : 100>, Tunnel Type <VxLan(8)>
Route Type: 5 (Ip Prefix Route)
VPN-Instance vpn1, Router ID 10.2.2.2:
BGP routing table entry information of 192.168.20.0/24:
Relay Tunnel Out-Interface: VXLAN
// showing up under VPN-Instance vpn1, not just the EVPN address family, is what confirms the L3 tunnel can actually use itThe route arrived; the local side still has to let it in — and the command that controls that is different for L2 and L3 tunnels.
// L2 -- EVPN instance, no "evpn" keyword
<VTEP2> display current-configuration configuration evpn-instance evpn10
evpn vpn-instance evpn10 bd-mode
vpn-target 1:100 10:1 export-extcommunity
vpn-target 10:1 import-extcommunity
// L3 -- VPN instance, "evpn" keyword required
<VTEP2> display current-configuration configuration vpn-instance vpn1
ip vpn-instance vpn1
ipv4-family
vpn-target 1:100 export-extcommunity evpn
vpn-target 1:100 import-extcommunity evpn
vxlan vni 100Once the three layers above have told you where the problem sits, these five account for most of what's actually wrong.
SYMPTOMdisplay bgp evpn peer shows a peer stuck in a non-Established state indefinitely, and nothing downstream — no Inclusive route, no IP Prefix route — has anything to build on.
CAUSEBoth L2 and L3 tunnel-building routes ride on the same BGP EVPN session, and that session is sourced from a Loopback on each VTEP. If the IGP between the two VTEPs doesn't actually carry a route to the peer's Loopback, the TCP session behind BGP can't form at all, and it looks like an EVPN problem when it's really an IGP one.
FIXPing from the local Loopback source address to the remote one directly (ping -a <local> <remote>) before touching any EVPN or VPN-target configuration — if that fails, fix the IGP route first.
SYMPTOMThe two Loopbacks can ping each other fine, but display bgp evpn peer still won't reach Established.
CAUSEReachability between the two loopbacks confirms routing is fine, but doesn't confirm the BGP TCP session itself survives the path — a CPU-defend ACL, a CPCAR rate limit, or a middlebox somewhere in between can quietly drop TCP port 179 traffic while ICMP still gets through cleanly.
FIXCheck display tcp status for the actual session state between the two Router IDs; if it isn't cleanly Established, look for CPCAR limits or ACLs on the path that specifically affect TCP port 179, not just general reachability.
SYMPTOMdisplay bgp evpn all routing-table inclusive-route on the originating VTEP shows the route with From: 0.0.0.0 and lists it as advertised to the remote peer — but the remote VTEP's own lookup for the same prefix comes back empty.
CAUSEThe L2 tunnel's Inclusive Multicast route is only accepted at the remote end if that VTEP's EVPN instance import-extcommunity shares a value with the RT the route was exported with — with no overlap, the route is silently dropped on arrival, with no error on either side.
FIXCompare the remote VTEP's evpn-instance import-extcommunity directly against the Ext-Community RT values shown on the originating side's advertised route, not against what you assume was configured.
SYMPTOMThe IP Prefix route looks correctly generated and even shows up in the EVPN address family on the receiving VTEP, but the tunnel to that gateway still won't build and the subnet stays unreachable.
CAUSEAn L3 tunnel needs its VPN Target configured under the VPN instance's ipv4-family with the trailing evpn keyword (vpn-target ... export-extcommunity evpn / import-extcommunity evpn) — configuring it as a plain vpn-target without that keyword, or configuring it under the EVPN instance instead (which is where the L2 form belongs), leaves the route visible at the EVPN level but never resolved into the VPN instance's own routing table.
FIXConfirm with display current-configuration configuration vpn-instance <name> that the export/import-extcommunity lines both carry the evpn keyword, and that the route shows up specifically under the VPN-Instance entry in the routing-table output, not only in the EVPN address family section above it.
SYMPTOMAfter resolving an L2 tunnel-establishment issue between two VTEPs, the L3 tunnel between the same two devices still won't come up, and it reads as though the earlier fix didn't work.
CAUSEThe two tunnel types share only the BGP EVPN neighbor layer — everything above that (the route type, the VPN Target configuration level, the specific import/export command) is independent between L2 and L3. Fixing an EVPN-instance RT mismatch does nothing for a VPN-instance RT mismatch on the same box.
FIXTreat an L2 fix and an L3 fix as two separate tickets on the same neighbor pair, and re-run the layer 2 and layer 3 checks for each tunnel type on its own, even after the other one is confirmed working.
Pulled straight from the field — the ones worth having an answer ready for.
Established only confirms the BGP EVPN control-plane session is up between the two VTEPs. The tunnel itself still needs its route type — Inclusive Multicast for L2, IP Prefix for L3 — to be generated, advertised, received, and accepted through the VPN Target cross-match. A healthy neighbor with a missing or rejected route still produces no tunnel.
Inclusive Multicast (Route Type 3) is what builds an L2 VXLAN tunnel — it's tied to the VTEP's NVE source address and carries no host information at all, just "this VTEP exists and is reachable for this VNI." IP Prefix (Route Type 5) is what builds an L3 tunnel — it's tied to a specific gateway (Vbdif) subnet and is what an IRB gateway advertises so other VTEPs can route to that subnet through it.
Check which command level you actually configured it at. For an L2 tunnel the VPN Target lives under the EVPN instance (evpn vpn-instance ... vpn-target ... export/import-extcommunity, no trailing keyword); for an L3 tunnel it lives under the VPN instance's ipv4-family with the evpn keyword (vpn-target ... export/import-extcommunity evpn). Identical-looking RT numbers configured at the wrong level, or missing the evpn keyword on the L3 side, produce exactly this symptom.
This note assumes the tunnel has literally never come up — no BGP EVPN Established state, or no Inclusive/IP Prefix route ever accepted. If the tunnel did establish and then drops, flaps, or comes up fine but a VM migration or specific traffic flow behaves oddly, that's a different set of checks — see the VXLAN Overlay Faults note, which picks up from a tunnel that already exists.
If every route check in this note comes back clean — neighbor Established, Inclusive or IP Prefix route generated and received, VPN Target overlapping — and the tunnel still isn't forwarding traffic, the fault has moved past tunnel establishment into a different category: check whether a specific host's EVPN route is missing rather than the tunnel itself, covered in the EVPN Route Not Learned note.
Yes — every command in this note is read-only except for the loopback-to-loopback ping used to test reachability, which doesn't touch the fabric's data plane. None of them require configuration changes just to diagnose, so there's no reason to wait for a maintenance window before running the checks themselves.
This note is built around the Huawei CloudEngine-style BGP EVPN distributed-gateway fabric and its display bgp evpn peer / display bgp evpn all routing-table inclusive-route / prefix-route / display current-configuration configuration evpn-instance / vpn-instance commands, plus the field cases behind them. It assumes a standard two-tier (L2 + L3) EVPN VXLAN design and doesn't cover controller-orchestrated (SDN fabric) automatic underlay/overlay provisioning, where these same symptoms can trace back to the controller rather than to the device configuration shown here.
Tell us which layer it's stuck at — neighbor, route, or VPN Target — plus whether it's an L2 or L3 tunnel, and the relevant display bgp evpn output, and we'll help you read it.