How an EVPN fabric knows where your server is
A practical walk through BGP EVPN route types, anycast gateways and ingress replication, with the show commands an engineer uses to trace a host.
A classic switched network finds a server by shouting: flood the frame everywhere, see who answers, remember the port. A BGP EVPN fabric finds it by being told. That single difference explains why EVPN fabrics scale, fail over quickly and can be audited, and it is worth understanding even if you never configure one yourself.
The problem with flood and learn
Traditional Layer 2 learns MAC addresses from traffic. When a switch does not know where a destination lives, it floods the frame out of every port in the VLAN. Spanning tree then blocks enough links to stop the flood looping forever, which means a good share of the cabling you paid for sits idle. Stretch that VLAN across many racks and you get large failure domains, slow convergence and a network that nobody can fully describe, because its state lives in tables that fill and expire on their own.
VXLAN on its own fixes the transport problem: it wraps Ethernet frames in UDP so a Layer 2 segment can cross a routed underlay with all links active. But plain VXLAN still floods to learn. EVPN replaces that learning with a control plane.
What EVPN actually advertises
EVPN is an address family of BGP. Each leaf switch that hosts servers acts as a VXLAN tunnel endpoint (VTEP) and tells the other leaves what it knows, using a small number of route types. Three of them do most of the work:
- Type 2, MAC and IP advertisement. When a server sends its first frame or ARP, the local leaf learns its MAC (and usually its IP) and advertises it to every other leaf with its own VTEP address as the next hop. Every leaf now knows where that server is without a single flood.
- Type 3, inclusive multicast. Each leaf announces which segments it participates in. This builds the list of VTEPs that should receive broadcast and unknown traffic for each segment. With ingress replication the sending leaf makes a unicast copy for each of them, so the underlay needs no multicast at all.
- Type 5, IP prefix. Routed subnets, for example a block of public addresses behind a customer firewall, are advertised as prefixes into a tenant VRF.
Route targets decide who imports what. A segment's routes carry its route target, and only leaves configured with that target import them. This is where tenant isolation is actually enforced, which is why the numbering of segments and route targets deserves real discipline (more on that below).
Anycast gateways: the same router everywhere
In an EVPN fabric every leaf that carries a segment can be its default gateway, using the same IP and the same virtual MAC. A server's first hop is always the switch it is plugged into. If that leaf fails, the server's bond fails over to the other leaf of the pair, which already answers on the same gateway address and MAC. Nothing on the server changes, no gateway protocol has to elect anyone, and workloads can move between racks keeping their gateway.
Combined with leaf pairs running virtual port-channels, this gives every host two physical switches behind one logical bond. On NX-OS a minimal anycast gateway looks like this:
fabric forwarding anycast-gateway-mac 0000.2222.3333
interface Vlan210
vrf member TENANT-A
ip address 192.0.2.1/26
fabric forwarding mode anycast-gateway
Tracing a host: the commands that matter
When something does not reach where it should, these are the commands we start with on Cisco Nexus, in roughly this order:
show nve peers ! are the other VTEPs up?
show nve vni ! is the segment up, control plane learning?
show l2route evpn mac all ! which MACs are local, which are remote, and from which peer
show bgp l2vpn evpn <mac-or-ip> ! the actual route, its RD, RT and next hop
show ip arp suppression-cache detail ! is ARP being answered locally?
show vpc consistency-parameters vlans ! do both leaves of the pair agree?
The story these tell is usually short. A MAC that is local on one leaf but never appears in BGP on the others points at the local learning or the segment configuration. A route that is present but not imported points at route targets. A VTEP that is missing from show nve peers points at the underlay. Reading the fabric's state like this is only possible because EVPN keeps that state in BGP, where it is visible and consistent, instead of in flood-learned tables.
Numbering is a security control
Every segment needs a VXLAN network identifier (VNI) and route targets, and the fabric will accept any number you type. Two segments that accidentally share an identifier are bridged together, silently, and a mistyped VNI that happens to belong to another segment looks perfectly legitimate on every screen.
The defence is a rule and a machine that checks it. Pick a fixed derivation, for example VNI equals a fixed offset plus the local VLAN number, with route targets derived from the VNI, and then verify it automatically:
- Read the VLAN to VNI map from every leaf on a schedule.
- Confirm every entry obeys the rule.
- Confirm every leaf that should carry the same segments carries identical maps.
- Compare a fingerprint of the whole map against a signed baseline in version control, so an intended change needs a deliberate re-sign with an author, and an unintended one pages an engineer.
We run exactly this check against our fabric every hour. It costs a few seconds of read-only access and turns a class of invisible mistakes into an alarm.
What to ask about your own fabric
- Are your gateways anycast on every leaf, or does one pair of switches own them?
- Is every host dual-homed into a leaf pair, or only the expensive ones?
- Do bonded hosts hash on layer 3 and layer 4, with the switch side matching, so both links actually carry traffic?
- Is there a written rule for VNI and route target numbering, and does anything enforce it?
- Can an engineer show you, with commands like the ones above, exactly where your server lives and how its traffic leaves the rack?
If you would like your servers on a fabric that is built and checked this way, or you want help reading your own, we are glad to help.
Published 22 October 2026.
All field notes