EVPN-VXLAN · BGP leaf-spine · 400G / 800G

The complete leaf-spine data center fabric, on open switches.

IP Infusion delivers a complete EVPN-VXLAN leaf-spine data center fabric: 400G and 800G switches running OcNOS-DC, pre-loaded and supported under one contract. You add capacity by adding switches, a server keeps the same gateway on any leaf, and every tenant stays isolated, with a distributed anycast gateway, EVPN multihoming, a BGP underlay, and multi-tenant VRF isolation on open hardware.

Delivered and supported as one system

One validated switch, software, and support contract.

IP Infusion qualifies the switch and OcNOS-DC together and supports them under one contract, so the fabric you design is the fabric that ships. Every claim below maps to a validated platform in the hardware list and a supported feature in the matrix.

Validated hardware

17 validated data center platforms

Every leaf, spine, and border switch is lab-qualified per ASIC stepping with OcNOS-DC pre-loaded, from 100G access leaves to 800G Tomahawk 5 spines.

Feature depth

Verifiable in the feature matrix

EVPN-VXLAN, the anycast gateway, multihoming, the BGP-unnumbered underlay, and multi-tenant VNIs are each mapped to the platforms that support them.

One contract

Switch, software, and RMA together

One team owns the software, switch, and RMA, and you still refresh the hardware and OcNOS-DC on independent cycles.

The reference architecture

How the fabric is built, and what each tier gives you.

Servers attach to leaves, leaves connect to every spine, and a border tier reaches the WAN and the second site. The split of work across these tiers is what lets you add capacity to one tier without touching the others, and lets a server keep the same gateway wherever it lands.

DC fabric topology: leaf-spine EVPN-VXLAN with VTEP leaves, eBGP ECMP uplinks, and a border leaf for external connectivity and EVPN route reflection
DC Fabric: EVPN-VXLAN leaf-spine with VTEP leaves, eBGP ECMP, and a border leaf for external connectivity.

The same OcNOS-DC image runs every tier, so you size and license per role and operate one software baseline across the fabric.

Where servers attach

Leaf: every rack's on-ramp

The leaf terminates VXLAN and hosts the distributed anycast gateway, so a server sees the same gateway IP and MAC on any leaf. Move or add a workload and it keeps its default route with no re-addressing.

You add server capacity by adding leaves, on a Trident 4 400G switch.

Where you add width

Spine: bandwidth for the whole fabric

The spine carries the BGP-unnumbered underlay, reflects EVPN routes, and spreads traffic with overlay ECMP. It holds no tunnel endpoints, so adding a spine adds bandwidth to the whole fabric.

You scale wider by adding spines, without re-cabling the leaves.

Where the fabric exits

Border leaf: the fabric's controlled exit

The border leaf runs the EVPN Layer 3 gateway and advertises each tenant's IP prefixes outward, VRF by VRF. It is your one controlled handoff to the WAN and to the second site.

It is also where two fabrics stitch together for the coherent interconnect.

What keeps cabling simple

Underlay: plug-and-peer cabling

Every leaf-spine link runs BGP-unnumbered with extended next-hop encoding, so a link peers with no per-interface IP to assign or track. Cabling a new link is plug-and-peer.

That is what makes the fabric quick to cable and quick to grow.

EVPN-VXLAN engineering

How the switch builds the fabric.

The fabric grows by adding switches, not by re-architecting, and EVPN-VXLAN is what makes that work. VXLAN tunnels tenant traffic between leaves over the IP underlay, and EVPN advertises where every MAC, host, and prefix lives, so the switch forwards from a learned control plane instead of flooding to find a host.

RFC 7432 / 8365

EVPN advertises MAC, IP, and prefixes

The leaf runs the Layer 2 EVPN for VXLAN control plane and the prefix route for EVPN IRB, so EVPN carries MAC and IP host routes and IP prefixes across the fabric and each leaf forwards from what it has learned.

Anycast GW

Distributed anycast gateway

Every leaf presents the same gateway IP and MAC for a subnet, using multiple IP addresses on the IRB interface for the anycast gateway, so a server is always one hop from its gateway no matter which leaf it sits behind.

ESI-LAG

EVPN multihoming, active-active

Layer 2 EVPN multihoming for VXLAN attaches a server to two or more leaves in active-active mode over an Ethernet Segment. Both links forward, and there is no MLAG peer-link between the leaves.

RFC 7938

BGP-unnumbered underlay

Every leaf-spine link runs VXLAN EVPN with BGP unnumbered using extended next-hop encoding. A link peers without a per-interface IP address, which keeps the underlay simple to cable and grow.

Multi-tenant

