Cloud-Managed EVPN Fabric Overview
Cisco Cloud-Managed Fabric provides a cloud-first campus architecture built on standards-based BGP EVPN and VXLAN. Use Meraki Dashboard to define, deploy, monitor, and operate the fabric.
The architecture separates the physical Layer 3 Underlay from the logical EVPN VXLAN Overlay. OSPFv2 provides IP reachability between fabric nodes, Multiprotocol BGP EVPN distributes MAC, IP, and IP-prefix reachability, and VXLAN carries segmented Layer 2 and Layer 3 services between VXLAN tunnel endpoints (VTEPs).
Meraki Dashboard automates fabric workflows and provides a unified operational view of device roles, virtual routing and forwarding instances (VRFs), Underlay and Overlay subnets, BGP peers, VXLAN tunnels, and fabric health.
Fabric fundamentals
An EVPN VXLAN fabric separates the physical transport network from the logical services delivered to endpoints.
| Component | Purpose |
|---|---|
| Underlay | The physical Layer 3 network that provides IP reachability between fabric nodes. Cloud-Managed Fabric uses OSPFv2 for Underlay unicast routing. |
| Overlay | The logical Layer 2 and Layer 3 services carried across the Underlay. VXLAN Network Identifiers (VNIs) provide segmentation and tenant isolation. |
| Control plane | Multiprotocol BGP with the EVPN address family distributes MAC and IP reachability. Common EVPN routes include Type 2 MAC/IP advertisements, Type 3 Inclusive Multicast Ethernet Tag routes, and Type 5 IP-prefix routes. |
| Data plane | VXLAN encapsulates Ethernet frames in UDP/IP packets. VXLAN tunnel endpoints (VTEPs) encapsulate and decapsulate traffic and support symmetric integrated routing and bridging (IRB). |
Key protocols and capabilities include:
-
BGP EVPN for Overlay route exchange
-
VXLAN for data-plane encapsulation
-
OSPFv2 for Underlay reachability
-
Cisco ISE or Cisco Access Manager integration for Adaptive Policy, Security Group Tags (SGTs), and group policies
Fabric roles
| Role | Function |
|---|---|
| Border | Connects the fabric to external networks, such as a WAN, DMZ, or data center. A Border can provide Layer 3 handoffs to external networks. |
| Spine | Provides the resilient IP backbone between Leaf switches. Spines typically act as BGP route reflectors for EVPN routes and transport VXLAN-encapsulated traffic. |
| Leaf | Connects endpoints or non-fabric access switches. Leaves operate as VTEPs and provide Layer 2 bridging, Layer 3 IRB, ARP suppression, and host mobility. |
Catalyst 9300 and Catalyst 9500 Series switches can combine roles. Supported roles currently include Spine, Leaf, Border, and Border-Spine.
Dependencies and requirements
Wired platform support
| Network layer | Supported platform | Minimum software | Fabric role |
|---|---|---|---|
| Access (Cisco cloud-managed switching) | Cisco 9350; Catalyst 9300, 9300L, 9300LM, and 9300X; Catalyst 9200 and Catalyst 9200L; Catalyst 9200CX | IOS XE 17.18.2 | Layer 2, outside the fabric |
| Access (Meraki switching) | MS390, MS130, MS150 | MS 17 or later | Layer 2, outside the fabric |
| Distribution | Catalyst 9500 High Performance, Catalyst 9300X | IOS XE 17.18.2 or later | Leaf |
| Core | Catalyst 9500 High Performance, Catalyst 9300X | IOS XE 17.18.2 or later | Spine or Border-Spine |
| Network edge (WAN, DMZ, and other external networks) | Catalyst 9500 High Performance; Catalyst 9300X | IOS XE 17.18.2 or later | Border |
Licensing: Cloud Switching Advanced licensing is required for fabric and Adaptive Policy features.
Wireless platform support
| Vendor | Supported access points | Operational mode | Forwarding mode |
|---|---|---|---|
| Cisco | MR and CW Access Points | Cloud-managed | Distributed |
Recommended platforms
-
Spine: Catalyst 9500-24Y4C, 9500-48Y4C, 9500-32C, Catalyst 9300X models
-
Border: Catalyst 9500-24Y4C, 9500-48Y4C, 9500-32C, Catalyst 9300X models
-
Leaf: Catalyst 9500-24Y4C, 9500-48Y4C, 9500-32C Standalone/EVPN Multi-Homing, or Catalyst 9300X models with StackWise or EVPN Multi-Homing support
-
Access: Cisco or Meraki Layer 2 switches that support SGT/TrustSec, including Cisco 9350; Catalyst 9300, 9300L, 9300LM, and 9300X; Catalyst 9200, Catalyst 9200L, and Catalyst 9200CX; and the MS390, MS150, and MS130 families
-
Wireless: MR and CW Access Points
Software and service requirements
| Requirement | Minimum or required value |
|---|---|
| Switch software | IOS XE 17.18.2 or later |
| Licensing | Cloud Switching Advanced |
| Management | Meraki Dashboard and internet connectivity over TCP 443. See Help > Firewall info in Dashboard for the current destination list |
| Identity and policy | Cisco ISE 3.2 or later, or Cisco Access Manager |
| Underlay routing | OSPFv2 |
| Underlay topology | Layer 3 Underlay |
Resource reservations
Automatic Underlay and Overlay provisioning uses reserved VLANs, Loopbacks, VNIs, and address space. Before deployment, confirm that these resources are unused and do not overlap with the existing network. The Underlay address pool can be customized during fabric creation. A custom Underlay bypasses automatic Underlay provisioning and does not require the automatic Underlay VLAN reservation.
| Resource | Default or base value | Allocation or reserved range | Notes |
|---|---|---|---|
| Fabric ID | 1 | 1–8 | Unique fabric identifier |
| VRF ID | 1 | 1–64 | Unique VRF identifier |
| Core VLAN | 965 | 965–1028 | Allocated from the base according to the VRF index |
| Underlay VLAN | 900 | 900–915 | Required only for the routed SVI automatic Underlay |
| Layer 2 VNI | 10000 | Offset 1–4094 | Derived from the VLAN allocation |
| Layer 3 VNI | 20000 | Offset 1–64 | Derived from the VRF allocation |
| Fabric Loopback | Loopback100 | One per fabric node | Used as the fabric VTEP Loopback |
| Core VLAN Loopback | Loopback200 | Loopback200–263 | Allocated according to the VRF index |
| Anycast RP Loopback | Loopback300 | Loopback300–363 | Used when multicast replication is enabled |
| Route distinguisher | — | <fabric-Loopback-IP>:<core-VLAN-ID> | Automatically derived |
| Route target | — | <fabric-ASN>:<core-VLAN-ID> | Automatically derived |
| Underlay subnet pool | 172.16.0.0/16 | One /24 per Underlay subnet | Customizable during fabric creation |
Release support and scale
| Capability | IOS XE 17.18.2 | IOS XE 17.18.3 / 26.1.1 |
|---|---|---|
| Cloud-managed mode | Managed | Managed |
| Release timing | December 2025 | July 2026 (public beta) |
| Access platforms | MS, Catalyst 9200, Catalyst 9300 | MS, Catalyst 9200, Catalyst 9300 |
| Distribution Leaf | Catalyst 9300X | Catalyst 9500 High Performance, Catalyst 9300X |
| Core Spine | Catalyst 9500 High Performance (recommended), Catalyst 9300X | Catalyst 9500 High Performance (recommended), Catalyst 9300X |
| Network edge/Border | Catalyst 9500 High Performance (recommended), Catalyst 9300X | Catalyst 9500 High Performance (recommended), Catalyst 9300X |
| Leaf system modes | Cisco StackWise | EVPN Multi-Homing; Cisco StackWise |
| Network support | Wired, Distributed Wireless | Wired, Distributed Wireless |
| Segmentation | Macro-segmentation, Micro-segmentation | Macro-segmentation, Micro-segmentation |
| Policy engines | Cisco ISE (Identity Services Engine), Cisco Access Manager | Cisco ISE (Identity Services Engine), Cisco Access Manager |
Scale and capacity
| Release | Access points | Access switches | Fabric clients | VRFs | Distribution blocks |
|---|---|---|---|---|---|
| IOS XE 17.18.2 | 300* | 384* | 3,000* | 32 | 4 |
| IOS XE 17.18.3 | 1,000* | 768* | 10,000* | 64 | 16 |
* Scale values are provided as guidance and remain subject to change following scale testing and validation.
Distribution-level fabric
The EVPN VXLAN fabric begins at the distribution layer. Catalyst 9500 or Catalyst 9300X switches act as Leaf nodes and connect to traditional Layer 2 access switches. This model introduces segmentation and mobility services without replacing the existing access layer, making it suitable for brownfield migrations, office buildings, and campus networks.
EVPN Multi-Homing at the distribution layer
Starting with IOS XE 17.18.3 / 26.1.1, EVPN Multi-Homing can be enabled on Catalyst 9300X or Catalyst 9500 High Performance distribution switches. An EVPN Multi-Homing pair preserves the existing Layer 2 access design while providing active/active forwarding, independent management and control planes, and distributed forwarding across the two Leaves.
Create the EVPN Multi-Homing pair before adding it to the fabric and assigning it the Leaf role:
-
In Meraki Dashboard, go to Switching > EVPN Multi-Homing.
-
Create the EVPN Multi-Homing pair.
-
In the fabric workflow, add the EVPN Multi-Homing pair and assign it the Leaf role.
-
Use the Add subnet workflow to provision the required Overlay subnets on the pair.
For downstream connectivity, aggregate the member links on both sides:
-
On the access switch, select the links under Switching > Switch ports, and then select Aggregate to create the port channel.
-
On the EVPN Multi-Homing pair, select both Leaf switches and their respective downstream links, and then select Aggregate.
Overlay subnet types
Cloud-Managed Fabric supports three Overlay subnet types. Select the least expansive forwarding behavior that meets endpoint requirements. In this section, BUM refers to broadcast, unknown-unicast, and multicast traffic.
Routed
-
Gateway and scope: A Layer 3 subnet exists on one Leaf and is not stretched.
-
BUM behavior: BUM traffic remains local to the Leaf.
-
VLAN and subnet requirements: Subnets must be unique; VLAN IDs do not need to match across Leaves.
-
Recommended use: Use this as the default when subnet mobility is not required.
-
Scale profile: Highly scalable.
DAG routed
-
Gateway and scope: A Layer 3 subnet is stretched across selected Leaves using a Distributed Anycast Gateway.
-
BUM behavior: BUM replication is restricted to the access edge and is not bridged between Leaves.
-
VLAN and subnet requirements: Participating Leaves use the same VLAN ID and Layer 3 subnet.
-
Recommended use: Choose this for IP endpoints and seamless wired or wireless mobility without extending the Layer 2 flood domain.
-
Scale profile: Scalable across medium to large networks.
DAG bridged
-
Gateway and scope: A Layer 3 subnet is stretched across selected Leaves using a Distributed Anycast Gateway.
-
BUM behavior: Layer 2 BUM traffic is replicated across participating Leaves.
-
VLAN and subnet requirements: Participating Leaves use the same VLAN ID and Layer 3 subnet.
-
Recommended use: Use this selectively for non-IP endpoints, silent hosts, and applications that require Layer 2 flooding.
-
Scale profile: Lower scale; use selectively.
