Skip to main content

 

Cisco Meraki Documentation

Cisco Secure Access Integration - Design Best Practices

  1. Last updated
  2. Save as PDF

Overview

Today’s remote and hybrid workforce, widespread cloud adoption, and increased internet-bound traffic require organizations to deliver secure, optimized access to applications anywhere, on any device. Traditional network models struggle to keep pace, prompting organizations to embrace Secure Access Service Edge (SASE) architectures. By integrating Cisco Meraki SD-WAN with Cisco Secure Access, businesses benefit from unified, cloud-native networking and security, ensuring consistent protection, simplified operations, and a scalable user experience across all locations.

Cisco Meraki and Secure Access stand out with their centralized, cloud-based dashboards, enabling IT teams to deploy, monitor, and manage networks from anywhere—eliminating the need to build more on-premises controllers. The platform integration prioritizes simplicity, scalability, and automation, while offering built-in analytics and security for both enterprise and distributed environments. Managed through the Cisco Meraki dashboard, Meraki MX SD-WAN leverages AutoVPN technology to seamlessly orchestrate and provision Secure Access cloud hubs and tunnels between sites in a spoke-and-hub network.

This design best practices document outlines options for deploying Meraki MX SD-WAN with Secure Access to deliver a comprehensive SASE solution. Following these recommended designs will help ensure your network achieves optimal performance and security.

Dual Fabric Terminology

For clearer guidance, the following special terms describe devices and traffic paths within two SD‑WAN fabrics: Traditional Cisco Meraki MX SD‑WAN and Cisco SSE Secure Access.

Cloud Fabric: Transport via cloud hubs using Cisco Secure Access; cloud path or cloud transport
 Cloud Spoke: Cisco Meraki spoke connected (enrolled) exclusively to the cloud
Cloud Hub: Cisco Secure Access-enhanced head‑ends that provide cloud transport and are designated with the CPSC‑HUB platform type in Cisco Meraki MX Dashboard

MX (Local) Fabric: Transport via MX hubs, using traditional Cisco Meraki MX SD‑WAN tunnels and routing; also referred to as the MX path or MX transport
Local Spoke: MX in spoke mode operating solely in the MX fabric, listing local or enrolled hubs
Local Hub: MX in hub mode that appears in a spoke's hub priority list

Dual-fabric devices:
Hybrid Spoke: MX spoke that uses both cloud fabric and MX fabric for traffic transport
Hybrid (Enrolled) Hub: MX hub that forms a mesh with other MX hubs while enrolled in the cloud fabric and route peering (hub‑to‑hub) with the region’s pair of cloud hubs

Further explanation on these terms can be found in the Secure Connect Hub Integration document.

Cisco SASE Supported Topologies for Meraki 

The following diagrams show the difference between spoke-spoke communication when enabling secure private access for users.  

Example Meraki topology:
 T1 Supported Topologies - Frame 1.jpg

Example Meraki topology via Secure Access: T1 Supported Topologies - Frame 2.jpg

Why do these changes occur?  

When deploying a SASE architecture, it is recommended to inspect East-West traffic between sites to maximize the security efficacy of the security services. We disable the direct Spoke-Spoke communication via MX Hub to ensure all traffic is inspected, and policy is applied as intended. 

Platform Optimization   

To improve platform stability and resiliency, the following optimization is adopted at onboarding for all organizations that enable the Meraki Secure Access integration: 

  • Dashboard installed routes are removed from all Spokes and Hubs.   

  • BGP protocol is used as a sole method of providing routes to sites  

  • Meraki Hubs are prevented from sharing the Spoke routes they learned toward other Spokes. 

  • Cloud Spokes traffic to any other sites (any Spoke or Hub) prefers the cloud path 

Organizations can support up to 1000 enrolled Sites, with each advertising a maximum of 10 routing prefixes to the Cloud Fabric. These MX-advertised prefixes encompass local subnets, eBGP-learned routes, and defined static routes.

For quicker convergence with Cloud Hubs, Spoke sites can be configured to receive only a default route, bypassing specific iBGP route prefixes. This simplified routing also allows sites to advertise an increased limit of up to 20 prefixes with the same 1000 enrolled Sites.

To enable this reduced routing configuration for your regions, contact Meraki support.

Learn more about the 2025 Platform Optimization here. 

These settings, derived from insights gained from the Secure Connect product and its underlying technology, ensure faster failover during Data Center outages. They also simplify spoke site routing, thereby reducing overall route complexity and improving BGP convergence.

Do I need a Maintenance Window? 

  • Do you have the Secure Access Secure Internet Access package only (No SPA package purchased)? 

  • Customers with the following packages may need a maintenance window: 

  • Secure Internet Access (SIA) Essentials 

  • Secure Internet Access (SIA) Advantage 

  • Customers with the following packages will not need a maintenance window: 

  • Secure Internet Access (SIA) + Secure Private Access (SPA) 

  • DNS Defense is not yet supported via this integration.  

  • Does your organization require spoke-spoke communication using an MX hub? 

  • Every Meraki organization has this capability by default, but not all customers use it.  

  • Some larger organizations use this to manage the scalability of their deployments when changing routing configuration. 

If you have answered Yes to both questions above, you should schedule a maintenance window BEFORE enabling the Secure Access integration.

Enabling Secure Access Meraki Integration in a Maintenance Window 

Once you are in your scheduled maintenance window, complete the following steps: 

  1. Turn on the integration by completing these steps 

  1. Onboard the hubs & spokes to SSE by completing these steps 

  1. If you have SIA only and desire Spoke-Spoke communication, call support to have them disable the feature after you have onboarded your hubs & spokes to Secure Access. 

  • You can reference this document or tell them that you “desire Spoke-Spoke communication” reinstated on your organization.  

