EVPN-VXLAN is the dominant fabric architecture for new data center builds, but the way most resources explain it is either too marketing-fluffy or too RFC-dense for a working engineer to actually grok. This post walks through how EVPN-VXLAN actually works in production, with the packet walk, the route types that matter, and the failure modes the slides skip. By the end, you should be able to explain to a peer how a packet from one host actually finds another host on the other side of the fabric.
The short version. EVPN-VXLAN separates the network into two layers. The underlay is a routed IP fabric, typically with eBGP between every leaf and spine, where every VTEP (the leaf) has IP reachability to every other VTEP. The overlay is BGP EVPN, which carries MAC and IP information about hosts attached to each VTEP. When a packet from host A on leaf 1 needs to reach host B on leaf 4, leaf 1 looks up host B’s MAC, finds it associated with leaf 4’s VTEP IP, encapsulates the original Ethernet frame in a VXLAN header pointing to leaf 4, and sends it across the underlay. Leaf 4 decapsulates and delivers to host B. That is the entire core mechanic, and it is simpler to understand than the slides suggest.
The two layers, briefly
The underlay is a pure IP routed network. Spines are P routers, leaves are PE routers. eBGP runs between every leaf and every spine. The only job of the underlay is to give every VTEP a reachable IP address (typically the leaf’s loopback). The underlay does not know about VLANs, MAC addresses, or tenants. It just routes IP packets.
The overlay is BGP EVPN, which runs as a separate AFI on the same BGP sessions or on dedicated overlay sessions. EVPN carries information about the hosts attached to each VTEP, including their MAC addresses, their IP addresses, the VLAN they belong to (mapped to a VNI in VXLAN), and the EVPN instance and route distinguisher. When a leaf learns about a new MAC locally, it advertises a Type 2 EVPN route to its peers. When a leaf learns about a remote host through EVPN, it programs the local hardware to encapsulate traffic to that host into VXLAN destined for the remote VTEP.
The packet walk
Let us trace a packet from Host A (MAC AA:AA, IP 10.1.1.1, on Leaf 1) to Host B (MAC BB:BB, IP 10.1.1.2, on Leaf 4). Both hosts are in VLAN 100, mapped to VNI 10100.
Step 1. Host A sends an Ethernet frame with source MAC AA:AA, destination MAC BB:BB.
Step 2. Leaf 1 receives the frame on a port in VLAN 100. Leaf 1 looks up MAC BB:BB in its forwarding table. The lookup returns “VTEP at IP 10.0.0.4 (Leaf 4’s loopback), VNI 10100”. This information was learned earlier from a Type 2 EVPN route that Leaf 4 advertised when it saw Host B.
Step 3. Leaf 1 wraps the original Ethernet frame in a VXLAN header. The VXLAN header includes VNI 10100. Leaf 1 then wraps the VXLAN header in an outer IP header with source 10.0.0.1 (Leaf 1’s loopback) and destination 10.0.0.4 (Leaf 4’s loopback), and an outer UDP header with destination port 4789 (the standard VXLAN port). Finally, Leaf 1 wraps everything in an outer Ethernet header for transmission to whichever spine is the next hop.
Step 4. The packet traverses the underlay. Spines route it based on the outer IP header (destination 10.0.0.4) using ECMP. The packet might go through Spine 1 or Spine 2 depending on hash. The spines do not know about Host A, Host B, VLAN 100, or VNI 10100. They just route IP.
Step 5. Leaf 4 receives the packet, sees its own loopback as the destination, decapsulates the outer Ethernet, IP, UDP, and VXLAN headers. The original Ethernet frame is exposed. Leaf 4 reads the VNI (10100), maps it to its local VLAN 100, and forwards the original frame out the port where Host B lives.
Step 6. Host B receives the original frame as if it were on the same Layer 2 segment as Host A, even though they are physically on different leaves connected only by an IP fabric.
That is the entire mechanic. Everything else in EVPN is bookkeeping to make this work at scale, support multi-tenancy, handle failures, and add Layer 3 routing.
The five EVPN route types
EVPN defines several route types that carry different information across the fabric. The five most relevant in production:
Type 1, Ethernet Auto-Discovery. Used for multi-homed devices. Helps with mass withdraw when an ESI link goes down. Less relevant in single-homed designs.
Type 2, MAC-IP Advertisement. The workhorse. Carries a MAC address, optionally an IP address, the VNI, and the originating VTEP. Every host attached to the fabric generates one of these. This is what populates the forwarding tables on remote leaves.
Type 3, Inclusive Multicast Ethernet Tag. Used to build the BUM (broadcast, unknown unicast, multicast) replication list. When a host sends an ARP that needs to be flooded, Type 3 routes tell each leaf which other leaves are interested.
Type 4, Ethernet Segment Route. Used for designated forwarder election in multi-homing scenarios.
Type 5, IP Prefix Route. Used for inter-subnet routing within the fabric. When a leaf has hosts in different subnets and needs to advertise the prefix to other leaves, Type 5 carries that.
VTEP, ESI, and other terms
A few terms that come up constantly. VTEP (VXLAN Tunnel Endpoint) is the function that encapsulates and decapsulates VXLAN. In a typical fabric, every leaf is a VTEP. VNI (VXLAN Network Identifier) is a 24-bit value that identifies which virtual network a packet belongs to. Maps to a VLAN on the leaf. ESI (Ethernet Segment Identifier) is used when a single host or device is multi-homed across multiple leaves, identifying that segment uniquely. RD (Route Distinguisher) makes EVPN routes unique per VRF/EVI. RT (Route Target) controls which EVPN routes are imported into which EVPN instance.
What the marketing skips
EVPN-VXLAN works beautifully when configured correctly. It also has failure modes that vendor decks omit.
MAC mobility events cascade. When a host moves from one leaf to another, EVPN tracks this with a mobility sequence number. A misbehaving host that constantly moves (think a flapping LACP bond) generates EVPN updates that ripple through the entire fabric. Performance degrades and engineers spend hours hunting for “fabric instability” that is actually one bad host.
Multi-vendor interop has real edge cases. Cisco, Arista, Juniper, and Nokia all implement EVPN per the RFC, but each has slight differences in how they handle ESI labels, MAC mobility timers, and route-target derivation. Multi-vendor fabrics work, but the edge cases require documentation.
BUM traffic still uses replication. Despite the routed underlay, broadcast and multicast traffic in EVPN is replicated, either via ingress replication (each leaf replicates per destination) or via underlay multicast. Both have scaling limits at fabric size.
Convergence depends on BFD tuning. Sub-second convergence requires BFD with appropriate timers. Tuning too aggressively burns CPU. Tuning too loosely loses the convergence advantage. Find the platform sweet spot.
When to use EVPN-VXLAN
EVPN is the right answer when you need multi-tenancy at scale, scale-out east-west traffic, multi-site Layer 2 mobility, or operational consistency across many leaves. It is the wrong answer for a small single-site network with limited tenancy and a team that does not want to learn BGP. Pick deliberately based on environment, not because vendors are pushing it.
FAQ
Is EVPN-VXLAN the same as Cisco ACI?
No. ACI uses VXLAN encapsulation but a different control plane (APIC and OpFlex). EVPN-VXLAN is the open standard, ACI is Cisco’s proprietary equivalent. Both can coexist with care.
Can I run EVPN-VXLAN over the WAN?
Yes, with appropriate underlay. EVPN was originally designed for service provider WAN, and it works well between data center sites with sufficient underlay capacity.
How is EVPN different from MPLS L2VPN?
EVPN uses BGP for the control plane and supports multi-homing, mass withdraw, and MAC learning in the control plane (not data plane). Traditional MPLS L2VPN learned MACs in the data plane via flooding. EVPN is a generational improvement.
Related posts
Designing or operating an EVPN fabric
EVPN-VXLAN rewards good design and punishes shortcuts. Our data center practice has designed and operated EVPN fabrics across Western Canada for service providers and large enterprises. If you are evaluating EVPN for your environment, we will help you make the right call.
Last verified April 2026 by the aaanetworkx data center practice.