VRF isolation over VNIs

Each tenant lives in its own VRF over its own VNIs, and inter-VRF route leaking over EVPN-VXLAN passes only the prefixes you permit, so isolation is the default and any sharing between tenants is explicit.

ECMP + RR

Overlay ECMP and route reflection

Overlay equal-cost multipath spreads traffic across every spine, and EVPN route reflection in the fabric passes routes between leaves without a full mesh, so the fabric scales wider by adding spines.

Automation and operations

From bare switch to production leaf in minutes.

A new switch boots, pulls its configuration, and joins the fabric with no console session. From there you operate the fabric as code, with streaming telemetry and model-driven configuration on every platform.

Onboarding

ZTP at boot

A switch pulls its image and configuration through Zero Touch Provisioning, so it goes from the box to a production leaf without a console session.

Telemetry

gNMI streaming

gNMI streams telemetry to your collector, dial-in and dial-out, so leaf and spine state is a live feed instead of a poll.

Config as code

NETCONF, OpenConfig, Ansible

NETCONF and OpenConfig models with Ansible let you push and verify EVPN and VXLAN state as code, consistently across the fabric.

Visibility

sFlow, BFD, graceful restart

sFlow samples traffic for visibility, BFD detects a failure fast, and BGP graceful restart keeps the fabric forwarding while a neighbor reconverges.

Data center interconnect

Interconnect two fabrics over coherent DCI.

When an operator runs two data centers, tenants in one need to reach tenants in the other, and the fabric extends across both sites as one network. The border leaf in each fabric stitches the two VXLAN Layer 3 domains, each fabric advertises its tenant IP prefixes to the other over EVPN, and a 400G OpenZR+ coherent link carries the traffic between the sites, using the same routed-optical technique already proven on service provider routers.

The stitch

Border leaf stitches the L3 domains

The EVPN Layer 3 gateway on each border leaf performs VXLAN Layer 3 stitching, so one fabric's VXLAN domain hands off to the other at Layer 3 rather than bridging one flat domain across the WAN.

The handoff

Type-5 prefixes, per-tenant

Each fabric advertises its tenant IP prefixes to the other as EVPN IP-prefix routes, reflected by the route servers, and inter-VRF route leaking keeps each tenant's VRF isolated across both sites.

The transport

400G ZR+ coherent, no transponder

A ZR+ capable switch seats a 400G OpenZR+ coherent optic directly in a faceplate port and lights the wavelength, with no separate transponder shelf. The same 400G coherent DCI runs on data center switches like the Edgecore AS9726-32DB and on the service provider routers already deployed for interconnect, and the 800G Tomahawk 5 fabric scales the port capacity behind it.

See it end to end

Switch the view between one site's fabric, the coherent DCI stitch between sites, and the remote fabric.

Two-site data center interconnect selector Two EVPN-VXLAN leaf-spine fabrics, Site A on the left and Site B on the right, each with two leaves and a spine and a border leaf, joined in the center by a 400G OpenZR+ coherent link between the two border leaves. Select a view to highlight one site's fabric, the interconnect stitch, or the remote fabric. Leaf A1 VTEP Leaf A2 VTEP Spine A underlay RR SITE A Border A L3 gateway Border B L3 gateway 400G ZR+ coherent EVPN Type-5 handoff, VXLAN L3 stitching Spine B underlay RR Leaf B1 VTEP Leaf B2 VTEP SITE B

Coherent DCI stitch. The two border leaves stitch the fabrics at Layer 3 and light a 400G OpenZR+ coherent link between the sites. Each fabric advertises its tenant IP prefixes to the other as EVPN Type-5 routes, and per-tenant VRF isolation is preserved across both sites.

Platform sizing

Which validated switch for which role.

IP Infusion delivers the fabric on 17 validated data center platforms from Edgecore and UfiSpace, each lab-qualified per ASIC stepping with OcNOS-DC pre-loaded. Leaves size on port count and the anycast gateway; spines size on fabric width; the interconnect leaf sizes on the coherent optic.

