Home / Notes / EVPN Route Not Learned
NOTES · EVPN / BGP TROUBLESHOOTING

EVPN Route Not Learned: Step-by-Step BGP EVPN Diagnosis

A Leaf switch that can't find the route to a destination VM is one of the most common tickets in a BGP EVPN VXLAN fabric. This is the check order that finds the fault fastest — confirm the ARP is really there, confirm the route is really generated, confirm it's really learned, and confirm the VPN Target actually lets it in.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

Four Reasons, One Strict Order

The route is missing for one of exactly four reasons, and they sit in a strict order — check them in that order and you stop guessing.

On a Leaf switch in a BGP EVPN VXLAN fabric, "the route to that VM isn't there" almost never means the fabric is broken end to end. It means one specific link in a four-link chain didn't complete: the destination Leaf never learned the VM's ARP, that Leaf never turned the ARP into an EVPN route, this Leaf never learned the route the other side advertised, or the route arrived but the VPN Target community never let it cross into the local routing table.

What follows is the fault split this is built on, the display bgp evpn commands to run at each stage, the root causes that show up again and again once you're past the first check, and field-tested answers to the questions that come up around this exact fault.

Read the Split Before You Touch Any Configuration

EVPN route-missing faults split into two halves: the problem is still on the remote Leaf, or the remote Leaf did its job and the problem is in what came back to this one.

Placing the symptom on this split first tells you whether to keep working the remote Leaf or come back and work the local one — which saves a round trip to the wrong device.

EVPN Route Missing on Leaf Problem Is Still on the Remote Leaf Problem Is in What Came Back to This Leaf Check 1 · ARP not learned for the VMno ARP entry on remote Leaf -- not an EVPN fault yet Check 2 · EVPN route not generatedVbdif gateway / EVPN instance / RT config / route-policy Check 3 · Route not learned locallynot advertised by remote peer, or filtered in transit Check 4 · VPN Target doesn't crossimport/export extcommunity mismatch -- silently dropped

Diagram labels are kept in English for engineering clarity.

Checks 1 and 2 below live entirely on the remote Leaf; checks 3 and 4 live entirely on this Leaf. Nothing about IP reachability, VLAN config elsewhere in the fabric, or the physical link belongs on this tree — those are separate faults with their own checks.

Working Through Each Check

Four checks, one command each, and each one tells you whether to keep going or go fix something specific.

Check 1 — Confirm the Remote Leaf Actually Learned the VM's ARP

If the ARP isn't there, nothing past this point matters yet — the EVPN route can't exist before the ARP does.

  1. Identify which Leaf the destination VM is actually on (the "remote Leaf") — from the management platform, the controller, the Border Leaf's routing table, or the device inventory.
  2. Run display arp network <VM-IP> on the remote Leaf. A learned ARP entry shows the VM's IP, MAC, VLAN/BD and access interface.
  3. If the ARP isn't there at all, this is a separate ARP-learning fault, not an EVPN fault — chase that down first, then come back to check 2.
<Leaf3> display arp network 192.168.1.11
ARP Entry Types: D - Dynamic, S - Static, I - Interface, O - OpenFlow, RD - Redirect
EXP: Expire-time VLAN:VLAN or Bridge Domain

IP ADDRESS      MAC ADDRESS    EXP(M) TYPE/VLAN       INTERFACE        VPN-INSTANCE
----------------------------------------------------------------------------------------
192.168.1.11    0019-9400-000b 1164   D/BD1012254     Eth-Trunk1.4     ABC
----------------------------------------------------------------------------------------
Total:1         Dynamic:1       Static:0    Interface:0    OpenFlow:0
Redirect:0
// ARP present -> move to check 2. Nothing here -> this is an ARP fault, not an EVPN fault.

Check 2 — Confirm the Remote Leaf Actually Generated the EVPN Route

