Skip to main content

 

Cisco Meraki Documentation

Cisco Secure Connect - Design Best Practices

  1. Last updated
  2. Save as PDF

Overview

This document outlines the design options for using Meraki MX SD-WAN with Secure Connect, offering a comprehensive Secure Access Service Edge (SASE) experience. Cisco recommends aligning your network design with the outlined designs for the best experience.

There are terms used in this document meant to make it easier to identify different types of sites. The definitions of those terms can be found in the Hub Integration document.

2025 Platform Optimization 

Cisco continues to optimize the Secure Connect platform for improved resiliency and routing performance. These optimizations are aligned with the best design practices detailed in this document. To ensure the best experience and performance, it is recommended that your network configuration closely follows these recommended network designs.


To enhance your Secure Connect tenant, you should open a Secure Connect support ticket and request the "2025 Platform Optimization." After you open the ticket, your support engineer will provide the specific details needed to implement the changes. Note that a brief downtime may be necessary to apply these optimizations. Your support engineer will coordinate with you to schedule the changes at a time that minimizes impact on your network operations. 

Design A – Cloud Fabric – Cloud Spoke and Cloud Hub

Design A Cloud Fabric, supports the Secure Connect Complete or Foundation packages and use cases the Secure Internet Access (SIA) and Secure Private access (SPA). It offers a simple cloud-based SD-WAN transport where all MX networks are Cloud Spokes.

Is this Design A for me? - Customer Traffic Profile

Organization with most traffic going north-south to the internet align well with this design. East-west traffic is also sent through the cloud fabric and subject to the cloud firewall consolidating traffic into a single cloud fabric.  Organizations with 500 or more sites enrolled in a region can benefit from this design, reducing the number of hub connections and routes at spokes. This design also works well for customers who choose not to procure and maintain the hub hardware.

Design A – Cloud Fabric Example Diagram

clipboard_e4e2c541ba755263deafb8a070878af2e.png

MX appliances are all Cloud Spokes enrolled in the cloud fabric.  Remote workers can access any Spoke prefixes through the cloud fabric.  Each Spoke can prioritize the closest Cloud Hub as their primary and all Cloud Hubs are automatically in a mesh in Secure Connect.  

Design A - Pros

  • Simplified SD-WAN design with minimal setup
  • Supports both Secure Internet Access (SIA) and Secure Private access (SPA) use cases
  • Route table on spokes is small allowing the cloud fabric to route to all prefixes
  • No MX hub hardware to purchase and manage
  • Cloud firewall for East-to-West traffic for additional security control
  • DIA breakout supported with spokes exempting local traffic from tunnel and going Direct to Internet (DIA) for trusted SaaS
  • Well-suited for customer with 500 or more sites

Design A - Cons

  • No support for MX Local Hubs
  • Limited flexibility to change the traffic path
  • No customer hubs to backup cloud - Customers depend on the cloud fabric for all traffic and act as the only backbone for all traffic
  • Cloud Hub locations subject to DCs supported by Secure Connect

Design B – Flexible – Cloud and Hybrid Spokes with Enrolled Hubs

Design B Flexible, supports both the Secure Internet Access (SIA) and Secure Private access (SPA) use cases. This design allows MX Local Hubs to be enrolled alongside Cloud and Hybrid Spokes.  All spokes will prefer the cloud path except when enrolled hub is communicating with a dependent hybrid spoke.  The hybrid spoke and the enrolled hub it lists in the priority will use the direct MX path.

The Meraki organization must optimize the platform to setup desired sets of routes on Meraki devices.  This design is flexible as it adds Hybrid Spokes and Enrolled Hubs into the design, communicating with existing Cloud Spokes and Cloud Hubs.

Is this Design B for me? - Customer Traffic Profile

Design B Flexible supports more traffic patterns and leverages both the Meraki SD-WAN fabric and the cloud fabric. This allows customers based on business need to route some or all east-west traffic through the Meraki SD-WAN fabric bypassing the cloud fabric. This flexibility can add to the complexity over other designs.

Customer traffic in all directions is driven into cloud fabric for security inspection.  A common cloud firewall policy is applied to all cloud fabric communication.  East-to-West traffic such as spoke-to-hub, remote-worker-to-SDWAN, and spoke-to-spoke communication can all be governed by the firewall policy. Hybrid spokes allow for spoke-to-hub traffic through the Meraki SD-WAN fabric, bypassing the cloud fabric and its firewall.

clipboard_ea9b92bfcf9088f6a6f31acb924cfdc06.png

