DMVPN WAN Failover: Route Policy or Shut the Tunnel?

A dual-WAN DMVPN hub fails over in one of two ways, and the difference is bigger than it looks. One changes which next hop a route policy selects, so packets keep flowing and only their exit changes. The other administratively shuts the tunnel, which takes every service on that interface down with it. Both can be correct, because they answer different questions.

The decision comes before the config

Three conditions decide this for you. Does anything else depend on the tunnel interface being up, such as a second DMVPN profile or a monitor that reads its state? Does the traffic that must fail over carry its own policy, or does it rely on the global routing table? And does the operator need an unmistakable state change, or is a quiet path switch acceptable? Answer those three and the choice usually makes itself.

If a shutdown would take down services that were working, the route policy is the smaller action. If the requirement is that the tunnel must not exist while the primary WAN is down, no policy entry can express that.

Write the answer down, because the config is the easy part.

What the route policy actually changes

With policy-based routing, a tracked object can gate a next hop. The route-map entry names a candidate next hop and the tracked object that must be up for it to be used, and that tracking state comes from an IP SLA probe. When the object goes down, the entry stops matching and the packet is evaluated by the next entry or by the ordinary routing table.

That last detail surprises people: a policy that stops selecting a next hop usually permits normal routing rather than blocking traffic. If you need a black hole on failure, you have to write one.

The syntax differs across platforms and releases, so check the guide for the version you actually run.

What shutting the tunnel changes

Shutting an interface changes administrative state. Every tunnel, route and session that depends on it goes down at once, which is exactly what you want if the tunnel is the thing that must disappear. It is also how an EEM applet turns a WAN problem into an outage that includes unrelated services.

If you go this way, limit the applet to one interface and one trigger, save the previous administrative state, define the recovery action, and make sure repeated flaps cannot drive it into a loop.

A hard-coded recovery command can also override a maintenance shutdown somebody else performed.

Make the probe travel the path you think

A probe that follows the current best route moves to the backup WAN along with everything else, and then reports the primary as healthy because it is no longer using it.

Pin the probe to the interface or source address of the path you are testing. Also check what it targets, since reaching the ISP's next hop proves less than reaching the service the tunnel exists for. Set the up and down delays deliberately: a short down delay reacts fast and flaps, while a long one rides out blips and hides real failures. Cisco's IOS XE tracking and policy-routing guide documents the supported combinations, and the feature set on your platform decides which of them you can use.

Record both delay values next to the tracked object, or nobody will know why it behaved that way.

Decide restoration, then verify

Restoration deserves its own decision. A link that keeps crossing the threshold can move sessions more often than one that has clearly failed, and each move costs rekeying and application retries. Choose a stability requirement and let the delay express it. Then verify during a change window with the probe's path visible: selected route, outer peer path, and what the application actually did.

If failover works but the application still breaks, the problem sits above the routing layer and no amount of tracking will fix it.

Keep the evidence from that window, because the next change will be compared against it.