AutoVPN Dual-Hub Design Causing Asymmetric Routing, How to Prevent It?

[MerakiMaverick]

Hello Meraki Community,

I’ve got a scenario with a few design questions, and I’m looking for some ideas:

I have spokes that connect to two data centers through AutoVPN. Some spoke tunnels come up on the secondary hub first, especially at remote sites with slower WAN. When the primary later comes online, both hubs advertise the spoke subnet to the data center core. Our internal routing prefers the primary hub if it is advertising the spoke subnet.

But this causes problems:
1. If the spoke initially connected to the secondary, internal routing might shift after the primary comes up.
2. If the primary tunnel drops and returns, traffic may continue to flow through the secondary, causing asymmetrical routing.

Does Meraki provide any mechanism to:
1. Advertise spoke routes only if the tunnel is actively carrying traffic, not just “up”?
2. Or suppress routes from a hub that is not currently the active path?

Both hubs advertise the same remote peer subnet. If they’re always seen as online, how do I avoid asymmetric routing? And when the primary hub goes offline, it doesn’t seem to pull its route from the available destinations.

Note: My hubs are operating in one‑arm VPN concentrator mode.

[alemabrahao]

The priority is from top to bottom in the list, so if Hub1 backs, it becomes the priority again.

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

[MerakiMaverick]

Thank you! As a follow‑up question, is there any way to prevent a hub from advertising a spoke’s route when that hub is not the active tunnel? (When in one-arm concentrator mode).

[alemabrahao]

Meraki does not support suppressing AutoVPN route advertisement on a standby/secondary hub.
When using one‑arm concentrator mode, both hubs will continue to advertise the full AutoVPN route table, because route advertisement is tied to AutoVPN participation, not to tunnel activeness.

[MerakiMaverick]

I do see under "Operation and Failover":

"When a WAN Appliance is configured to connect to multiple VPN concentrators advertising the same subnets, the routes to those subnets become tracked. Hello messages are periodically sent across the tunnels from the remote site to the VPN hubs to monitor connectivity. If the tunnel to the highest priority hub goes down, the route is removed from the route table and traffic is routed to the next highest priority hub that is reachable. This route failover operation only applies when identical routes are advertised from multiple Auto VPN hubs."

In this document "Meraki Auto VPN General Best Practices - Cisco Meraki Documentation".

But it doesn't seem to be doing this.

[alemabrahao]

This is the expected behavior. If you are experiencing the problem you described, the best course of action is to open a support case so they can investigate.

Make sure you are using the latest stable software version.

[PhilipDAth]

>If the spoke initially connected to the secondary, internal routing might shift after the primary comes up.

Wouldn't this be desirable?  You want to prefer the primary?