Meraki SD-WAN Hub Integration with Secure Connect jp

Last updated
Save as PDF

Introduction

Organizations that wish to continue to use their existing MX hubs with Secure Connect have the option to enroll and integrate their MX Hubs into the Secure Connect cloud fabric which maintains the full mesh connectivity where needed while utilizing the Internet security provided by Secure Connect. This integration allows the network administrator to have all, or a subset of their branches continue to be spokes connected to an MX hub and the remaining branch locations and remote workers to be connected via the Secure Connect cloud fabric. Sites and remote users connected to the Secure Connect cloud fabric have the benefit of applying consistent policies and cloud-based security inspection to all East-to-West traffic.

Organizations can take a phased migration approach by initially routing Internet-only traffic through the cloud, with the flexibility to later include other traffic types, such as spoke-to-hub and spoke-to-spoke communication.

The document explains the relevant feature options and the latest design now available for Secure Connect customers. For clarity, the special terms are used to describe devices used in this document. Please review those in the Document SD-WAN Terminology section before starting.

Hub Integration in the Sites Page

Using the Secure Connect > Sites page, Meraki SD-WAN hubs can be enrolled into the cloud fabric. Once provisioning is successfully completed, the cloud fabric connects to hub resources, including VPN-enabled local subnets, static routes, and eBGP learned prefixes. Below illustrated remote workers are connected to Secure Connect via RAVPN or ZTNA. They are able to access applications connected behind enrolled hubs. Furthermore, the spoke and hub branches worldwide can enroll and fully inter-connect using the cloud fabric.

By default, Hub 1 does not receive a default route from cloud hubs. However, this option can be enabled manually if needed.

Enrolling a Hub in the Cloud Fabric

Meraki hub networks are now listed alongside eligible spoke devices when Secure Connect > Sites > Add Sites page is opened. The process for connecting a hub to Secure Connect is identical to the workflow used for enrolling a spoke network. Simply select the hubs that should be to connect and follow the standard procedure.

SD-WAN Fabric Devices

Meraki MX devices (including vMX and Z platforms) are SD-WAN platforms managed within their own networks in the Meraki Dashboard. These devices form Hub-and-Spoke SD-WAN fabric through simple modifications in the Security & SD-WAN settings.

• Hubs: Hub devices form a full mesh of VPN tunnels with other hubs in the AutoVPN domain, enabling connectivity between spokes.
• Spokes: Spokes rely on one or more hubs, creating multiple paths to their reachable networks through point-to-point tunnels.

If all MX devices in the AutoVPN domain are configured as hubs, the resulting topology forms a full mesh.

When MX hubs are enrolled in the cloud fabric, they only mesh with the cloud hubs assigned to their region.
The routing behaviors of Spoke and Hub modes are distinct but can be further customized by administrators using the Meraki Dashboard UI or internal system controls available through Meraki support. For more details, refer to the Meraki SD-WAN documentation.

There are two priority-related UI settings which play a role in a design with two fabrics and should be considered:

1. Site-to-Site VPN Hub Prioritization: Spokes connected to Secure Connect and to local Meraki SD-WAN hubs may have MX hubs first in priority over Secure Connect DC hubs. This would affect East-West communication between Spoke sites enrolled to Secure Connect and Meraki SD-WAN hubs (hubs may or may not be enrolled in Secure Connect).

2. Organization-wide Concentrator Hub Prioritization : Meraki SD-WAN hubs use the org-wide concentrator setting to prioritize the cloud hub as primary for all hubs enrolled in that region. Please keep the Secure Connect DC hubs grouped by region in the list. All MX hubs enrolled in that region will prefer the top cloud hub as primary.

Primary and Secondary Cloud Hubs per Region

As with spokes, an MX hub will use both primary and secondary data centers (DCs). For example, in the U.S. West region, Los Angeles serves as the primary DC, while Palo Alto is the secondary DC. The failover behavior between the primary and secondary DCs is consistent with that of MX spokes.

Organization-wide settings > Concentrator priority under Security & SD-WAN > Site-to-Site VPN is used to prioritize the cloud hub as primary for all enrolled hubs. In the figure above, U.S. Central region enrolled hubs will prefer Denver DC cloud hub over Dallas.

AutoVPN Tunnel Creation

After selecting and confirming the desired Secure Connect region, an AutoVPN tunnel is automatically created from the hub to each Secure Connect DC within that region. If the region selected for a hub to enroll is not already deployed, the system will provision the CPSC-HUB appliances in their DC networks. Once those cloud hubs are up, the tunnels and dynamic route peering will be established.

