Cisco IP SLA Tracking for Floating Static Route Failover

A floating static route only fails over when the interface goes down, which is useless when the interface stays up while the ISP stops forwarding — a very common failure with upstream carrier problems. Cisco IP SLA solves this by testing reachability end to end and withdrawing the route when the probe fails. This article builds the complete redundant-ISP configuration: the icmp-echo probe, the track object, the two default routes with different administrative distances, and the NAT route-maps that keep translation working after a failover.

The Three Pieces

1. IP SLA operation — an active probe (here icmp-echo) sourced from a specific interface toward a stable remote address.
2. Track object — binds a route to the probe result.
3. Floating static route — a backup route with a higher administrative distance that is installed only when the tracked route disappears.

Configure the Probe and Track

ip sla 1
 icmp-echo 10.0.12.2 source-ip 10.0.12.1
  timeout 5000
  threshold 5000
  frequency 60
ip sla schedule 1 life forever start-time now

track 8 ip sla 1 reachability

Three timers decide how fast failover happens and how often you generate traffic. Cisco's documented recommendation for this use case is a 5000 ms threshold, a 5000 ms timeout and a 60 second frequency. Shrinking the frequency gives faster detection at the cost of more probe traffic — and remember that a probe fired every second to a public address is indistinguishable from a monitoring service to some upstreams.

The probe target matters more than the timers. Point it at something that reflects the actual path: the next-hop ISP router address or a well-known address inside the carrier, not your own loopback on the far side of the failed link.

Floating Static Routes

ip route 0.0.0.0 0.0.0.0 10.0.12.2 track 8
ip route 0.0.0.0 0.0.0.0 10.0.13.2 10

The primary default route carries the track; the secondary has administrative distance 10 so it is installed only when the tracked route is removed from the RIB. Verify both states:

CustomerEdge# show ip route static
Gateway of last resort is 10.0.12.2 to network 0.0.0.0
S*    0.0.0.0/0 [1/0] via 10.0.12.2      ! primary is up, track 8 is up

CustomerEdge# show ip route static
Gateway of last resort is 10.0.13.2 to network 0.0.0.0
S*    0.0.0.0/0 [10/0] via 10.0.13.2     ! primary withdrawn, backup installed

Keeping NAT Correct After Failover

If the primary route withdraws but the NAT statement still translates toward the failed interface, the source addresses leaving the backup link are wrong and return traffic is dropped. Route-map based NAT keyed on the exit interface fixes it:

interface GigabitEthernet0/0/2
 description TOWARDS CUSTOMER LAN
 ip nat inside

ip access-list extended 101
 permit ip 192.168.1.0 0.0.0.255 any

route-map NAT_ISP1 permit 10
 match ip address 101
 match interface GigabitEthernet0/0/1
route-map NAT_ISP2 permit 10
 match ip address 101
 match interface GigabitEthernet0/0/0

ip nat inside source route-map NAT_ISP1 interface GigabitEthernet0/0/1 overload
ip nat inside source route-map NAT_ISP2 interface GigabitEthernet0/0/0 overload

Because each route-map matches its own exit interface, only the NAT rule associated with the interface actually carrying traffic can be active. That is what produces a seamless address change on failover.

Verification

show track
show ip sla statistics
show ip sla configuration
show ip nat translations | include GigabitEthernet0/0

show track output shows reachability state, the number of changes and the last change timestamp, plus which object is tracking it:

Track 8  IP SLA 1 reachability
  Reachability is Up
  7 changes, last change 00:00:17
  Latest operation return code: OK
  Tracked by: Static IP Routing 0

Practical Warnings

• Probe flapping causes route flapping. If the target is intermittently reachable, add a delay on the track object rather than shrinking the SLA timers.
• Test the failover in a maintenance window by administratively shutting the primary uplink — not by pulling the probe target, which tests a different code path.
• Do not track the interface line protocol as a substitute. Line state tells you nothing about upstream forwarding.

Related on this site: Cisco IOS IP SLA and Object Tracking Failover fundamentals, HSRP vs VRRP vs GLBP: FHRP Configuration Compared for the first-hop redundancy alternative, and 华为路由器静态路由与默认路由配置详解 design notes for qualified next hops.

原文链接：https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/200785-ISP-Failover-with-default-routes-using-I.html