IP SLA Tracking: The Brownout a Floating Route Cannot See
A failover that never happens, because the interface never goes down. Diagnose the missing IP SLA track and fix it yourself, live, right below.
Symptom
The interface stays up, so the primary route never withdraws and the backup never installs. The site is offline while the routing table looks exactly as it was designed to look.
Your mission
Prove the cause, then fix it
Format
Guided CLI investigation
Investigate before you configure.
Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.
Observe the symptom and link state.
Diagnose by comparing the protocol evidence.
Verify the expected device state and confirm the original symptom is resolved.
Console access: R1
This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.
Need a hint?
Reveal the root cause when you're ready.
Try the investigation first, then use this as your escape hatch, not a dead end.
Lab debrief
Turn the session into a repeatable troubleshooting pattern.
Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.
The problem
R1 has a primary default route via ISP-A and a floating backup via ISP-B at administrative distance 200. ISP-A is having a brownout beyond its own first hop. Gi0/0 is up, the primary route is still installed, the backup has not taken over, and the site is offline.
What you'll practice
- Recognise a failure the local interface state cannot detect
- Use a two-ping test to separate first-hop health from end-to-end reachability
- Build an IP SLA probe and schedule it
- Chain a tracked object to a static route so failover actually happens
1. Why the floating route did not float
A static route without tracking is withdrawn only when its outgoing interface goes down. A brownout beyond the first hop never touches the local link, so the route stays installed and the backup, being worse, stays out. You will learn to recognise that shape of failure immediately.
2. The two-ping test
Pinging the ISP's own interface and then something beyond it separates local health from end-to-end reachability in about ten seconds. You will use it here and it generalises to almost every upstream problem.
3. Three objects, each inert alone
The probe measures, the tracked object interprets, and the route obeys. You will deliberately build only part of the chain twice and see nothing happen, which is exactly how this is usually misconfigured in the field.
The topology
R1 has a primary ISP-A link on Gi0/0 (next hop 10.0.1.2) and a backup ISP-B link on Gi0/1 (next hop 10.0.2.2) carrying a floating default route at distance 200.
Commands to run yourself
The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.
show ip routeping 10.0.1.2ping 8.8.8.8Topology diagram
Frequently asked
Why did the floating static route not take over?
Because nothing withdrew the primary. A static route without tracking is only removed when its outgoing interface goes down, and the local link is perfectly healthy here; the fault is further upstream. The backup has a worse administrative distance, so as long as the primary remains in the table the backup stays out of it, which is exactly the behaviour you asked for when you configured it.
Why does the IP SLA need scheduling separately?
The ip sla block only defines the operation. It does not start it, and an unscheduled operation never runs even once, so it never reports a result and any object tracking it stays Up. show ip sla statistics reports that the operation has not started, and forgetting this step is the single most common reason people believe IP SLA tracking does not work.
Why specify a source-interface on the probe?
So the probe keeps testing the path you intend. Without it the probe may be sourced from whichever interface the routing table currently prefers, which after a failover is the backup link. The probe would then start succeeding over the backup and flap the primary route back in, giving you an oscillation instead of a failover.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.