Cisco IOS IP SLA Configuration: ICMP Echo and Track Objects

When your primary WAN link goes down at the ISP side, a plain static default route keeps sending traffic into a black hole because the local interface never goes down. Cisco IOS IP SLA solves this by generating real probes - ICMP echo, UDP jitter, TCP connect - and feeding the results into track objects that can pull down a static route and trigger a backup link. This guide shows the complete IP SLA workflow on IOS/IOS-XE: define the probe, schedule it, track it, and use it for static route failover.

Background: Why Routing Alone Cannot Detect This Failure

Routing protocols detect failure through the absence of updates. A static route has no updates to lose, and a directly connected interface only goes down when the local hardware says so. That is the gap IP SLA fills.

Consider a typical branch router. Its default route points at the ISP's next hop one hop away across a fibre or Ethernet handoff. If the ISP's upstream fails, or their routing to you goes away, your local interface stays up — the Ethernet link is genuinely carrying light. Your router therefore keeps the default route installed, keeps forwarding traffic out that interface, and every packet is dropped at the other end. The symptom users report is total loss of connectivity while every interface on the router is green, which is exactly the kind of outage that wastes hours.

Service Level Agreement monitoring in IOS solves it by actively testing whether the far end actually answers. A probe sends a packet on a fixed schedule, measures the response, and updates a state machine. A track object subscribes to that state, and other features — static routes, HSRP, PBR, EEM — react to changes in it. The result is a self-healing path selection that works without a routing protocol between you and the ISP.

Three pieces are involved and it helps to keep them separate in your head:

• The operation — the probe definition (ip sla 1 plus a type such as icmp-echo) with timing parameters.
• The schedule — the ip sla schedule command that starts the operation and defines its lifetime. A probe that is configured but not scheduled sends nothing at all, which is the single most common configuration mistake.
• The track object — the glue that converts probe results into a boolean that routing and first-hop redundancy can consume.

Prerequisites and Platform Notes

• IOS 12.4 or later, or IOS-XE. Command syntax is stable across both, but on IOS-XE the ip sla configuration is unified with ip sla responder for on-box responder roles.
• A reachable probe target. For ICMP echo, any device that answers ping works — the ISP next hop, a well-known public address, or a device in your own remote site. Choose something that fails when the path fails, not when one host reboots.
• A stable source interface. Specify source-interface explicitly; omitting it lets IOS pick an address, and the probe can then break after a routing change.
• Clock. Statistics timestamps need a sane clock. If you are also tuning log destinations for the failover events, Cisco IOS logging and syslog configuration covers buffer, trap and severity settings.
• Understanding of the responder requirement. ICMP echo needs no responder. UDP jitter and most UDP operations either need an ip sla responder on the target or a Cisco device that acts as one — do not schedule a jitter probe against a device that does not support the responder and then wonder why the statistics are empty.

IP SLA ICMP Echo Operation Basics

An ICMP echo operation measures end-to-end response time between the router and any IP device. No responder is needed on the destination - a normal ping target such as the ISP next-hop works. Operations are numbered, defined in ip sla configuration mode, and must be explicitly started with ip sla schedule.

Configuring a Basic ICMP Echo Probe

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 2.2.2.2 source-interface FastEthernet0/0
R1(config-ip-sla-echo)# timeout 1000
R1(config-ip-sla-echo)# threshold 2
R1(config-ip-sla-echo)# frequency 3
R1(config-ip-sla-echo)# exit
R1(config)# ip sla schedule 1 life forever start-time now

The probe sends an ICMP echo to 2.2.2.2 every 3 seconds (frequency), waits 1000 ms (timeout) and records a reaction when the RTT exceeds 2 ms (threshold).

Each parameter deserves a second look, because the defaults are not always what you want:

• frequency sets the interval between probes. Three to five seconds is typical for failover detection. Faster detection costs more control-plane CPU and more probe traffic; a frequency of 1 second across hundreds of branches is a real load on a small router.
• timeout is how long the router waits for a reply before counting the probe as failed. It should be smaller than the frequency, otherwise probes overlap and the operation reports out-of-order results.
• threshold does not control up/down state — it drives the statistics counters for threshold violations, which you read with show ip sla statistics. Setting it to 2 ms on an internet path guarantees constant threshold breaches that mean nothing. Set it to a real service expectation (say 100 ms) if you intend to monitor it.

Tracking the Probe with a Track Object

Create a track object that follows the probe state, then tie your default route to it:

R1(config)# track 1 ip sla 1 reachability
R1(config-track)# exit
R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.1 track 1
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.1 10

While the probe answers, track 1 is up and the primary route (metric 1) is installed. When the ISP link dies at the far end, the track goes down, the primary route is removed from the RIB, and the floating backup route (metric 10) takes over. You can also use track 1 ip sla 1 state for stricter state tracking.

The difference between reachability and state matters more than it first appears. reachability asks whether the target answered recently, and it is the right choice for a link-liveness monitor. state reflects the operation's own state machine, including whether it is configured, scheduled and active. If you schedule a probe with a bounded life and forget to renew it, a state track will go down for reasons that have nothing to do with the network — a failure mode that has caused more than one midnight page.

Step-by-Step: From Probe to Automatic Failover

