Skip to main content

 

Cisco Meraki Documentation

Cloud-Managed EVPN Fabric Installation / Lab Guide

  1. Last updated
  2. Save as PDF

Cloud Fabric Installation Overview 

Cisco Meraki's cloud-managed fabric solution provides a flexible and powerful way to design, deploy, and manage your cloud Fabrics using the Meraki Dashboard. There are multiple valid approaches to configuring a fabric, depending on your network topology, scale, security requirements, and operational preferences.

This guide presents one specific method for installing and configuring a Meraki cloud fabric. It focuses on a common, straightforward deployment pattern that emphasizes best practices for reliability, simplicity, and scalability. While the steps outlined here have been tested and are recommended for many environments, they are not the only way to achieve a successful fabric deployment.

Alternative configurations may include different underlay/overlay designs, varied placement of border gateways, custom routing policies, or integration with existing non-Meraki infrastructure. The Meraki Dashboard's intuitive interface and extensive documentation allow you to adapt the fabric to your unique needs.

As you proceed through this guide, feel free to modify or deviate from the presented steps where appropriate for your environment. Always refer to the latest Meraki documentation for the most current features, recommendations, and supported topologies.

Let's get started.

Topology Overview:  

This lab guide may use hardware that is 'compatible' but may not be officially supported yet. Please see the Cloud EVPN Fabric Overview page for officially supported hardware.
 

Spine-leaf architecture with BGP EVPN VXLAN overlay on OSPF underlay.  

  • Spine Layer: 2x Catalyst 9500H (IP transport; BGP Route-Reflector; connected via HundredGigE to leaves/borders). 

  • Leaf Layer: 2-4x Catalyst 9300X (VTEP for access; TwentyFiveGigE uplinks to spines; trunk downlinks to access switches/APs). 

  • Border Layer: 2x Catalyst 9300X (VTEP for external L3 routing; GigabitEthernet to core/fusion routers with VRFs). 

  • Access Layer: 2x Catalyst 9300 (stacked for wired) + 2x Catalyst 9166i APs (wireless); trunk uplinks to leaves. 

 

Sample Connectivity Diagram:  

 
 

 

Lab Size/Scale Considerations:  

  • Recommended lab is 3-4 switches (1 border/spine and 2 leaves)  

  • For scale/capacity numbers please see the Cloud EVPN Fabric Overview 


Lab Configuration Steps 

Underlay Configuration

STOP!!! DECISION TIME 

Before you begin you must decide if you want to deploy the lab with an automated SVI underlay or custom user-created underlay

Option 1: Automated SVI Underlay (Default)  