Route Learning and Default Route Injection

Enrolled MX hubs will learn the routes from the cloud fabric. By default, the default route (0.0.0.0/0) is not injected. It can be enabled using the Remote Routes option in Sites page.

Remote Routes Configuration for Hubs

Selecting an enrolled hub site in the Sites user interface will reveal a right-side drawer. Within this interface, administrators can enable the Remote Routes option under the Default Route setting.

The Remote Routes option becomes available only for MX appliances configured as a hub and then enrolled in the cloud fabric.

Initial Design

Since the feature was added to allow hubs to be enrolled into Sites, the initial design below required that all spokes used MX hub mesh for East-West traffic. MX spokes listed Meraki hubs as their first priority after which followed Secure Connect cloud hubs. This ensured the MX hub tunnels and all their related routes were prioritized for branch-to-branch traffic.

Referring to below figure, Spokes (I.e., Spoke 1) connecting to Secure Connect and having a direct AutoVPN connectivity to Hub 1, prioritizes the direct AutoVPN path to MX Hub 1. This results in all East-West traffic taking the direct path via AutoVPN to MX Hub 1 and not being inspected by Secure Connect cloud security services.

The sections of the document below describe the new design with different types of spokes and enrolled hubs. Please reach out to Secure Connect support to discuss any different scenarios.

Cloud vs. MX Path for Branch Interconnect

When MX hub is enrolled, two paths are available for Spoke-to-Spoke (S2S) and Spoke-to-Hub (S2H) traffic: the Cloud Path or the MX Path. MX hub forms tunnels and peerings with regional cloud hubs. Learned routes with policy can enable remote workers to access resources behind the hub.

In the initial design, the MX Path was required for S2S and S2H traffic, while the Cloud Path was primarily reserved for Internet access and app access for remote workers. By placing an MX hub in top priority on hybrid spokes, S2S and S2H traffic is directed to use the MX Path.

The new design allows S2S and S2H traffic to use the Cloud Path and decouple in using different paths. It can support both Cloud Spokes and Hybrid Spokes, where the latter can prefer the MX path for S2H traffic.

The solution has been enhanced to support the new flexible design. The platform optimization section explains how to enable the cloud-centric design in the organization which already uses Secure Connect.

Platform Optimization for Hub Integration

Cisco has enhanced the Secure Connect solution by adding a set of new and complementing features in its Cloud infrastructure and Meraki MX devices. Previously, integrating MX Hubs within Secure Connect had certain design constraints that can now be resolved. These new controls allow for more flexible network designs with different settings on MX Spokes and Hubs. The cloud fabric path can be used to inter-connect all enrolled MX spokes and hubs.

To optimize your Meraki organization please open the 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.

Please note that a brief downtime is necessary to apply these optimizations. The configurations and routes on all MX branches will reset as a result, reducing the overall system footprint. Cisco support engineer can discuss further details and coordinate the best time to minimizes impact on network operations.

Flexible Design for Hub Integration

An optimized platform removes previous constraints and enables additional scenarios for spokes and hubs. Cloud spokes and hybrid spokes use the cloud path while the latter can still leverage MX path by listing a hub in its priority. Below diagram shows the traffic path chosen different S2S, S2H, and H2H scenarios.

The new hub integration design allows for the following:

Cloud path for all S2S and cloud S2H (cloud spoke to enrolled hub) traffic
MX path on hybrid spokes when an enrolled hub is added to the priority list. There is no need to set priority between groups of hubs, as cloud vs. MX groups no longer install the routes to similar networks. See the change in behavior section below for more details.
Regional primary Data Center (cloud hub) preference is controlled differently on spokes and hubs:
- On each individual spoke using a list of added hubs. I.e., Palo Alto over Los Angeles shown below. Both are automatically added to the hub list when using the Sites UI. MX hubs are added manually under Security & SDWAN > Sites-to-Sites page.
- In organization-wide concentrator priority list, primary can be setup by moving one over the other hub that are in the same region.

Spokes and hubs that are enrolled in the same region can be setup with different primary cloud hubs. Below concentrator priority shows that Spoke 1 and Hub 1 are using different primary data centers. The same applies for Spoke 3 and Hub 2. The cloud hubs should be paired up according to their region while setting preference between the two.

Change in Behavior for Hub priority on Hybrid Spokes