Use the Call Me Now feature in the Meraki dashboard to request an immediate phone call. 
Phone calls guarantee faster response times and can deploy these changes during your maintenance window. 

4. Optional: Organizations managing a large number of sites (over 500) enrolled in a single Secure Access region can enable the only-default-route for Spokes feature described in the Platform Optimization section of this document. Customers can request to enable this feature when they contact Meraki support. Learn more here. 

Design A - Cloud Spokes and Cloud Hubs

This design supports both Secure Internet Access (SIA) and Secure Private Access (SPA) use cases. It provides a straightforward, cloud‑based SD‑WAN transport model in which all MX networks operate as Cloud Spokes.

All customer branch spokes are enrolled in Cisco Secure Access, and no MX hubs are deployed. All traffic-spoke‑to‑spoke, remote worker to site, and endpoint to IPSec‑attached applications-flows through the cloud path. Because MX hubs are removed from the design, it can scale to a very large number of sites, making it particularly suitable for environments such as retail deployments.

clipboard_e964a2955b935f751558d3cf3071ed87f.png

Is this Design for me? - Customer Traffic Profile

Organizations whose traffic is primarily north‑south toward the internet align well with this architecture. East‑west traffic is also carried through the cloud fabric and inspected by the cloud firewall, consolidating traffic into a single security and routing domain.

Organizations with 500 or more sites within a region can benefit significantly from this approach by reducing the number of hub connections required and minimizing route scale at spokes. This design also appeals to customers who prefer not to purchase, host, or maintain hub hardware.

All MX appliances function as Cloud Spokes connected to the cloud fabric. Remote workers can reach any spoke‑advertised prefixes through the cloud. Each Spoke can select the nearest Cloud Hub as its primary, and all Cloud Hubs automatically form a mesh within Secure Access.

Design A - Pros

• Simplified SD‑WAN architecture with minimal configuration
• Supports both SIA and SPA use cases
• Small routing tables at spokes, with the cloud fabric providing full prefix reachability
• No MX hub hardware to deploy or maintain
• Cloud firewall protection for east‑west traffic
• DIA breakout supported, allowing spokes to send trusted SaaS traffic directly to the internet
• Ideal for customers with 500+ sites
• Broad regional coverage through Secure Access integration

Design A - Cons

• No support for MX Local Hubs or Hybrid Hubs
• Less flexibility to alter traffic paths
• No customer‑owned hubs to provide backup for cloud transport-traffic relies entirely on the cloud fabric as the backbone

Design B - Any Spokes with Hybrid and Cloud Hubs

This design supports both Secure Internet Access (SIA) and Secure Private Access (SPA) use cases. It allows a mix of Cloud Spokes, Hybrid Spokes, and Local Spokes, creating a flexible architecture that can adapt to varying connectivity and application access needs.

In the SPA use case, Cloud Spokes use the cloud path for application access, while Hybrid and Local Spokes can use the MX path to reach applications directly through their enrolled MX hubs. In private access scenarios, an MX‑based traffic path (dotted green) enables Hybrid Spokes to access Hybrid Hub resources without using the cloud path.

clipboard_eb1b4c7c85025b71b3e9d93d776932867.png

For internet‑bound traffic, Secure Internet Access (SIA) is used for most sites. Even Hybrid Hubs can advertise a default route to send internet traffic through the cloud path for SIA.

 clipboard_e02345f2a79698da48ecab11c0940de17.png

Is this Design for me? - Customer Traffic Profile

This design supports a broader range of traffic patterns by leveraging both the Meraki SD‑WAN fabric and the cloud fabric. Customers can selectively route east‑west traffic through the Meraki SD‑WAN fabric when needed, bypassing the cloud fabric. This flexibility increases capability but also introduces more complexity compared to simpler designs.

All traffic directed into the cloud fabric is subject to a unified cloud firewall policy. East‑west flows-such as spoke‑to‑hub, remote‑worker‑to‑SD‑WAN, and spoke‑to‑spoke-can be governed by this common security layer. When Hybrid Spokes communicate directly with Hybrid Hubs through the MX fabric, these flows bypass the cloud firewall.

Cloud Spokes can still be used for the majority of branch sites, maintaining simple routing and configuration. Hybrid Spokes provide additional flexibility by enabling direct communication to selected Hybrid Hubs when performance or latency advantages exist. Remote workers (RAVPN or ZTNA) must be explicitly permitted in policy to access SD‑WAN resources. Applications behind SD‑WAN must also be defined and allowed as policy destinations.

Resources connected through the cloud transport can communicate freely, except when Hybrid Spokes are configured with priority MX Hubs. Assigning a Hybrid Hub in the hub‑priority list ensures direct MX‑tunnel connectivity from that Hybrid Spoke.

Design B - Pros
  • Supports both SIA and SPA use cases
  • Spoke‑to‑spoke traffic can traverse the cloud with a common security policy
  • Hybrid Spokes allow direct spoke‑to‑hub access through the MX fabric to improve performance or latency
  • Cloud Spokes maintain simple configuration while providing full access to cloud resources
  • Provides a balanced approach between security and direct connectivity
  • Faster convergence improves onboarding speed and redundancy
  • Additional redundancy from Local and Enrolled Hubs ensures east‑west traffic continues even if the cloud path experiences issues
Design B - Cons
  • Requires additional MX hardware for Local and Enrolled Hubs
  • Dual‑backbone routing increases complexity and troubleshooting difficulty
  • Routing defaults to the cloud path, with direct MX‑based paths used only when configured on Hybrid Spokes
  • Hybrid Spoke-to-Enrolled Hub traffic bypasses the cloud firewall

Support for additional Meraki designs will be validated after Meraki with Secure Access solution reaches General Availability.