Validated data center switches by fabric role. Last verified: Jul 2026.
Role Validated switch Silicon and capacity Why it fits the role
Leaf (400G) Edgecore AS9726-32DB / UfiSpace S9300-32D Broadcom Trident 4, 12.8 Tbps, 400G The VTEP tier: server-facing ports, the distributed anycast gateway, and EVPN multihoming.
Spine (400G) Edgecore AS9736-64D Broadcom Tomahawk 4, 25.6 Tbps, 400G Underlay ECMP and EVPN route reflection, no VTEPs, sized for fabric width.
Spine / super-spine (800G) Edgecore AIS800-64D / UfiSpace S9321-64E Broadcom Tomahawk 5, 51.2 Tbps, 800G 800G scale-out for the largest fabrics. The AIS800-64D uses QSFP-DD800 optics.
Interconnect leaf (400G coherent) Edgecore AS9726-32DB Broadcom Trident 4, 12.8 Tbps, 32×400G, 400G ZR+ coherent Seats a 400G OpenZR+ coherent pluggable in a QSFP-DD port and lights the interconnect wavelength directly, with no external transponder.
100G leaf / ToR Edgecore AS7726-32X / UfiSpace S9110-32X Broadcom Trident 3, 3.2 Tbps, 100G Access-tier leaves for 25G and 100G server racks.

17 validated data center platforms. See every validated platform, including the rest of the portfolio, in the hardware compatibility list, and match features to hardware in the feature matrix.

How to size the fabric

  • Leaf tier. Put the leaves on 400G Trident 4 for the VTEP, the anycast gateway, and EVPN multihoming, or on a 100G Trident 3 leaf for 25G and 100G server racks.
  • Spine tier. Put the spines on 400G Tomahawk 4, or on 800G Tomahawk 5 when the fabric needs to scale wider, and add spines rather than touching the leaves.
  • Interconnect leaf. Use the AS9726-32DB with 400G OpenZR+ coherent pluggables in its QSFP-DD ports when the fabric extends to a second site, so the interconnect leaf lights the wavelength directly.
  • One contract. IP Infusion validates and supports every role as one system, and the switch and OcNOS-DC refresh on independent cycles.
Config: leaf VTEP with anycast gateway

Configure a leaf VTEP.

Each leaf terminates VXLAN tunnels, hosts the distributed anycast gateway, and runs the EVPN address family in BGP. Below is a representative OcNOS-DC leaf configuration: VXLAN with integrated routing and bridging, a tenant with its layer 3 VNI and bridge domain, the distributed anycast gateway with a shared MAC, the VNI to tenant mapping, and EVPN under BGP.

OcNOS-DC · leaf VTEP
! Leaf VTEP: VXLAN overlay, distributed anycast gateway, EVPN in BGP
configure terminal
nvo vxlan enable
nvo vxlan irb
evpn irb-forwarding anycast-gateway-mac 0000.0000.1111
ip vrf tenant1
 l3vni 5010
mac vrf tenant1_l2
 rd 10.0.0.1:10
 route-target both 100:10
interface irb10
 ip vrf forwarding tenant1
 ip address 10.10.10.1/24
 evpn irb-if-forwarding anycast-gateway-mac
nvo vxlan id 10 ingress-replication inner-vid-disabled vxlan host-reachability-protocol evpn-bgp tenant1_l2 evpn irb10
nvo vxlan vtep-ip-global 10.0.0.1
router bgp 65001
 neighbor 10.0.1.1 remote-as 65000
 address-family l2vpn evpn
  neighbor 10.0.1.1 activate

What each line does

  1. nvo vxlan enable and nvo vxlan irb turn on VXLAN and integrated routing and bridging, so the leaf both switches inside a subnet and routes between subnets over the fabric.
  2. evpn irb-forwarding anycast-gateway-mac 0000.0000.1111 sets one shared gateway MAC for the whole fabric, so every leaf answers as the same default gateway.
  3. ip vrf tenant1 with l3vni 5010 gives the tenant its own routing table and the layer 3 VNI that carries routed traffic between subnets across the fabric.
  4. mac vrf tenant1_l2 with its rd and route-target both gives the tenant bridge domain a route distinguisher and import and export targets, so EVPN keeps each tenant's MAC and IP routes separate.
  5. interface irb10 is the tenant gateway: ip vrf forwarding tenant1 binds it to the tenant table, ip address sets the gateway IP, and evpn irb-if-forwarding anycast-gateway-mac applies the shared anycast MAC to this interface.
  6. The nvo vxlan id 10 line maps VNI 10 to the tenant, uses ingress replication for broadcast and multicast traffic, and sets host-reachability-protocol evpn-bgp so BGP EVPN learns host reachability.
  7. nvo vxlan vtep-ip-global 10.0.0.1 sets the tunnel-endpoint address, a loopback, that identifies this leaf in the fabric.
  8. router bgp 65001 with neighbor 10.0.1.1 remote-as 65000 forms the session to the spine, and the address-family l2vpn evpn block activates EVPN so the leaf advertises and learns MAC, IP, and prefix routes.

These are OcNOS-DC VXLAN and EVPN commands from the OcNOS-DC configuration guide, shown with example VNIs, VRF names, and addresses rather than copied from one device. Confirm the exact IDs, route targets, and addresses for your fabric against the OcNOS-DC VXLAN and EVPN configuration guide at documentation.ipinfusion.com.

