Effective dual WAN failover testing must prove more than the presence of two internet circuits. The links may still share a building entry, carrier path, power source, router, firewall, DNS dependency, or cloud gateway. A local interface can also stay up while the wider service path is failing.
What dual WAN failover testing must prove
A headquarters may buy internet links from two carriers and still lose both when they enter through the same building route, depend on the same power circuit, or terminate on one firewall. Another common failure is logical: the interface remains up while the carrier path, DNS service, cloud gateway, or application route is unavailable, so automatic failover never starts.
What prevents a clean switchover
- Health checks test only the local gateway rather than an important remote destination.
- The backup circuit cannot carry critical traffic at normal peak load.
- NAT, VPN, DNS, inbound publishing, or security policies exist only on the primary path.
- Aggressive thresholds cause repeated switching, while slow thresholds prolong the outage.
Monitor the service path, not only the interface
Map the end-to-end paths and common failure points. Health checks should test a meaningful remote destination through the intended link, with thresholds that avoid both slow detection and unstable switching. Confirm that the standby circuit has enough capacity and that important applications, VPNs, inbound services, DNS, and security policies behave correctly after a route change.
Design choices that need business input
- Which applications and sites must remain usable during degraded operation?
- How much backup capacity is required and which traffic may be limited?
- What remote targets prove internet, cloud, VPN, and name-resolution availability?
- Who authorizes a drill, observes application behavior, and approves restoration?
Record the switch, the user effect, and the return path
A controlled drill should record the starting state, injected failure, detection time, route change, application effect, user communication, restoration, and exceptions. Avoid an unannounced full outage test. Begin with device and route simulation, then progress to a maintenance-window exercise with owners present.
Run a staged failover exercise
- Confirm physical and carrier path independence.
- Test remote reachability rather than only interface state.
- Check standby bandwidth, routing, NAT, VPN, DNS, and inbound dependencies.
- Define switch and switch-back thresholds to prevent flapping.
- Run controlled drills and track corrective actions to closure.
Dual-WAN design and drill questions
Is carrier diversity enough?
No. Confirm physical entry, upstream path, power, equipment, DNS, cloud, and operational dependencies. Two invoices do not prove end-to-end independence.
Should failback be automatic?
It depends on application sensitivity and route stability. A controlled return may be safer when sessions, VPNs, inbound services, or unstable carrier recovery are involved.
Can the first test be a full outage?
Start with route and device simulation, then progress to a maintenance-window test with owners, communications, observation points, and rollback prepared.
Treat WAN resilience as an enterprise network capability
Failover combines circuits, routing, security, application behavior, monitoring, and operating ownership. It should be reviewed as a complete network service.