Cloud Spokes can be used for most branches keeping routing and configuration simple.

An additional benefit is the ability to configure Hybrid Spokes when direct communication when desired (i.e., Spoke 2 in below figure).

Design B – Flexible Example Diagram

clipboard_e2204bc63a5c78be7ca1ebc42cd8dbec7.png

SD-WAN Spokes and Hubs enroll in the cloud fabric and communicate using the Secure Connect:

  • Cloud Spokes 1 or 3 to Enrolled Hubs 1 or 2
  • Cloud Spokes 1 or 3 to Hybrid Spokes 3
  • Cloud Spokes 1 to other Cloud Spokes 3 use default route towards cloud fabric
  • Hybrid Spokes 2 list Enrolled Hubs 1 and 2 and use MX transport to their prefixes

Any remote workers on RAVPN or ZTNA must be permitted as source in policy to access above SD-WAN resources.  Applications and resources placed behind SD-WAN must be defined and then permitted by policy as destination.

This design allows any cloud transport connected resources to communicate amongst each other with exceptions made for Hybrid Spokes to use MX fabric to reach Enrolled Hubs listed in their Hub priority.  Adding Enrolled Hubs in these settings guarantees direct communication via tunnel from Hybrid Spoke (2) to the Hub (1 and 2). 

Design B - Pros

  • Supports both Secure Internet Access (SIA) and Secure Private access (SPA) use cases
  • Spoke-to-spoke traffic via Cloud and common security policy
  • Spoke-to-Hub path can be direct when using a Hybrid Spoke when it benefits the latency or performance
  • Cloud Spoke always prefers the cloud path  and provides a simple configuration with full access to cloud resources
  • Balance of security and connectivity with use of Hybrid Spokes with Cloud Spokes
  • Convergence is shortened, reducing site onboarding time and improving redundancy
  • Additional redundancy is provided by Local & Enrolled Hubs – In the event of a failure in the cloud east-west traffic will continue to flow

Design B - Cons

  • Local & Enrolled Hubs as additional MX hardware are required and maintained
  • Traffic is routed using two different backbones making the solution more complicated and harder to troubleshoot.
  • Routing is reduced to a default cloud path and when desired the direct path can be used from Hybrid Spokes to MX Hubs
  • Hybrid Spoke to Enrolled Hub transport does not transit the cloud firewall

Design C – SIG – Hybrid Spokes and Local Hubs

Design C is best aligned with the Secure Connect Foundation package and the Secure Internet Access (SIA) use case.  It is focused on preserving the SIG (Security Internet Gateway) use case where MX SD-WAN transport is used for east-to-west traffic.  It provides inter-connect at speed of MX WAN and no inspection for private traffic in the cloud.  Hybrid Spokes list both cloud and MX hubs and prioritize MX over Cloud transport.

Is this Design for me? - Customer Traffic Profile

Organizations with a Secure Connect Foundation license can benefit from this design. Phased migrations from SIGraki [EE1] to Secure Connect allow latency-sensitive protocols to retain the advantages of direct MX transport. The cloud transport for east-to-west traffic can also be added at a later stage if the Secure Connect Complete package is purchased.  All Spokes are Hybrid Spokes and have matching Cloud transport priorities.

Design C - Diagram

 clipboard_ee14a34a4046f748791c7fe5afec82dca.png 

Hybrid Spokes are enrolled and use the cloud transport  and communicate using the Secure Connect:

  • Cloud Spokes cannot connect to the local Hub subnets (paths 1-2 and 1-4)
  • Cloud Spokes to Hybrid Spokes and vice versa use cloud transport (path 1 to 3)
  • Hybrid Spokes use MX transport for prefixes provided by listed MX hubs (paths 3-2 and 3-4)

The presence of remote workers on RAVPN or ZTNA is uncommon as they would not have access to the Hubs.  

This design allows any cloud transport connected resources to communicate amongst each other with exceptions made for Hybrid Spokes to use MX transport to reach local Hubs listed in their Hub priority.  Adding and prioritizing the Enrolled Hubs in these settings guarantees direct communication via tunnel from hybrid spoke to the hub (paths 3-2 or 3-4).  

Design C - Pros

  • Simple deployment for customers only needing the Secure Internet Access (SIA) use case
  • Spoke-to-Hub and Spoke-to-spoke use MX transport at MX platform performance
  • Familiar SIG design with priority of MX over Cloud transport

Design C - Cons

  • Spoke-to-spoke and spoke-to-hub traffic is not inspected by the cloud firewall
  • Hybrid Spokes need to match up in their Hub priorities