An ARP entry existing locally doesn't mean it was ever turned into a route the rest of the fabric can see.

  1. Filter the remote Leaf's own EVPN routing table by the VM's IP: display bgp instance overlay evpn all routing-table | include <VM-IP>. A hit means the local MAC route was generated; the next-hop reads 0.0.0.0 because the source is local.
  2. If nothing comes back, the route was never generated — check the Vbdif/BDIF gateway configuration for that VM's subnet, the EVPN instance configuration, and whether the BD and VPN's RT (route-target) attributes are actually set, plus whether a BGP route-policy is filtering it out before it's even created.
  3. If everything above checks out and the route still won't generate, reset arp dynamic ip <VM-IP> once to force re-learning before escalating.
<Leaf3> display bgp instance overlay evpn all routing-table | include 192.168.1.11
Local AS number : 64888

BGP Local router ID is 172.31.58.20
Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
              h - history,  i - internal, s - suppressed, S - Stale
              Origin : i - IGP, e - EGP, ? - incomplete

EVPN address family:
 Number of Mac Routes: 82864
*>    0:48:0019-9400-000b:32:192.168.1.11                    0.0.0.0
// 0.0.0.0 next-hop = this route was generated locally, on this Leaf

Check 3 — Confirm This Leaf Actually Learned the Route the Remote Side Sent

The remote Leaf can have advertised a perfectly correct route and this Leaf can still not have it — that's a receiving-side problem, not a generating-side one.

  1. On the remote Leaf, look up the specific MAC route it generated: display bgp instance overlay evpn all routing-table mac-route <prefix>, where <prefix> is the 0:48:<mac>:32:<ip> string filtered out in check 2. Confirm its Label information, Ext-Community RT values, and the Advertised to such N peers list.
  2. Repeat the same lookup on this Leaf, for the same prefix. If it doesn't show up at all, the remote Leaf either isn't advertising it to this peer, or a route-policy somewhere between the two is filtering it — check both.
  3. If this Leaf does have the route, note that with multiple Spine route reflectors, the same prefix often arrives twice, once from each Spine, and BGP best-path selection marks one of them "not preferred for peer address" — that's expected, not a fault.
<Leaf3> display bgp instance overlay evpn all routing-table mac-route 0:48:0019-9400-000b:32:192.168.1.11

BGP local router ID : 172.31.58.20
Local AS number : 64888
Total routes of Route Distinguisher(2101:1012254): 1
BGP routing table entry information of 0:48:0019-9400-000b:32:192.168.1.11:
Imported route.
Label information (Received/Applied): NULL/1012254 1010000
From: 0.0.0.0 (0.0.0.0)
Route Duration: 0d07h52m39s
Original nexthop: 172.31.58.138
Ext-Community: RT <0 : 1010000>, RT <0 : 1012254>, Tunnel Type <VxLan>, Router's MAC <0000-5e00-02c9>
Route Type: 2 (MAC Advertisement Route)
Advertised to such 1 peers:
    10.124.138.251
// this is the remote Leaf's own advertised copy -- confirm it looks like this before checking the local side

Check 4 — Confirm the VPN Target Actually Lets the Route Cross

This is where almost every remaining case ends up: the route arrived, and the local VPN Target still doesn't let it into the routing table.

  1. On this Leaf, compare the received route's Ext-Community RT values (from check 3's local lookup) against this Leaf's own EVPN instance import-extcommunity: display current-configuration configuration evpn-instance <name>.
  2. The two only need one matching value, not an exact match — but if there's no overlap at all, the route is silently dropped with no log and no error.
  3. If the values don't overlap, correct the import-extcommunity on this Leaf's EVPN instance to include at least one RT value the remote side actually exports; don't change the remote side unless it's genuinely misconfigured.
<Leaf1> display current-configuration configuration evpn-instance evpn10
evpn vpn-instance evpn10 bd-mode
 route-distinguisher 1:10
 vpn-target 1:100 10:1 export-extcommunity
 vpn-target 10:1 import-extcommunity
// import-extcommunity must share at least one value with the Ext-Community RT the remote Leaf advertised