1. Confirm the backup path works before automating anything. Bring the backup interface up and prove it carries traffic.
2. Verify the probe target answers with an ordinary ping sourced from the intended interface: ping 2.2.2.2 source FastEthernet0/0.
3. Define and schedule the operation with ip sla 1 / icmp-echo / ip sla schedule 1 life forever start-time now.
4. Create the track object and confirm it reads Up with show track.
5. Attach it to the primary route with track 1, and add the backup route with a higher administrative distance or metric.
6. Test the failure deliberately. Shut the primary interface, or filter ICMP toward the probe target, and watch the route change. Test with the real failure mode where possible: an interface shutdown is detected by the interface itself, which does not exercise IP SLA. Blocking traffic to the probe target while the interface stays up is the honest test.
7. Tune the timers so detection time is acceptable without flooding the control plane.

That distinction in step six is the one people get wrong. If you test by shutting the interface, the static route disappears because the next hop became unreachable — IP SLA was never consulted. Only when the interface stays up and the probe stops answering does the track object do the work.

Verification Commands

R1# show ip sla configuration
R1# show ip sla statistics
R1# show track
R1# show ip route 0.0.0.0

In show track, look for Reachability is Up/Down and the latest operation return code. Other useful operation types include udp-jitter for voice-quality measurement and tcp-connect for application reachability.

Read the outputs in this order. show ip sla configuration proves the operation exists and is scheduled — check the Schedule block for Start Time and Life. show ip sla statistics proves it is actually running: look for a rising Number of successes, a current RTT, and an Operational return code of OK (anything else, such as Timeout or Internal Error, tells you the probe is not healthy). Return codes are documented by name and are the fastest way to tell "the far end is down" from "the probe is misconfigured". show track then proves the glue works, and show ip route 0.0.0.0 proves the consequence: exactly one default route should be in the table, the tracked one while the probe is healthy, the floating one after it fails.

Reaction Configuration and Event-Driven Actions

R1(config)# ip sla reaction-configuration 1 react timeout threshold-type immediate action-type trapOnly
R1(config)# ip sla logging traps
R1# show ip sla reaction-configuration

Reactions turn a probe into an event source. react timeout triggers when a probe exceeds its timeout; react rtt triggers on the threshold. The action-type decides whether IOS logs, sends SNMP traps, or starts another operation. Pairing this with EEM lets the router react to a path failure with something other than a route change — Cisco EEM applets shows the syslog-trigger pattern, and IOS can also trigger an EEM applet directly from an IP SLA reaction.

Be conservative here. A reaction configured with trapOnly is safe; a reaction that reloads interfaces on every timeout will amplify a transient blip into a service-affecting event.

Using IP SLA with First-Hop Redundancy

The same track object drives HSRP and VRRP decisions, which is where IP SLA earns most of its keep in campus and branch designs. An HSRP group that tracks the WAN-facing probe will decrement its priority when the uplink fails, letting the standby router take over the virtual IP even though the router itself is perfectly healthy. Two tracked objects combine usefully: one on the WAN reachability probe, one on the interface line protocol, so failover triggers on whichever fails first.

R1(config)# track 2 interface GigabitEthernet0/0 line-protocol
R1(config)# interface GigabitEthernet0/1
R1(config-if)# standby 1 ip 10.10.10.1
R1(config-if)# standby 1 priority 110
R1(config-if)# standby 1 preempt
R1(config-if)# standby 1 track 1 decrement 20
R1(config-if)# standby 1 track 2 decrement 20

Two decrements of 20 take the priority from 110 to 70, below the default of 100, so the peer takes over. The full configuration — priority, preempt, and the interaction between them — is covered in Cisco HSRP with priority, preempt and track. The equivalent discussion for other vendors is ArubaOS-CX VRRP and active gateway, where the track mechanism has a different name but identical intent, and Junos BFD liveness detection shows the sub-second family of liveness detection that some designs prefer over IP SLA on routed paths.

Troubleshooting: When the Probe Does Not Fail Over

• Track is always Up. Usually the probe target is reachable by an unintended path — a second default route, or a management network. Verify with show ip sla statistics that the RTT is sane and sourced from the right interface.
• Track is always Down. Check Operational return code in the statistics output. A misconfigured source-interface or a schedule that never started are the usual culprits.
• Route does not change even though the track went down. Confirm the primary route actually references the track, and that the backup route has a higher administrative distance (or an explicit metric when both are statics). Two statics with the same distance produce an equal-cost pair, not a failover.
• Probe flaps with the link. Timers are too aggressive relative to the real path jitter. Increase frequency or raise timeout and confirm the target is genuinely stable.
• Statistics are empty. The operation is not scheduled, or is on a device that requires a responder. Run show ip sla configuration and look at the Schedule block first.

FAQ

How many IP SLA operations can a router run? It varies by platform and licence; small routers support far fewer than service-provider boxes. Check the platform documentation before deploying dozens of probes at one-second frequency.

Is IP SLA the same as BFD? No. BFD is a protocol negotiated between two devices for sub-second liveness detection on a routed path. IP SLA is a one-sided active measurement toolkit that needs no cooperation from the far end for ICMP echo. Use BFD when both ends speak it; use IP SLA when they do not.

Can I track an IP SLA probe without a static route? Yes. Track objects can drive HSRP, VRRP, PBR and EEM independently of routing.

What happens if the probe target itself goes down but the path is fine? The track goes down and your failover triggers for a non-path reason. Mitigate by probing a next hop or a target on the path rather than a single end host, or by combining two operations in a track list.

Does IP SLA traffic affect link utilisation? Negligibly at typical frequencies, but account for it in QoS accounting on very small links — a 1-second probe is 86,400 packets per day per operation.

IP SLA often drives HSRP failover decisions - see Cisco HSRP with priority, preempt and track, or trigger actions on probe failure with Cisco EEM applets. For Linux equivalents see Keepalived VRRP failover setup.

原文链接：https://networklessons.com/ip-services/ip-sla-service-level-agreement-on-cisco-ios