A floating static route only fails over when the port goes down — but a dead ISP usually leaves your port cheerfully up. IP SLA fixes that: the router pings something on the internet, and when the pings stop, it withdraws the route. The Cisco answer to the exact problem our Starlink failover post solves on MikroTik.
The routing post ended on an honest gotcha: a floating static route only fails over when the primary route leaves the table, and IOS withdraws a static when its interface goes down. But the most common WAN failure isn't a down port — it's a fibre that dies three streets away while your ONT keeps the local link up/up. The router thinks everything's fine and never touches the backup. Users have no internet; the router insists all is well.
IP SLA closes that gap. It's a built-in probe engine: the router continuously pings a reliable internet target (say 8.8.8.8) out the primary WAN. A track object watches the probe, and the primary static route is made conditional on that track. Pings stop → track goes down → route withdrawn → the floating backup installs — all in seconds, driven by actual reachability instead of link state. Add a little NAT choreography so translations follow the active WAN, and you have true dual-WAN failover. This is the direct Cisco equivalent of the recursive-route + netwatch trick from our Starlink + MikroTik failover writeup.
01
Define what "the internet is reachable" means: a repeating ICMP echo to a stable target, sent out the primary WAN. Then schedule it to run forever.
# Probe 1: ping 8.8.8.8, sourced from the primary WAN interface, # every 2 seconds, fail if no reply within 1 second (1000 ms). R1(config)# ip sla 1 R1(config-ip-sla)# icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0 R1(config-ip-sla-echo)# frequency 2 R1(config-ip-sla-echo)# threshold 1000 R1(config-ip-sla-echo)# timeout 1000 R1(config-ip-sla-echo)# exit # Start it now and never stop R1(config)# ip sla schedule 1 life forever start-time now # Confirm it's actually probing (safe) R1# show ip sla statistics 1 IPSLA operation id: 1 Latest RTT: 14 milliseconds Latest operation return code: OK Number of successes: 428 Number of failures: 0
Two subtleties. First, pick a target that is always up and not your ISP's own gateway — 8.8.8.8 or 1.1.1.1 are the standard choices; probing your ISP's first hop can report "healthy" while the internet beyond it is dead. Second, on a router with a default route out both WANs, you must pin the probe to the primary path or IOS may send the ping out the backup and always see success. source-interface helps, but the robust fix is a /32 static for the probe target out the primary next-hop (ip route 8.8.8.8 255.255.255.255 <primary-gw>) so the probe truly tests the primary.
02
A track object translates "the SLA is passing/failing" into an up/down state that routes and HSRP can react to. Add delays so a single blip doesn't flap the whole edge.
R1(config)# track 1 ip sla 1 reachability R1(config-track)# delay down 5 up 15 R1(config-track)# exit # down 5 = wait 5 s of failure before declaring DOWN (ignore a hiccup) # up 15 = wait 15 s of success before declaring UP again # (don't fail back onto a flapping primary that keeps dropping) R1# show track 1 Track 1 IP SLA 1 reachability Reachability is Up 2 changes, last change 00:12:40 Delay up 15 secs, down 5 secs
03
Now make the primary default route conditional on the track. When the probe fails, the tracked route is pulled from the table and the floating backup — which was waiting with a worse AD — installs automatically.
# Primary default via fibre, but ONLY while track 1 is up R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1 # Backup default via Starlink/LTE with AD 10 — floats in when primary leaves R1(config)# ip route 0.0.0.0 0.0.0.0 198.51.100.1 10 # Steady state — only the tracked (AD 1) route is installed: R1# show ip route static S* 0.0.0.0/0 [1/0] via 203.0.113.1 # Kill the fibre upstream (port stays up!). Within ~5 s: %TRACK-6-STATE: 1 ip sla 1 reachability Up -> Down R1# show ip route static S* 0.0.0.0/0 [10/0] via 198.51.100.1 ← backup took over
The track 1 object you just built isn't route-specific — it's a reusable signal. On a two-router edge, feed it into HSRP (standby 10 track 1 decrement 30, from the FHRP post) so the gateway also fails over when the primary WAN dies, not just when the router does. One probe, one track, two consumers: the default route and the gateway election. That's the whole redundant edge reacting to a single source of truth about internet reachability.
04
The trap that catches everyone: routing fails over, but existing NAT translations still point at the dead WAN's IP, so traffic dies anyway. NAT has to move with the route.
# Mark both WAN interfaces outside, the LAN inside (as in the NAT post) R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip nat outside R1(config)# interface GigabitEthernet0/1 R1(config-if)# ip nat outside # A route-map per WAN: "NAT the LAN only when egress is THIS interface" R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255 R1(config)# route-map WAN-FIBRE permit 10 R1(config-route-map)# match ip address 1 R1(config-route-map)# match interface GigabitEthernet0/0 R1(config-route-map)# exit R1(config)# route-map WAN-LTE permit 10 R1(config-route-map)# match ip address 1 R1(config-route-map)# match interface GigabitEthernet0/1 R1(config-route-map)# exit R1(config)# ip nat inside source route-map WAN-FIBRE interface GigabitEthernet0/0 overload R1(config)# ip nat inside source route-map WAN-LTE interface GigabitEthernet0/1 overload # Each rule fires only when the routing table sends the flow out its WAN.
Even with route-map NAT, translations created before failover are cached against the old WAN and linger until they time out — so the first minute after a failover can look half-broken. On failover you want to flush them: clear ip nat translation *. Automate it with an EEM applet that watches the track and clears NAT on a state change (a natural use of the EEM post coming later in this series). Manually, it's the first command to run if "failover happened but some things still don't work."
05
Failover has four moving parts — probe, track, route, NAT. When it misbehaves, walk them in order; the break is always at one specific link in the chain.
| Command | Checks |
|---|---|
| show ip sla statistics 1 | Is the probe running and succeeding? Return code OK? |
| show ip sla configuration 1 | Target, source, frequency, timeout — is it probing the right thing the right way? |
| show track 1 | Track state and how many times it has flipped (flap detector). |
| show ip route static | Which default is currently installed — proof of who's active. |
| show ip nat translations | Are translations using the active WAN's address? |
| show ip sla statistics 1 details | Per-probe RTT and the exact failure reason. |
# Probe failing when the internet is actually fine? R1# show ip sla statistics 1 # → fix source-interface / the /32 pin # Probe OK but track never goes down on failure? R1# show track 1 # → check the probe egress path is really the primary # Track down but route doesn't switch? R1# show ip route static # → the "track 1" keyword missing on the primary route # Route switched but traffic still dies? R1# show ip nat translations # → route-map NAT missing, or clear the stale table
06
This is the post where the two platforms line up most tightly — our Starlink writeup solves the identical problem with RouterOS primitives.
| MikroTik / RouterOS | Cisco IOS |
|---|---|
| /ip route check-gateway=ping | IP SLA icmp-echo + track reachability |
| Netwatch host + up/down scripts | Track object (+ EEM for side effects) |
| Recursive route via a probed /32 | Tracked static + the /32 probe pin |
| distance= on the backup route | Floating static (trailing AD) |
| Two masquerade rules per out-interface | Route-map NAT per WAN interface |
| Netwatch clears connections on flip | clear ip nat translation * via EEM |
Remote properties here often run fibre-or-DSL primary with Starlink as backup (or the reverse). Starlink's IP changes and its link to the dish stays up even when the service is degraded — the exact scenario link-state failover misses. Probe-driven failover is the only thing that reacts to what the guest actually experiences: "can I reach the internet," not "is a cable plugged in." We build the same pattern on whichever platform is already on-site.
Takeaways
/32 static so "success" means the primary actually works.delay down/up so a blip doesn't flap the edge and a flapping primary can't yo-yo you back onto it.ip route 0.0.0.0 0.0.0.0 <gw> track 1 plus a floating backup at a worse AD. Probe fails → primary withdrawn → backup installs.clear ip nat translation *, ideally via EEM) or the first minute looks broken.NOCTIS builds dual-WAN edges that fail over on real internet reachability — not a link light — on Cisco or MikroTik, with NAT that follows the active path. We test it by killing the primary upstream, the way it actually fails.
Book a Discovery Call →