Meraki SD-WAN design: sizing hubs, choosing routing and adding branches cleanly

Sooner or later every Meraki SD-WAN faces the same question: what has to happen when a new branch is added? The answer is short when the design is settled, and long when hub size, routing and hardware were never decided. This piece follows Meraki's documentation, marks our own recommendations and ends with a checklist.

The architecture as Meraki documents it

Auto VPN builds tunnels between MX appliances through a cloud-based process, orchestrated by a registry service in the cloud. A hub is the central point sites build tunnels to; a spoke connects exclusively to its designated hubs, and traffic between sites passes through the hub.

Meraki recommends this hub-and-spoke topology for most SD-WAN deployments; in a mesh, every mesh-mode appliance connects directly to all the others. The recommended reference architecture has six building blocks:

• an MX in the data centre as a one-armed concentrator with a single Ethernet connection upstream
• warm spare or high availability in the data centre
• OSPF advertisement of the VPN subnets into the data-centre network
• redundancy through a second data centre (DC-DC failover)
• split tunnel at the branches
• dual WAN uplinks at every branch

Every second, the appliances send a UDP probe of about 100 bytes over each tunnel and derive packet loss, latency and jitter from it for path selection.

Size hubs by tunnels, not by sites

Hub selection starts in the MX Sizing Guide, which gives two tunnel figures per model: the maximum from lab tests without client traffic in the tunnels, the recommended maximum from tests with client traffic. Its performance figures are based on MX 26.1.

The same document rates the number of VPN tunnels, like on-box HTTPS inspection, as a high performance impact, and recommends validating the sizing with a proof of concept, because every environment is different.

The count is what matters. A branch with two uplinks forms Auto VPN tunnels over both internet interfaces at once. In a DC-DC failover design it forms tunnels to every hub configured for it and sends traffic for subnets advertised by several hubs to the highest-priority reachable hub.

Routing: static routes, BGP and what MX 26.2 changes

In the basic model, the dashboard distributes routes itself: every subnet and static route with VPN mode enabled goes to the other MXs in the organisation. Hub order on a spoke acts as the metric: routes via the top hub get metric 0, and each further position adds one. With peer tracking, an MX marks all routes of a tunnel unreachable once the remote peer fails.

Meraki warns that this default can produce large routing tables that may destabilise devices in networks with many subnets, and describes four techniques:

• No hub-to-hub tunnels: organisation-wide; Meraki Support enables it on request.
• No spoke-to-spoke routes: routes to subnets behind other spokes are no longer distributed; also organisation-wide via Support.
• Tracking hub-originated routes: spokes track every route with a hub as next hop, even without a redundant path; also via Support.
• Route summarisation: on by default. Summarised routes carry no metric and are not tracked.

MX 26.2 moves the line between Auto VPN and dynamic routing. According to the Features Directory, BGP can be enabled independently of Auto VPN, MP-BGP exchanges IPv4 and IPv6 routes between Auto VPN peers over a single iBGP session, and ECMP spreads new flows across equal-cost paths for eBGP routes learned over several IPsec VPN tunnels.

Segmentation and SSE: VRF, SGT and Secure Access

Segmentation in a Meraki SD-WAN long meant VLANs, firewall rules and group policies. The Features Directory lists VRF, multiple virtual routing tables on one device, in 26.1 as a new feature marked “Early Access” and in 26.2 as an enhancement without that label. For Security Group Tags, 26.1 brought assignment and enforcement via group policies; 26.2 adds IP-to-SGT mapping and SGACL.

Since 26.1, VPN translation lets sites with overlapping subnets take part in the VPN through 1:1 subnet translation, and NAT exceptions can cover some or all VLANs.

For internet and SaaS, 26.1 introduced Cisco Secure Access integration in the dashboard. Anyone on Secure Connect faces a migration, which Cisco offers to consolidate its SASE portfolio on a single SSE platform. The migration guide sets the conditions:

• An organisation cannot currently be connected to Secure Connect and Secure Access at the same time, so some downtime is unavoidable.
• Moving the Auto VPN and IPsec connections requires downtime.
• Support removes Secure Connect only after every related configuration has been deleted, including RAVPN head-end regions, private applications and policies. That closes the quick way back; Cisco calls the limitation temporary.

Hardware generation: what stops at MX 18.1

The new features have a hardware boundary. According to Meraki, the MX64, MX64W, MX65, MX65W, MX84, MX100 and vMX100 run MX 18.1 at most and receive no firmware from 18.2 onwards, so nothing from 26.1 or 26.2. The end-of-support dates:

The last two rows come from EOL15861 of 27 August 2026: Cisco replaces the MX67C and MX68CW with Cisco 8000 Series Secure Routers running MX OS, marked by the -MX suffix. Per Cisco's FAQ, such a router keeps the operating system it was ordered with for life; conversion from MX OS to IOS XE is not possible, and existing co-term or subscription licences cannot be transferred. The planning side is covered in Meraki licensing models.

The same family also runs IOS XE: the Secure Routers C8455-G2, C8355-G2 and C8235-G2 can be managed in the dashboard from IOS XE 26.1.1. One rule from the onboarding guide shapes the design: an organisation can enable Auto VPN for only one device type, either IOS XE Secure Routers or MX and Secure Routers with MX OS, and Meraki recommends a dedicated organisation for IOS XE devices. Auto VPN on these routers uses a hybrid key exchange of P-521 and the post-quantum ML-KEM-768 by default; according to Meraki, hub-to-hub routing and ECMP are not currently available there. For the broader choice, see Meraki or Catalyst.

Adding a new branch: the checklist

With the design settled, a new branch is routine. This is our order:

1. 01

   Check the tunnel budget

   Branch uplinks times hubs times hub uplinks gives the new tunnels. Hold the total per hub against the recommended maximum.

2. 02

   Choose the hardware

   No model that ends at MX 18.1. For the MX67C and MX68CW, mind the end of sale on 27 November 2026; the successors need new licences.

3. 03

   Assign the address space

   A unique subnet that fits the summary of the branch range. VPN translation stays the exception.

4. 04

   Create the network and claim the devices

   From the template for the site type; templates and claiming are covered in our Meraki multi-site rollout article.

5. 05

   Configure Auto VPN as a spoke

   Hubs in the agreed order, local subnets in VPN mode, split or full tunnel as the standard says.

6. 06

   Apply policies and segmentation

   Both uplinks active, performance classes for voice and critical applications, VLANs, VRF, SGT and Secure Access as at every branch.

7. 07

   Align the firmware

   The same MX train as the hubs. Anyone using 26.2 features needs 26.2 on every device involved.

8. 08

   Accept with real application traffic

   A green tunnel is a diagnostic, not an acceptance. The branch passes when its client network reaches real services in the data centre and the cloud, including with one uplink pulled.

Our SD-WAN offering, linked right after this article, describes how we design Meraki SD-WANs, size hubs and connect branches in waves; all Meraki services are under Cisco Meraki. If an MX84 or MX100 is still your hub, or the next branch is already planned, you can walk through the design with us.