Streamlined routing footprint in the new design has changed function commonly used in Spoke SD-WAN settings. In the previous design, MX hubs listed over cloud hubs ensured MX path. The optimized set of routes no longer require admin to prioritize MX vs. cloud path. Since cloud installs only default routes, there are no competing S2H routes from the cloud with those installed by the listed MX hub. As a result, both order of groups shown below yields the same traffic pattern explained above.

A hybrid spoke that simply lists an MX hub will prefer the MX path to its prefixes, no matter which way the group-to-group priority is setup between the two paths. Again, this is the result of the new streamlined routing footprint on the spokes.

Prerequisites

There are features which may have negative effects on hub integration with Secure Connect. Please review below listed features to understand how they work with hubs enrolled in the cloud fabric.

Hub Mesh must be Enabled

Meraki hubs must be able to form a mesh in the organization. This feature is on by default but can be disabled with help from Meraki support. When disabled, enrolling a hub in the cloud fabric cannot work as expected, as no routes would be exchanged. Please contact Secure Connect support to either re-enable mesh or discuss alternatives.

Exit Hubs are not Supported

Using MX Hub as an Exit Hub is not supported with Secure Connect. Alternatively, enrolled hubs can enable a default route towards the cloud fabric using Remote Routes option.

Enabling Multiple Default Routes

MX Spokes enrolled in the cloud fabric always get a default route (iBGP) installed from the cloud hubs. To preserve the cloud path towards Internet, IPv4 default route feature should not be enabled on listed MX hubs. In below illustration, the Spoke's hub priority list uses 'Hub 4' towards Internet, because its default route is higher in priority compared to the cloud hubs.

Spokes with configured eBGP

Organizations that use eBGP on their Meraki MX Spokes should notify support during their initial platform optimization discussions. The spokes may require more then a default route from cloud hubs, in order to exchange those with their external peer.

An Organization with Hubs and no Spokes in Secure Connect

If an organization has all sites configured as hubs and intends to connect them to Secure Connect, the following are the recommendations and supported designs with Secure Connect:

Note: Secure Connect supports a scale of 60 for this design, meaning that in an all-hub network infrastructure, Secure Connect currently supports integrating up to 60 hubs simultaneously into its fabric.

All hubs connected to Secure Connect will not receive a default route. If there is an 'Internet Access' use case for the hubs connected to Secure Connect, then the user can enable the Default Route for each MX hub under Remote Routes.
The branch-to-branch interconnect between these hubs will always occur over the Auto VPN mesh between the hubs, and the traffic will not route through Secure Connect. As part of policy enforcement, choose your Security & SD-WAN security policies to secure the branch-to-branch traffic for this specific use case.

Document SD-WAN Terminology

For brevity, the document uses the following special terms to describe the devices and paths of traffic within two SD-WAN fabric types:

Cloud Fabric: Refers to Cloud Hub transport with Secure Connect. The document also notes it as the Cloud Path or Cloud Transport.
- Cloud Spoke: Meraki MX Spokes connected only to Secure Connect cloud fabric.
- Cloud Hub: Secure Connect enhanced head-ends that provide cloud transport and are designated with CPSC-HUB platform type. Once Sites UI enrolls a Site, the cloud hubs in that region establish tunnels and exchange routes with enrolled Sites.
MX Fabric: Refers to MX transport using MX Hubs and traditional Meraki SD-WAN tunnels and routes. The document also notes it as the MX Path or MX Transport.
- Local Spoke: MX in Spoke mode enrolled solely in the MX fabric by listing Local Hub(s) that are not enrolled in cloud fabric. Hub 3 below is not enrolled in Secure Connect.
- Local Hub: MX in Hub mode that shows up in a spoke priority list
Devices in both Fabrics: MX devices enrolled in the cloud fabric and spokes which list either a local or enrolled hub in their priority list
- Hybrid Spokes: MX Spoke devices that use both cloud and MX fabric to transport their traffic. When a local spoke is enrolled in cloud fabric, the system adds the cloud hubs up top by default. When needed, this can be quickly corrected in the UI to use the MX path group on top. In the new design shown below, follow-on change to ordering is not required.
- Enrolled Hubs: MX Hubs enrolled in the cloud fabric and peer in a hub-to-hub fashion with region's CPSC pair. MX hub still forms mesh with other hubs in the organization, that could be both local or enrolled hubs.
Traffic Paths:
- Spoke-to-Spoke (S2S) - East-West traffic path between spokes that connects via MX hub or cloud hub (MX or cloud path)
- Spoke-to-Hub (S2H) - East-West traffic path between spoke and a hub