Open vs proprietary

Open fabric switch vs a proprietary data center switch.

Against Arista or Cisco, the fabric question is whether an open switch runs EVPN-VXLAN leaf-spine as completely. OcNOS-DC does, on merchant silicon the operator can buy from more than one vendor, all under a single support contract.

Open fabric switch on OcNOS-DC versus proprietary data center platforms. Last verified: Jul 2026.
Fabric capability Open switch (OcNOS-DC) Proprietary (Arista EOS / Cisco NX-OS / Juniper Junos)
EVPN-VXLAN leaf-spine fabric details →
Distributed anycast gateway
EVPN multihoming (ESI-LAG, no MLAG dependency)
BGP-unnumbered underlay details →
Multi-tenant VRF and VNI isolation
ZTP, gNMI, NETCONF and OpenConfig
800G on Tomahawk 5
Hardware sourcing Open merchant silicon from multiple vendors Single-vendor switch
Delivery and support Complete switch, one support contract, switch and software refresh separately Vendor-bundled

Arista, EOS, Cisco, NX-OS, Nexus, Juniper, and Junos are trademarks of their respective owners. IP Infusion is not affiliated with and does not endorse these vendors; the comparison reflects OcNOS-DC capabilities verifiable in the feature matrix.

Before you evaluate

Questions about the data center fabric.

An EVPN-VXLAN leaf-spine data center fabric is a scale-out network that grows by adding switches. Every leaf is a VXLAN tunnel endpoint, BGP carries the underlay between leaf and spine, and EVPN advertises MAC and IP host routes and IP prefixes, so the fabric forwards from a learned control plane instead of flooding. IP Infusion delivers it as one system: the switch, OcNOS-DC pre-loaded, and one support contract, with a distributed anycast gateway, EVPN multihoming, and multi-tenant VRF isolation.
Each tenant gets its own set of VXLAN network identifiers (VNIs): Layer 2 VNIs carry bridged traffic and Layer 3 VNIs carry routed traffic inside a per-tenant VRF. Because traffic is encapsulated per VNI and routed inside a VRF, one tenant cannot see another tenant on the shared fabric. Where two tenants need to reach each other, inter-VRF route leaking over EVPN-VXLAN passes only the specific prefixes you permit, so isolation stays the default and sharing is explicit.
EVPN multihoming lets a server attach to two or more leaves at once in active-active mode using an Ethernet Segment Identifier (ESI-LAG), so both links forward traffic and a leaf failure is transparent. It is signaled entirely in the EVPN control plane, so there is no dedicated peer-link and no proprietary pairing between the two leaves. That is the difference from MLAG, which pairs exactly two switches over a peer-link. OcNOS-DC supports both, so a design that wants classic dual-homing can still use MLAG.
The border leaf in each fabric stitches the two VXLAN Layer 3 domains together, and each fabric advertises its tenant IP prefixes to the other as EVPN IP-prefix routes, with per-tenant VRF isolation preserved across the sites. For the transport, a 400G OpenZR+ coherent optic in a ZR+ capable switch, such as the Edgecore AS9726-32DB or a service provider router already deployed for interconnect, lights the wavelength directly in a QSFP-DD port, so there is no separate transponder. The 800G Tomahawk 5 switches carry the fabric behind it. For the optics deep-dive see the routed-optical solution, and for the coherent reach math see the coherent DCI technology page.
Yes, for an EVPN-VXLAN leaf-spine fabric. OcNOS-DC runs the same fabric capabilities on merchant-silicon switches: EVPN-VXLAN with a distributed anycast gateway, EVPN multihoming, a BGP-unnumbered underlay, multi-tenant VNIs, and ZTP with gNMI and NETCONF for operations. IP Infusion delivers the switch, the software, and the support as one system under a single contract, and you source hardware from more than one open-hardware vendor and refresh the switch and the software on independent cycles.
A new switch boots and pulls its configuration through Zero Touch Provisioning, so a switch goes from the box to a production leaf without a console session. From there the fabric is operated with streaming telemetry over gNMI, NETCONF and OpenConfig models, and Ansible, and the same models let you push and verify EVPN and VXLAN state as code. IP Infusion ships the switch with OcNOS-DC pre-loaded and a validated baseline, so the Day 0 image is consistent across every leaf and spine.
Evaluate the fabric

See the open data center fabric.

See how IP Infusion delivers the EVPN-VXLAN leaf-spine fabric as one system, or contact us to map your leaves, spines, and interconnect to the right validated platforms.