Lab 01 — Multisite Fabric

EVPN VXLAN Multisite

Connecting sites and pods over DCI and data-centre interconnect, with border gateways carrying EVPN routes while VXLAN keeps tenants isolated.

EVPNMultipodMultisiteBGWVXLAN

Overview

This lab joins two independent pods into one multisite fabric. Each pod runs its own spine-leaf underlay with OSPF, and a pair of border gateways (BGWs) at each site exchanges EVPN routes across a DCI link — so a workload in POD 1 can reach POD 2 without either site leaking the other's internal prefixes.

Tenants ride in VXLAN segments end to end: the VNI stays consistent across sites, the BGWs re-originate the routes, and BUM traffic is carried with ingress replication so no multicast is needed in the underlay.

Lab facts

  • PlatformEVE-NG · NX-OS
  • UnderlayOSPF, numbered links
  • OverlayMP-BGP EVPN
  • Data planeVXLAN, ingress replication
  • Sites2 pods · 2 BGWs each

What this lab covers

  • Spine-leaf underlay with OSPF point-to-point links
  • MP-BGP EVPN peering between spines and border gateways
  • DCI interconnect with dedicated BGW pairs per site
  • VXLAN VNIs stretched across sites with consistent mapping
  • Tenant isolation verified with overlapping test subnets
  • Gateway failure drill: losing one BGW per site

Key configuration

Server racks with red cables Data-centre rack aisle

Results & takeaways

End-to-end ping between overlapping tenant subnets in opposite pods succeeded with each tenant fully isolated from the other. Shutting one BGW per site moved traffic to the surviving gateway without dropping the VXLAN overlay, and re-adding the gateway re-synced EVPN routes automatically.

The main lesson: multisite stands or falls on consistent VNI and route-target planning. A small spreadsheet mapping VNIs to tenants, agreed before touching the CLI, saved hours of debugging later.

Related labs

All topologies Start your project