[NOTE] If you cannot enforce VLAN pruning across the deployment with R-PVST+, it is strongly suggested to start with a reliable fabric underlay using a pure layer 3 routed underlay design (Routed Underlay Option #2).  

A diagram of a company AI-generated content may be incorrect. 

A diagram of a company AI-generated content may be incorrect. 

  1. This option requires STRICT pruning of fabric vlans from the underlay. Bridging fabric vlans between fabric nodes via Layer2 WILL create chaos and unpredictability.   

  1. This option automates the creation of underlay transport VLANs (900-915) on fabric nodes for a layer2 underlay. It also provisions a subnet for this underlay interface.  

 

Option 2: User-Created Routed Underlay (Recommended) 
A screenshot of a computer screen AI-generated content may be incorrect. 
  1. Safest Option but requires manual underlay and OSPF peer configurations 

  2. Use Routed Ports to connect the fabric nodes together, these must be created manually 

 

Physical Connectivity 

Border Connectivity 

There are two ways to connect the border 

  1. Single Trunk Interface

A screenshot of a computer AI-generated content may be incorrect. 

  • Single cable for both management and fabric egress vlan 

  • L2 spanning-tree domain extended to the Fusion device 

  1. Routed Interfaces 

A screenshot of a computer AI-generated content may be incorrect. 

  • Two connections required, one for management and one for fabric egress 

  • Pure L2 isolation from the Fusion device 

 

 

Fabric Node Connectivity  
 

 

 

Underlay Automation 

Underlay Routing  

A screenshot of a computer screen AI-generated content may be incorrect. 

 

  1. IGP (OSPFv2)  

  1. OSPF is used for the underlay routing protocol. It will only create the OSPF peering on the underlay.  

  1. Route redistribution from/to the OSPF underlay is currently not supported in EFT. Static routes are recommended at this time.     

  1. The subnet will need to routed/reachable from outside the fabric (DHCP, Radius etc). 

  1. In the above example. The loopback pool subnet (10.254.254.0/24) should have a static route on the fusion router pointing to the Border node’s underlay interface 

 

 

Underlay Transport 
  1. In Cloud Fabric Phase-1, we're using SVI/VLANs as underlay transports to facilitate brownfield migration. The goal is to migrate all underlay subnets into the fabric allowing for pure layer3 inter-switch links. 

 

  1. Larger deployments can look like the following.  

  • Vlans 900 & 902 are used for SPINE-BORDER links 

  • Vlans 901 & 903 are used for SPINE-LEAF links 

  • For multi-role nodes, these vlans aren't provisioned 

 

  1. A more “common” representation of the previous diagram would look like the following 

A diagram of a computer AI-generated content may be incorrect. 

  1. If you expand the Border/Spine into a more complex fabric environment, you could see something like this

A diagram of a network AI-generated content may be incorrect. 

  • This example shows how the fabric underlay segments can be mapped to trunks while preventing them from being blocked by spanning-tree. R-PVST+ is used to ensure that only the looped VLAN is blocked and not the critical underlay VLAN. 

 

 

  

Pre-Fabric Check-list 

 

1. Make sure your firmware is up-to date 

  1. Check firmware version is showing correct version. For this lab we'll be using 17.18.2 GA 

 

  1. Make sure your config-generation is working without issues 

  1. 'show meraki config up' from Cloud-CLI or Tools Show-CLI command runner. 

A screenshot of a computer AI-generated content may be incorrect. 

  • Everything should be showing “Pass” 

  • If you see the above example “Not needed”, that means there is no queued config and everything is stable. 

  • Check the last config-save time. Make sure it is at least 15+ minutes old 

  1. If there are any failures, please contact support and resolve prior to deploying fabric 

A computer screen with a black background AI-generated content may be incorrect. 

  1. Verify no conflict with fabric underlay resource reservations (Vlan-id, loopbacks, etc) 

 

 

Network Prep / Staging 

Network Settings 

  1. Navigate to "Network-wide -> General" 

  1. Set Traffic Analysis to "Detailed: collect destination hostnames" 

 

 

Switch Port configuration 

We want to prune all VLANs that aren't in use on the switch. By default, every port is configured as a trunk port. If there is at least ONE port on a switch still configured for trunk(allowed 1-1000), all 1000 ports will be provisioned on the switch. To enable Rapid-PVST+, we need to prune the vlans to below 300. You can follow the process here or do so manually. 

 

  1. Configure all ports to be Access ports VLAN1 

  1. Navigate to "Switching -> Switch Ports", change results-per-page to 200 for easier configuration. 

  1. Bulk select all ports on the page 

 

  1. Edit ports to configure and click "update" to commit 

  • Type = Access 

  • VLAN = 1 

 

2.  Port Automation with Smart-Ports

Smart-Ports are used essential to simplifying switch-port configuration and minimizing misconfigurations. They can be used to map previously definte port profiles to ports. 

 

 

Migrating Cloud-Management to a Routed Uplinks 

Routed Ports can be used for Cloud management, but needs to be configured in two steps. In this example, we get the switches connected to dashboard, let them upgrade and get stable. Only then do we migrate the switch to use routed uplinks 

 A diagram of a router AI-generated content may be incorrect. 

IMPORTANT: 

  • Routed port subnets cannot overlay with any existing subnet 

 

 

MIGRATION STEPS 

  1. Navigate to the Switch Details Mimic panel and select the desired port, next click "Edit" 

 

  1. Change the ports "Interface mode" to "Routed port" and update. This will redirect you to the "Routing and DHCP" page. 

 

  1. On the "Routing and DHCP" page,  it should let you enter the interface details. Make sure to enable the "V4 Uplink" checkbox. Save changes 

 

  1. The Routed uplink config will get pushed to the switch. Make sure the config has been pushed before physically wiring the port 

  1. The switch might take <X> minutes before it migrates to Routed Uplink 

 

  1. Check your routed interface, it should match the switches management uplink details in the side-panel 

 

  1. SUCCESS! Repeat for all switches.  The switch might take a while to flip over to routed-uplink.  

 

Network Switch Settings in Dashboard 

  1. Navigate to "Switching -> Switches -> Switch Settings" 

  1. Set "Management VLAN" to your management VLAN 

  1. Change "STP configuration mode" to "Enable Rapid per-VLAN Spanning Tree (RPVST+) 

[NOTE!!!] By converting to RPVST+ you are limited to 300 total active vlans. Trunks configured for more than 1000 vlans will be truncated to 300. (This is why it's important to prune vlans before this step) 

  1. Change priority for the Leaves to '61440' for VLANs 900-915 and ‘0’ for fabric subnets 

  1. Change priority for SPINE-1 to ‘0’ for VLAN 900,901 

  1. Change priority for SPINE-2 to ‘0’ for VLAN 902,903 

A screenshot of a computer AI-generated content may be incorrect. 

  1. Configure Quality of Service  

  1. Create a new rule "Add a QoS rule for this network" and Save the default. It should be Any/Any Trusted.   

 

  1. Edit DSCP to CoS map and configure best practices, Save 

 

  1. Configure MTU to '9100', click Confirm 

 

  1. At this point you've configured A LOT. Use Cloud-CLI to verify configuration has been pushed before proceeding to the next step. 

  1. 'show meraki config up' from Cloud-CLI or Tools Show-CLI command runner.

A screenshot of a computer AI-generated content may be incorrect. 

  1. If you want to force a config push. You can enable/disable a port in dashboard, or change something arbitrary like the devices street address. 

[TIP] If your impatient like me, just add a space to the end of the existing physical street address, make sure ‘update location’ is checked and then hit enter. 

 

 

 

Deploying Cloud Fabric 

Steps to deploy 

  • All switches already in Cloud-Config mode 

  • Pre-check and Dashboard Network Prep 

  • VLAN pruning, RPVST+ and/or Routed-Port config 

  • (optional) DIY underlay provisioning (routed port links, OSPF peering) 

  • Create & Deploy Cloud Fabric 

  • Validate Fabric Device Config  

  • Validate Routing Environment 

  • Validate Client Connectivity 

 

Creating a new Fabric 

  1. Navigated to "Organization -> Fabric" 

  2. Click "Create new fabric" 

  

  1. Enter your fabric details on the Fabric setup page 

  1. BGP ASN: 65005 

  1. (optional) auth-key 

  1. Select networks 

  1. Underlay loopback IP pool: 10.254.254.0/24 

 

  1. VRFs, click "next" 

 

  1. Creating Fabric Subnets, click "Add subnet" 

 

  1. Create fabric_subnet_101  (Distributed Anycast Gateway BRIDGED Mode) 

  1. Name: fabric_subnet_101 

  2. Vlan-id: 101 

  3. Interface IP/Mask: 10.1.101.1/24    <<<<<---- ANYCAST GATEWAY 

  4. DHCP Server IP: 10.10.248.1  (This must be outside the fabric, on the MX or centralized) 

  5. Anycast Gateway: Enabled 

  6. Broadcast Replication: Enabled 

  7. Save subnet 

   

  1. Create fabric_subnet_102 (Distributed Anycast Gateway Routed Subnet) 

  1. Name: fabric_subnet_102 

  2. Vlan-id: 102 

  3. Interface IP/Mask: 10.1.102.1/24    <<<<<---- ANYCAST GATEWAY 

  4. DHCP Server IP: 10.10.248.1   (This must be outside the fabric, on the MX or centralized) 

  5. Anycast Gateway: Enabled 

  6. Broadcast Replication: Disabled 

  7. Save subnet 

 

  1. Once your subnets look good, click "Next" 

 

  1. Border Configuration 

  1. You can create a L3 interface at this stage, click "Create L3 interface" on your Border-1 

 

  1. Create your EGRESS interface, this is the interface which the fabric overlay traffic will egress the network 

  1. Name: FABRIC_EGRESS 

  2. VRF: Fabric 

  3. Vlan-id: 50 

  4. MTU: 1500 

  5. Interface IP/mask: 10.1.100.2/30 

 

  1. Create eBGP instance 

  1. Neighbor IPv4: 10.1.100.1 

  2. Remote AS: 65001 

  3. VRF: Fabric 

  4. Source Interface: 10.1.100.2/30 

  5. Click Save 

 

  1. Validate config before clicking "Save to staging" 

 

  1. Click on the fabric instance to enter the staged config. Click "Comment and deploy" to deploy the config 

 

 

Validating and Troubleshooting Deployment 

clipboard_e8de1ba548860ba969ab6d11daf0ce350.png

Fabric and Device Configuration Validation 

Fabric UX

 

  • The Fabric Summary page has many good sources of information, from deployment status to statistics and detailed view 

  • Detailed Views 

  1. Topology – good for identifying connectivity between fabric nodes. This currently requires CDP/LLDP so will only show for Trunk/SVI underlay

 

  1. Fabric Devices – tracks device health status, loopback ip and fabric roles