EVPN-VXLAN is now the standard for enterprise and hyperscaler data centers in 2026. With Cisco DCNM reaching end-of-support in April 2026, thousands of enterprises are migrating from legacy VLAN-based designs to BGP EVPN with VXLAN encapsulation. This guide covers the full stack: fabric design, IRB models, multi-site interconnect, and multi-vendor interoperability.
Quick Comparison: Data Center Fabric Options in 2026
| Design | Control Plane | Data Plane | Multi-Tenancy | Multi-Vendor | Scale |
|---|---|---|---|---|---|
| EVPN-VXLAN (modern) | BGP EVPN | VXLAN | ✅ Native | ✅ Standard (RFC 7432) | 1000s of leaves |
| Legacy 3-tier (VLAN+STP) | STP/MSTP | Ethernet | ❌ VLAN-limited (4094) | ✅ Basic | 100s of switches |
| OTV (Cisco DCI) | IS-IS | MAC-in-IP | ❌ Limited | ❌ Cisco-only | Small |
| VPLS (SP DCI) | LDP or BGP | MPLS | ⚠️ Via VFI | ⚠️ Complex | Medium |
| Pure L3 Clos | eBGP | IP | ❌ None (L3-only) | ✅ Standard | Very high |
Bottom line: EVPN-VXLAN is the modern standard. It replaced spanning-tree for scale, replaced OTV/VPLS for DCI, and added native multi-tenancy that no legacy design offered. The question is no longer "should we use EVPN-VXLAN" but "how do we validate designs and migrations safely." NetPilot is the fastest way to spin up a working multi-vendor EVPN-VXLAN fabric (Arista, Cisco, Juniper, Nokia) for testing designs, rehearsing migrations, and validating multi-vendor interop — 2 minutes from prompt to working CLI access.
What Is EVPN-VXLAN?
EVPN (Ethernet VPN) is a BGP-based control plane (RFC 7432) that distributes MAC addresses, IP bindings, and multi-tenancy routing information across a network. VXLAN (Virtual eXtensible LAN) is a MAC-in-UDP encapsulation that tunnels Layer 2 traffic over Layer 3 infrastructure — supporting 16 million segments (vs 4094 for traditional VLANs).
Together they form a fabric where:
- Leaves host workloads and act as VTEPs (VXLAN Tunnel Endpoints)
- Spines provide L3 reachability between leaves (BGP underlay)
- BGP EVPN signals MAC-to-VTEP bindings, eliminating the need for flood-and-learn
- VXLAN encapsulates tenant traffic for transport across the L3 underlay
The result: Layer 2 segments stretched across any number of leaves without spanning-tree, with strict multi-tenancy, and with multi-vendor interoperability.
Leaf-Spine Fabric Design Principles
Every EVPN-VXLAN fabric is built on a Clos topology (leaf-spine):
- Every leaf connects to every spine (non-blocking by design)
- No leaf-to-leaf direct links
- No spine-to-spine direct links
- ECMP provides equal-cost paths between any two leaves (typically 2-16 spines)
Typical production sizing:
| Fabric size | Leaves | Spines | ECMP paths |
|---|---|---|---|
| Small | 4-16 | 2 | 2-way |
| Medium | 16-64 | 4-8 | 4-8 way |
| Large | 64-256 | 8-16 | 8-16 way |
| Hyperscale | 256+ | 16-32 | 16-32 way |
The underlay is almost always eBGP IPv4 (per RFC 7938), because it scales better than any IGP for thousands of leaves, has strong policy controls, and terminates ECMP at the leaf.
Symmetric vs Asymmetric IRB: The Critical Choice
IRB (Integrated Routing and Bridging) refers to how the fabric routes between VNIs (Virtual Network Identifiers).
Asymmetric IRB
- Every leaf has an SVI for every tenant VLAN
- Routing happens on the ingress leaf
- EVPN Type-2 routes (MAC+IP) carry all information
- No L3 VNI needed
Pros: Simpler config, no L3 VNI concept Cons: Every leaf must carry every tenant's full VLAN set. Doesn't scale past ~10-15 tenants.
Symmetric IRB
- Each tenant has a dedicated L3 VNI
- Ingress leaf does ingress bridging, egress leaf does egress bridging, routing happens via the L3 VNI between them
- EVPN Type-2 routes (MAC+IP) and Type-5 routes (IP prefix) both used
- Cleaner VRF separation
Pros: Each leaf only carries VLANs for local tenants. Scales to hundreds of tenants. Cons: Slightly more complex config. Extra L3 VNI per tenant.
Rule of thumb: Symmetric IRB for most new designs. Asymmetric only if you have fewer than 10 tenants and want config simplicity.
See it in action: Symmetric IRB prompt and Asymmetric IRB prompt — ready-to-run.
Multi-Tenancy: The Killer Feature
EVPN-VXLAN provides native multi-tenancy through VRFs tied to L3 VNIs and VNI-to-VRF mapping. Three isolated tenants with different route-targets cannot leak routes between each other without explicit policy.
Typical tenant design:
Tenant A:
Route-Target: 100:100
L3 VNI: 50100
VLANs: VNI 10101, VNI 10102
Tenant B:
Route-Target: 200:200
L3 VNI: 50200
VLANs: VNI 10201, VNI 10202This isolation is controlplane-enforced — there's no way for Tenant A's broadcast to reach Tenant B's switches. Compare that to VLAN-based isolation, where a misconfigured trunk port can break the tenant boundary instantly.
See it: Multi-Tenant VRFs with EVPN prompt.
Multi-Site DCI: The OTV Replacement
The hardest legacy DCI problem: how do you stretch Layer 2 between two data centers without creating a spanning-tree loop or flooding BUM (broadcast/unknown-unicast/multicast) traffic unnecessarily?
Legacy answers:
- OTV (Cisco-only) — reaches EOS April 2026
- VPLS (SP-grade, complex)
- Dark fiber L2 extension (fragile, no BUM control)
Modern answer: EVPN Multi-Site
- Each data center runs its own EVPN-VXLAN fabric independently
- Border gateways at each site re-originate EVPN routes with local next-hop
- BUM suppression prevents cross-site flooding
- Multiple sites can be meshed or hub-spoke
See it: EVPN-VXLAN Multi-Site DCI prompt.
For enterprises migrating off OTV before April 2026, the OTV-to-EVPN Migration prompt provides a parallel-run validation pattern.
Multi-Vendor Interoperability (Where Things Get Real)
RFC 7432 and RFC 8365 standardize EVPN-VXLAN across vendors. In theory, Cisco, Arista, Juniper, and Nokia all interoperate. In practice, every vendor implements details slightly differently:
| Vendor | EVPN Maturity | Notable Quirks |
|---|---|---|
| Arista EOS | ✅ Production-hardened | Default implementation, reference |
| Cisco NX-OS | ✅ Production-hardened | RT auto-derivation differs; requires explicit mapping |
| Cisco IOS-XR | ✅ SP-grade | Used in large-scale fabrics, explicit ESI |
| Juniper Junos | ✅ Production-hardened | EVPN started in Junos, strong SP heritage |
| Nokia SR Linux | ✅ Growing | Clean implementation, newer |
| FRR | ⚠️ Improving | Open-source, good for labs and hyperscalers |
The interoperability gotchas are almost always in:
- Route-target auto-derivation (when each vendor picks a different default RT for the same VNI)
- ESI (Ethernet Segment Identifier) handling in multi-homing
- BUM replication tree selection (ingress replication vs multicast)
See multi-vendor in practice: Cisco + Arista EVPN-VXLAN Interop prompt.
AI Cluster Networking: The 2026 Twist
The biggest new EVPN-VXLAN use case in 2026 is AI training cluster fabrics. GPUs doing gradient synchronization need lossless Ethernet (for RoCEv2), very low latency, and ECMP hashing that doesn't polarize on elephant flows.
Requirements:
- PFC (Priority Flow Control) for lossless behavior on specific traffic classes
- ECN (Explicit Congestion Notification) to signal back to senders before drops
- ECMP with entropy labels to balance GPU-to-GPU traffic across spines
- Buffer tuning on spine and leaf queues
Most AI cluster fabrics today are pure L3 Clos (no EVPN overlay needed) but overlay support is growing as multi-tenant AI inference hosting becomes a business.
See an AI fabric example: AI Cluster RoCEv2 Fabric prompt.
FAQ
What's the difference between EVPN-VXLAN and legacy VLAN-based fabrics?
Legacy VLAN fabrics rely on spanning-tree for loop prevention, limiting scale to a few hundred switches. EVPN-VXLAN uses a BGP control plane for MAC learning and Layer 3 underlay with ECMP — scaling to thousands of leaves without spanning-tree.
Should I use symmetric or asymmetric IRB?
Use symmetric IRB for most new designs. It scales better because each leaf only carries VLANs for its locally-attached tenants. Asymmetric IRB is simpler but every leaf must carry every tenant's full VLAN set — limiting you to small tenant counts.
Does EVPN-VXLAN work across vendors?
Yes, RFC 7432 and RFC 8365 standardize the protocol. Cisco, Arista, Juniper, and Nokia all implement it. However, vendor differences in route-target auto-derivation, ESI handling, and BUM replication require lab testing before production deployment.
What's the replacement for OTV as DCI?
EVPN Multi-Site. It provides the same stretched-Layer-2 capability across data centers, plus BUM suppression, selective re-origination of routes at border gateways, and multi-vendor support. With DCNM reaching EOS in April 2026, every OTV deployment needs a migration plan.
Can I run EVPN-VXLAN without a BGP underlay?
Technically yes — you could run OSPF/IS-IS underlay. In practice, eBGP underlay (per RFC 7938) is the industry standard because it scales to thousands of leaves, handles multi-path naturally, and gives policy controls for leaf isolation.
How do I test EVPN-VXLAN designs before production?
Either deploy physical lab hardware (expensive, limited to 4-8 devices) or use a virtual lab environment. NetPilot deploys multi-vendor EVPN-VXLAN topologies to isolated cloud infrastructure in 2 minutes using real device CLIs (Arista cEOS, Cisco NX-OS alternatives, Nokia SR Linux) — with ready-made prompts for symmetric IRB, multi-site DCI, and multi-tenant VRFs.
Which Should You Build First?
- Never built EVPN-VXLAN before? Start with the Clos Fabric with BGP Underlay (pure L3, no overlay) to understand the foundation.
- Enterprise data center? Build Leaf-Spine EVPN-VXLAN Symmetric IRB — the production standard.
- Multi-site enterprise? Add EVPN-VXLAN Multi-Site DCI.
- Multi-tenant hosting provider? Build Multi-Tenant VRFs with EVPN.
- AI cluster? Build the AI Cluster RoCEv2 Fabric.
- Migrating off OTV? Run the OTV-to-EVPN Migration lab in parallel with your production topology.
Ready to build an EVPN-VXLAN lab? Try NetPilot — describe your fabric in plain English and deploy a working multi-vendor EVPN-VXLAN topology in 2 minutes. Or explore the full example-prompts library for copy-paste-ready lab scenarios.