5 Root Causes That Show Up Again and Again

Once the four checks above have told you where the problem sits, these five account for most of what's actually wrong.

1. Remote Leaf Never Learns the VM's ARP in the First Place

SYMPTOMdisplay arp network <VM-IP> on the remote Leaf comes back empty, and nothing further down the EVPN chain has anything to work with yet.

CAUSEThe EVPN route for a VM's IP is generated directly from the local ARP/host-route table on the Leaf it's attached to — if the ARP was never learned (host down, wrong VLAN, wrong access interface, gateway ARP suppression misconfigured), there is no source data for an EVPN route to be built from at all.

FIXTreat this as an ARP-learning fault on the remote Leaf first — check the access-side interface, VLAN/BD membership and gateway config there — before touching anything EVPN-related.

2. BDIF Gateway or EVPN Instance Isn't Actually Configured for That Subnet

SYMPTOMThe ARP is confirmed present on the remote Leaf, but display bgp instance overlay evpn all routing-table | include <VM-IP> comes back with nothing.

CAUSEThe MAC/IP route only gets generated if the Vbdif interface for that VM's BD is correctly bound to the right VPN instance and the corresponding EVPN instance is actually configured — a gateway that's up but bound to the wrong vpn-instance, or an EVPN instance that's missing entirely for that BD, produces a Leaf that has the ARP and simply never turns it into a route.

FIXConfirm display current-configuration interface vbdif <BD-ID> shows the correct ip binding vpn-instance, and that an evpn vpn-instance exists and is bound to that BD.

3. A Route-Policy Somewhere Between the Two Leafs Quietly Filters It

SYMPTOMThe remote Leaf's own EVPN table shows the route generated and advertised, but the local Leaf's table shows nothing for the same prefix.

CAUSEA BGP route-policy applied on either Leaf, or on a Spine route reflector in between, can filter an EVPN route out of the advertisement without producing any error or log entry — the route simply never crosses to the other side.

FIXCheck for a route-policy configured under the BGP EVPN peer or address-family on every device in the advertisement path, not just the two endpoints, and confirm it isn't matching this specific prefix or RT.

4. VPN Target Doesn't Cross — the Single Most Common Last Cause

SYMPTOMThe route is confirmed present on the local Leaf's EVPN table (display bgp instance overlay evpn all routing-table mac-route <prefix> shows it) but it never makes it into the actual forwarding/routing table.

CAUSEBGP EVPN accepts a route into the routing table only if at least one of the route's Ext-Community RT values matches one of the local EVPN instance's import-extcommunity values — if the export and import RT sets don't overlap at all, the route is dropped silently with nothing in the logs.

FIXCompare display current-configuration configuration evpn-instance <name>'s import-extcommunity against the Ext-Community RT values the remote side is actually advertising (not the values you assume it's advertising), and adjust the local import list to include a matching value.

5. Two Spines, Two Copies of the Same Route, One Marked Non-Preferred — That's Not the Bug

SYMPTOMThe local EVPN table shows two entries for the exact same prefix, received from two different Router IDs, with one marked not preferred for peer address, and this gets reported as "the route looks wrong."

CAUSEIn any fabric with more than one Spine acting as a route reflector, the same EVPN route legitimately arrives twice — once reflected by each Spine — and BGP's own best-path selection picks one as active and marks the other as not preferred. This is normal redundant-path behavior, not evidence of a fault.

FIXConfirm both copies carry the same Label information and Ext-Community RT values; if they do, this isn't the cause of the missing-route ticket — keep looking at the VPN Target cross-check instead.

Related solution designs

AI Computing Datacenter Network: When the GPUs Are Idle, It Is Usually the NetworkThe spine-leaf EVPN VXLAN fabric this fault sits inside — where a missing host route quietly looks like a compute problem first. Resilient Data Center Network: No Single Failure Should Stop the RoomThe redundant Spine route-reflection design behind the "two copies, one non-preferred" behavior this note explains.

