Dual-WAN was supposed to make outages invisible. Instead, connectivity “comes and goes” every few seconds: VoIP calls drop, VPNs re-establish constantly, downloads restart. The primary link is actually fine — the failover logic is switching back and forth on a health check it should never have trusted, and every flip tears down every session. A flapping failover is worse than the outage it was meant to cover.
Dual-WAN failover rests on a health probe: the router repeatedly tests whether the primary link is alive, and if the test fails, it promotes the backup. The design assumption is that the test fails rarely and decisively — a real outage. When the probe is unreliable instead, it fails and recovers constantly, and the router dutifully switches back and forth on every blink.
Each switch is not free: changing the default route re-sources NAT, invalidates conntrack, and tears down every stateful session — VoIP, VPN, SSH, downloads — which then try to re-establish just in time for the next flip. The result is a network that is never stable, which is worse than a clean outage you can wait out. The link is fine; the failover is the fault.
01
The probe says down, the router fails over, the probe says up, it fails back — and every flip resets every session.
The tell that distinguishes this from a genuinely bad link is the rhythm: it recovers and dies on a regular beat, not randomly, and the logs show the gateway going up and down far more often than any real link would. A link that is actually failing stays down; a flapping probe toggles like a metronome.
02
Almost always the health check, not the link: the wrong target, timers too tight, or no hold-down to damp the oscillation.
| Cause | Why it flaps |
|---|---|
| Probing an unreliable target | Pinging a host that rate-limits or deprioritises ICMP (or is just flaky) makes the probe fail on a healthy link. |
| Timers too aggressive | One missed ping flips the route. Normal jitter looks like an outage. |
| No hold-down / hysteresis | Nothing stops it switching back the instant the probe recovers, so it oscillates instead of settling. |
| Probe reachable via both WANs | If the target is reachable through either link, the probe can succeed/fail ambiguously — pin it to the interface under test. |
03
Regular, rhythmic instability and a log full of up/down — not the steady silence of a dead link.
| What you see | What it tells you |
|---|---|
| Connectivity “comes and goes” on a beat | The route is oscillating, not the link failing. |
| VoIP drops, VPN reconnects constantly | Stateful sessions torn down on every flip. |
| Logs full of gateway up/down, route change | The probe toggling far more often than a real link would. |
| Public IP keeps changing | Traffic keeps re-sourcing as the active WAN flips. |
04
Probe a reliable, diverse target through the right interface, and add hold-down so a recovered link does not instantly steal the route back.
Probe something that is reliable and actually diverse from the backup path, and bind the probe to the interface under test so it measures that link, not “the internet via whatever route.” Then damp it: require several consecutive failures before failing over, and a hold-down before failing back, so a link that is merely twitchy does not drag every session with it.
# probe a reliable IP THROUGH wan1 only (recursive route pins the path) /ip route add dst-address=9.9.9.9/32 gateway=WAN1-GW scope=10 /ip route add dst-address=0.0.0.0/0 gateway=9.9.9.9 target-scope=11 \ check-gateway=ping distance=1 comment="primary: wan1" /ip route add dst-address=0.0.0.0/0 gateway=WAN2-GW distance=2 comment="backup: wan2" # netwatch with a tolerant interval/timeout so one blip is not an outage /tool netwatch add host=9.9.9.9 interval=10s timeout=2s
ip sla 1
icmp-echo 9.9.9.9 source-interface GigabitEthernet0/0/0
threshold 1500
timeout 2000
frequency 5
track 1 ip sla 1 reachability
delay down 15 up 30 ! hold-down: 15s to fail over, 30s before failing backIf the health-check target can be reached through either WAN, the probe never cleanly tells you the primary is down — and worse, after failover it may still “succeed” via the backup and immediately fail back. Always pin the probe to the specific interface (a recursive route or source-interface), and pick a target that is not anycast-reachable everywhere. Testing “is the internet up?” is not the same as “is this link up?”
05
The route log and the gateway history tell flapping from failing at a glance.
# RouterOS: is the primary route toggling active/inactive on a beat? /log print where message~"gateway" # rhythmic up/down = flap /tool netwatch print # status + since: how often is it flipping? /ip route print where comment~"primary" # active or not, right now? # Cisco: the track and SLA history show track 1 show ip sla statistics 1
A gateway that goes up and down on a regular cadence — versus staying down — is the signature of a flap, not a failure. Fix the probe target and add hold-down, and the route settles on the primary where it belongs, failing over only when the link truly dies.
Takeaways
A flapping failover is almost always a bad health probe or missing hold-down, not a bad link. I fix the probe, add hysteresis so failover is rare and sticky, and prove it by pulling the primary for real.
Book a Discovery Call →