Summary: Explains why a Meraki spoke site loses access to hub networks when VPN tunnels fail, covers the default non-identical route tracking limitation, and documents the Meraki backend flag that enables spoke fallback to covering supernet routes.
When a Meraki spoke connects to multiple hubs, it learns routes to hub-local networks over AutoVPN tunnels and groups them into failover sets. Within a failover group, the spoke selects a path by hub priority and can switch between members of that group if a tunnel goes down.
The critical default rule is that failover groups are formed by exact prefix match only. Two hubs both advertising 10.1.0.0/16 form one failover group — the spoke can switch between them. A third hub advertising 10.0.0.0/8 forms a completely separate group, even though the prefix overlaps. Traffic forwarding uses longest-prefix match, so in normal operation the /16 always wins and this grouping is invisible.
The limitation becomes apparent on failure.
Consider a spoke connected to three hubs:
10.1.0.0/1610.2.0.0/1610.0.0.0/8 (covering supernet)When Hub A and Hub B's tunnels fail, the spoke deactivates the /16 routes. It does not perform a second longest-prefix lookup to find Hub C's covering /8. Traffic to destinations in 10.1.0.0/16 and 10.2.0.0/16 black-holes at the spoke despite a valid covering route sitting in the route table.
This is also why Hub C's mesh connectivity to Hub A and Hub B does not help. AutoVPN is not transitive — Hub C does not re-advertise Hub A's or Hub B's routes back toward the spoke. The spoke has no route to those networks from Hub C's perspective; it only has Hub C's own /8 advertisement. Even if Hub C can reach Hub A's networks via the hub mesh, the spoke cannot take advantage of that path automatically.
Meraki's MX Routing Behavior documentation includes a footnote: "If you require the spoke MX to be able to failover to a hub with a less specific subnet, please contact Cisco Meraki Support." This refers to a hidden backend flag with no dashboard equivalent — it can only be set by Meraki support or engineering against a specific network or organisation.
The flag changes the rule the spoke uses to build failover groups. With the flag disabled (default), only identical prefixes form a group. With the flag enabled, overlapping routes — including less-specific covering prefixes — are treated as failover candidates for each other.
Behaviour with the flag enabled:
/16 route carries the traffic. The flag has no effect in steady state./8 via Hub C) and forwards traffic there.This converts AutoVPN's route lookup from "longest match, no recursion" into the "longest match with fall-through to shorter prefixes" behaviour that every conventional routing table has natively. Hub advertisements are unchanged — hubs advertise exactly what they advertised before. The change is a local route-selection rule on the spoke only.
The failure-mode consequences are design-dependent and potentially surprising. A supernet is often advertised by an exit hub or a data centre for reasons unrelated to backing up specific subnets. Enabling automatic fallback means a hub can suddenly start receiving traffic for networks it may have no actual path to — turning a clean, diagnosable black-hole at the spoke into a confusing one deeper in the topology, with possible asymmetric return paths.
Meraki gates the flag behind support so that the covering hub's genuine onward reachability can be verified before the behaviour changes. Two things the flag cannot fix must be confirmed independently:
⚠️ Test Before Depending On It
Deliberately fail the primary hub's tunnel in a maintenance window and confirm both the spoke's route table and actual traffic flow, including return direction, before relying on the flag in production.
The exact scoping of this flag is not publicly documented. Meraki does not publish a catalogue of backend configuration knobs or their available scoping options. The flag may be applicable per-network or organisation-wide — this must be confirmed with Meraki support when raising the case.
If the flag is per-network, the logical target is the spoke network(s) that need the fallback behaviour, not the hubs, since the change is in the spoke's route selection. This approach contains the blast radius — only spokes where the covering hub's reachability has been verified inherit the new behaviour.
If the flag can only be applied organisation-wide, the risk assessment changes considerably: every spoke in the organisation with any overlapping non-identical prefixes inherits the new fallback behaviour, including topologies where a supernet advertisement was never intended as a backup path.
When opening a case, reference the footnote from the MX Routing Behavior documentation explicitly and describe the prefixes involved. Recommended questions:
The support case is effectively the only documentation of the flag's existence — it is invisible in the dashboard, invisible to the Meraki API, and invisible in any config export. Record the case number in any KBA or design document that covers the affected site so that future engineers know the routing behaves non-standardly and why.
Before requesting the flag, confirm the full traffic path in both directions: