A static route has one fatal flaw: it believes in itself. As long as the outgoing interface is up, the route stays in the table, even if the next hop died, the far end of the circuit is a black hole, or the provider's core is on fire. The interface is up, so the route is valid. That is the whole of a static route's world view.
Object tracking fixes this. You attach a condition to the route, and the route only exists while the condition is true. Combine it with an IP SLA probe and you get a static route that tests the path before trusting it. This article builds one and then kills the path to prove it works. It extends the IP Services cluster guide.
The Problem, Concretely
Classic dual-WAN setup. A primary link and a backup link, both static routes, the backup with a higher administrative distance so it stays out of the table until the primary disappears:
ip route 10.0.20.0 255.255.255.0 10.0.12.2
ip route 10.0.20.0 255.255.255.0 10.0.13.2 200The second route has AD 200 against the default of 1, which makes it a floating static: it floats above the routing table, invisible, until the better route is withdrawn. See the IP Routing cluster guide for how administrative distance arbitrates between sources.
This works perfectly for exactly one failure mode: the local interface going down. The router notices, withdraws the connected route, the primary static loses its next hop, and the floating static installs.
It fails completely for every other failure mode. If the next hop is reachable at layer 2 but the path beyond it is broken (a common outcome when the far end is a switch, a media converter, or a provider handoff), your interface stays up, the primary static stays in the table, and you cheerfully forward traffic into a black hole forever. Nothing fails over, because from the router's point of view, nothing failed.
The Fix: Track a Probe, Not an Interface
Three pieces, in order.
1. An IP SLA probe that tests the path. Not the interface, the path:
R1(config)# ip sla 1
R1(config-ip-sla-echo)# icmp-echo 10.0.12.2 source-interface Ethernet0/1
R1(config-ip-sla-echo)# frequency 5
R1(config-ip-sla-echo)# timeout 500
R1(config)# ip sla schedule 1 life forever start-time now2. A tracked object that watches the probe:
R1(config)# track 1 ip sla 1 reachability3. A static route that depends on the tracked object:
R1(config)# ip route 10.0.20.0 255.255.255.0 10.0.12.2 track 1
R1(config)# ip route 10.0.20.0 255.255.255.0 10.0.13.2 200That is the whole mechanism. The primary route now exists only while track 1 is up, and track 1 is up only while the probe is getting replies.
Verifying the Healthy State
R1#show track 1
Track 1
IP SLA 1 reachability
Reachability is Up
1 change, last change 00:00:12
Latest operation return code: OK
Latest RTT (millisecs) 3
Tracked by:
Static IP Routing 0Read the last two lines carefully. Tracked by: Static IP Routing confirms that something is actually consuming this tracked object. If that section is empty, your track is running and nothing is listening to it, which is a surprisingly common way to spend an hour.
And the routing table shows the primary, at its normal AD of 1:
R1#show ip route 10.0.20.0
Routing entry for 10.0.20.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.0.12.2
Route metric is 0, traffic share count is 1Break the Path
Now kill the primary. In the lab this is a shutdown, but the point is that the same thing happens for any failure the probe can detect, including ones that leave the interface up:
R1(config)# interface Ethernet0/1
R1(config-if)# shutdownWithin a few probe intervals:
R1#show track 1
Track 1
IP SLA 1 reachability
Reachability is Down
16 changes, last change 00:00:09
Latest operation return code: Timeout
Tracked by:
Static IP Routing 0Reachability is Down. Return code Timeout, which is the probe failing rather than merely being slow. (This is why the timeout/threshold distinction from the IP SLA article matters: an "over threshold" result would leave this object UP.)
The routing table responds:
R1#show ip route 10.0.20.0
Routing entry for 10.0.20.0/24
Known via "static", distance 200, metric 0
Routing Descriptor Blocks:
* 10.0.13.2
Route metric is 0, traffic share count is 1Distance 200, via 10.0.13.2. The primary is gone from the table entirely and the floating static has surfaced. And the traffic never noticed:
R1#ping 10.0.20.1 source Ethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.99.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 msOne hundred percent success across a failover the router performed by itself, based on a probe that tested the path rather than the link.
The Trap That Catches Everyone
Look closely at what the probe targets. It pings 10.0.12.2, the next hop. It does not ping 10.0.20.1, the destination.
This is deliberate and it matters. If the probe targeted 10.0.20.1, you would create a circular dependency: the probe needs a route to 10.0.20.1 to send the packet, but the route to 10.0.20.1 is the thing the probe is deciding whether to install. When the primary path dies, the route to the probe target dies with it, the probe starts using the backup path, succeeds, and re-installs the primary route. The router then oscillates.
Two safe patterns:
ip route 8.8.8.8 255.255.255.255 10.0.12.2 so the probe is forced down the primary path regardless of what the tracked route does. Tests the whole path end to end.The second pattern is what you want in production dual-ISP designs, because probing your own next hop tells you nothing about whether the ISP's upstream is working. Pin a host route to a well-known public address out of the primary interface, probe that, and track it. The host route never moves, so the probe always tests the path you intend.
What Else You Can Track
IP SLA reachability is the common case, but the tracking subsystem is more general:
The boolean list is underused and worth knowing. A single dropped probe on a lossy link should not move your default route. Tracking two probes to two different targets with track 10 list boolean or means the route only fails when both are unreachable, which is a much better proxy for "the path is genuinely dead."
Damping the Flap
A path that fails and recovers repeatedly will move your routing table with it, and route churn is its own outage. Two knobs:
R1(config)# track 1 ip sla 1 reachability
R1(config-track)# delay down 10 up 30delay down 10 means the object must be failing for 10 seconds before it declares down. delay up 30 means it must be healthy for 30 seconds before it declares up again. Asymmetric on purpose: fail fast (you want off a broken path quickly), recover slowly (you do not want to move back onto a path that is still flapping).
In the lab output above, note 16 changes on the tracked object. That is a tracker with no damping, faithfully reporting every transition during testing. In production that number is a red flag.
Tracking Is Not Just for Static Routes
The same tracked object can drive other things, which is where it gets genuinely powerful:
- HSRP/VRRP/GLBP priority.
standby 1 track 1 decrement 30lowers the priority when the uplink probe fails, so the standby router takes over as active gateway. This is the canonical fix for the "active HSRP router lost its uplink but is still the gateway" black hole. See the FHRP cluster guide. - EEM applets. An applet can fire on a track state change and log, alert, or reconfigure.
- PBR next-hop. A route-map
set ip next-hop verify-availabilitycan be tracked, so policy routing stops steering traffic into a dead next hop.
FAQ
Why does my tracked route never fail over?
Check three things in order: is the SLA scheduled (show ip sla summary), is the track actually reflecting it (show track), and does Tracked by: list your static route. Any one of those missing breaks the chain silently.
Why does my router oscillate between the two routes?
Your probe target is reachable via the backup path. Pin the probe target with a host route out of the primary interface, or probe the next hop.
Can I track a probe on the backup link too?
Yes, and you should if the backup is a real circuit rather than a local interface. Otherwise you can fail over onto a backup that is also dead.
What AD should the floating static use?
Anything higher than the primary and higher than any dynamic protocol you run for the same prefix. 200 is conventional because it is above every default AD except an unreachable (255).
Does this work with IPv6?
Yes. ipv6 route ... track N and IP SLA operations support IPv6 targets. The mechanism is identical.
Key Takeaways
- A plain static route trusts the interface, not the path. It cannot detect a next hop that is up but useless.
- The chain is: IP SLA probe to tracked object to static route. Break any link and nothing fails over.
show trackmust showTracked by: Static IP Routing. If it does not, nothing is consuming your tracker.- Never probe the destination you are routing to. Probe the next hop, or pin the probe target with a dedicated host route out of the primary interface.
- The failover is visible and clean: distance 1 via primary becomes distance 200 via backup, and traffic keeps flowing at 100 percent.
- Use
delay down / upto damp flapping. Fail fast, recover slowly. - Tracked objects also drive HSRP priority, EEM applets, and PBR next-hop verification. The static route is just the simplest consumer.
Next: the IP SLA probes themselves in depth, or the IP Services cluster guide.