Six Questions That Come Up Constantly

Pulled straight from the field — the ones worth having an answer ready for.

What does route type "2" actually mean when I see it in the output?

Route Type 2 is a MAC Advertisement Route — the EVPN route type that carries a host's MAC address and, when the host's IP is known, its IP as well. It's what this whole check sequence is chasing. Type 3 (Inclusive Multicast Route) is what builds the L2 tunnel itself, and Type 5 (IP Prefix Route) is what an IRB gateway advertises for a whole subnet — different fault, covered in the VXLAN Tunnel Won't Establish note.

Do I need to check the ARP table before the EVPN routing table, or can I check them in either order?

Check ARP first. The EVPN MAC/IP route for a host is generated from that host's locally-learned ARP entry — there's no route to find in the EVPN table if the ARP was never learned on the Leaf the host is attached to, so starting with the EVPN table on a Leaf with no ARP just wastes a step.

Is it safe to run reset arp dynamic ip on a production Leaf to try to force the route back?

Yes, for a single host's dynamic ARP entry — it only clears and re-triggers learning for that one IP, not the whole ARP table. It's a reasonable thing to try once configuration has already been confirmed correct, but it's a workaround for a symptom, not a fix; if the route doesn't come back after one reset, the underlying cause (RT mismatch, route-policy, missing EVPN instance) is still there and needs fixing.

The Ext-Community RT values look identical on both ends — why does the route still get rejected?

Confirm you're comparing the right pair: the remote side's export-extcommunity (what it actually put on the wire, visible in the received route's Ext-Community field) against this Leaf's import-extcommunity (not its own export value, which is easy to compare against by mistake). A route only needs to share one RT value between those two specific fields, not match every RT the two Leafs have configured.

How is this different from a VXLAN tunnel that won't establish at all?

This note assumes the BGP EVPN neighbor is Established and the tunnel between the two VTEPs already exists — the fabric works, but one specific host's route is missing. If the BGP EVPN peer itself never reaches Established, or the tunnel-building Inclusive Multicast / IP Prefix route never crosses at all, that's a different fault covered in the VXLAN Tunnel Won't Establish note, which starts one layer lower.

Multiple VMs on the same remote Leaf are all missing their routes — is that still an ARP or RT problem?

When it's every host on one Leaf rather than one host, move the checks up a level: confirm that Leaf's BGP EVPN peer is still Established (not just was), and that its EVPN instance and RT configuration weren't touched in a recent change — a single instance-level misconfiguration affects every host behind it at once, while a single missing ARP only affects that one host.

Honest Limits of This Note

Honest Limits of This Note

This note is built around the Huawei CloudEngine-style BGP EVPN distributed-gateway fabric and its display bgp instance overlay evpn / display arp network / display current-configuration configuration evpn-instance commands, plus the field cases behind them. It assumes the BGP EVPN neighbor relationship and the underlying VXLAN tunnel already exist — for tunnel-establishment faults themselves, see the VXLAN Tunnel Won't Establish note. It doesn't cover controller-orchestrated (SDN fabric) automatic route provisioning, where the same symptoms can point back to the controller rather than the device configuration.

Staring at a Leaf that's missing one specific route?

Tell us which of the four checks it's failing at — ARP, route generation, route reception, or VPN Target — plus the relevant display bgp evpn / display arp output, and we'll help you read it.

WhatsApp an engineer →

Related Reading

VXLAN Tunnel Won't Establish: EVPN Neighbors, Inclusive Routes and VPN TargetsOne layer lower than this note — for when the BGP EVPN neighbor or the tunnel itself never comes up in the first place. VXLAN Overlay Faults: VM Migration, Tunnel State and Traffic TracingThe tunnel is up and every route looks fine — this is where to look when the traffic itself still isn't behaving. OSPF Neighbor Stuck or Route Flapping? Reading the State Machine to Find the FaultDifferent protocol, same discipline — read the state before you start changing configuration.