Skip to content
Log in Sign up My account

4.4 IP SLA

Blueprint 4.4: Configure and verify IPSLA

  • What IP SLA operations measure, and which operations need a responder
  • ICMP echo, UDP jitter and other operation types
  • Scheduling: frequency, timeout, threshold, life
  • Object tracking: reachability versus state, delays
  • Using a tracked IP SLA with static routes and HSRP
  • Verification with show ip sla and show track

The verb is configure and verify. The classic exam scenario is a dual-ISP router whose default route must fail over when the ISP stops forwarding, even though the link stays up.

What IP SLA does

IP SLA (Service Level Agreement) makes the router generate synthetic test traffic on a schedule and record the results. Because the traffic is generated rather than observed, you can measure a path before users complain, and you can measure it continuously.

graph LR
  SRC["Source router<br/>ip sla 10 operation"] -->|"probe"| TGT["Target<br/>any host, or a router with ip sla responder"]
  TGT -->|"reply"| SRC
  SRC --> RES["Results:<br/>RTT, loss, jitter, return code"]
  RES --> TRK["track object"]
  TRK --> USE["static route, HSRP, EEM"]

Operation types

Operation Measures Needs responder
icmp-echo Round-trip time, reachability No
path-echo RTT hop by hop No
udp-echo RTT using UDP Optional (more accurate with one)
udp-jitter One-way delay, jitter, packet loss, MOS with a codec Yes
tcp-connect Time to complete a TCP handshake No for well-known ports; yes for arbitrary ports
http DNS, TCP connect and transaction time for an HTTP GET No
dns Name resolution time No
dhcp Time to obtain a lease No

The responder

R2(config)# ip sla responder

The responder is an IOS component on the target router. The source sends a control message to the responder on UDP port 1967 asking it to open the test port, then sends the probes. The responder timestamps each probe on arrival and departure, so the source can subtract the responder's processing time and calculate one-way values. One-way delay is only accurate when both routers' clocks are synchronized with NTP.

Exam trap

Jitter and one-way loss need two ends. A question that asks for jitter measurement wants udp-jitter on the source and ip sla responder on the target. icmp-echo cannot measure jitter.

Configuring an operation

ip sla 10
 icmp-echo 203.0.113.1 source-interface GigabitEthernet1
 frequency 10
 timeout 2000
 threshold 500
 tag ISP-A-NEXT-HOP
!
ip sla schedule 10 life forever start-time now
Parameter Meaning Default
frequency Seconds between probes 60 seconds
timeout Milliseconds to wait for a reply before the probe counts as failed 5000 ms
threshold RTT in milliseconds above which the result is "Over threshold" 5000 ms
life in ip sla schedule How long the operation runs 3600 seconds
start-time When it starts Pending (not started) until set

A scheduled operation cannot be edited. To change it, remove it with no ip sla 10, configure it again and reschedule it. The track object that references it survives and picks up the new operation.

The timeout must not exceed the frequency. Use timeout lower than frequency, and threshold lower than or equal to timeout.

Exam trap

An operation that is configured but never scheduled does nothing. An operation scheduled without life forever stops after one hour, and anything tracking it goes down at that point. Both show up as "the failover worked in the lab and broke later".

UDP jitter

R1(config)# ip sla 20
R1(config-ip-sla)# udp-jitter 10.255.255.2 16384 source-ip 10.255.255.1 codec g711ulaw
R1(config-ip-sla-jitter)# tos 184
R1(config-ip-sla-jitter)# frequency 30
R1(config)# ip sla schedule 20 life forever start-time now
!
R2(config)# ip sla responder

Without a codec, the operation sends 10 packets at 20 ms intervals by default (num-packets and interval change that). With codec g711ulaw it emulates a voice stream and also reports MOS and ICPIF scores. tos 184 marks the probes EF so they test the voice queue, not best effort.

Return codes and tracking

Every probe ends with a return code. The important ones are OK, Timeout and Over threshold. A track object turns those results into an up or down state that other features can react to.

track 1 ip sla 10 reachability
 delay down 10 up 30
Track type Up when the return code is Down when
reachability OK or Over threshold Timeout or other failure
state OK only Over threshold, Timeout or other failure

delay down 10 up 30 waits 10 seconds of continuous failure before declaring the object down, and 30 seconds of success before declaring it up again. This damps flapping when a link is marginal.

Exam trap

With state, a slow but working path (RTT above the threshold) is treated as down. With reachability it stays up. If a question says the route failed over even though the ISP still answered pings, look for state combined with a low threshold.

Using the track object

Default route failover

graph LR
  R1["R1"] -- "Gi1 203.0.113.2/30 primary" --- ISPA["ISP-A 203.0.113.1"]
  R1 -- "Gi2 198.51.100.2/30 backup" --- ISPB["ISP-B 198.51.100.1"]
  ISPA --- NET["Internet"]
  ISPB --- NET
ip sla 10
 icmp-echo 8.8.8.8 source-interface GigabitEthernet1
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now
!
track 1 ip sla 10 reachability
 delay down 10 up 30
!
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1
ip route 0.0.0.0 0.0.0.0 198.51.100.1 10
ip route 8.8.8.8 255.255.255.255 203.0.113.1

The primary default route is only installed while track 1 is up. The backup is a floating static route with administrative distance 10, so it is ignored while the AD 1 route exists and installs automatically when the primary is withdrawn.

The /32 host route for 8.8.8.8 is the subtle part. Probing a target beyond the ISP (rather than the next hop) proves the ISP is actually forwarding. But when the primary default route is removed, the probe to 8.8.8.8 would follow the backup default route out Gi2. source-interface sets only the source address, not the exit path. If the probe can succeed through ISP-B (for example because no source interface is set, so the probe is sourced from Gi2's address), the track comes back up, the primary route is reinstalled, the probe fails again, and the route flaps. Pinning the probe target to the primary next hop with a host route makes the probe test only the primary path.

Exam trap

Without IP SLA, a static route to a next hop on an Ethernet link stays in the table as long as the interface is up, even if the ISP's router is dead or its upstream has failed. That is the whole reason for the tracked route.

HSRP

interface GigabitEthernet3
 standby 1 ip 10.10.10.1
 standby 1 priority 110
 standby 1 preempt
 standby 1 track 1 decrement 20

If the probe fails, R1's priority drops from 110 to 90, the peer with priority 100 preempts (if it has preempt), and users move to the router with a working uplink.

Verification

R1# show ip sla configuration 10
IP SLAs Infrastructure Engine-III
Entry number: 10
Owner:
Tag: ISP-A-NEXT-HOP
Operation timeout (milliseconds): 2000
Type of operation to perform: icmp-echo
Target address/Source interface: 203.0.113.1/GigabitEthernet1
...
Schedule:
   Operation frequency (seconds): 10  (not considered if randomly scheduled)
   Next Scheduled Start Time: Start Time already passed
   Life (seconds): Forever
Threshold (milliseconds): 500

R1# show ip sla statistics 10
IPSLAs Latest Operation Statistics

IPSLA operation id: 10
        Latest RTT: 2 milliseconds
Latest operation start time: 10:15:32 UTC Wed Oct 7 2026
Latest operation return code: OK
Number of successes: 25
Number of failures: 0
Operation time to live: Forever

R1# show track 1
Track 1
  IP SLA 10 reachability
  Reachability is Up
    3 changes, last change 00:02:11
  Delay up 30 secs, down 10 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 2
  Tracked by:
    Static IP Routing 0

R1# show ip route static | include 0.0.0.0
S*    0.0.0.0/0 [1/0] via 203.0.113.1

After a failure the same command shows S* 0.0.0.0/0 [10/0] via 198.51.100.1. The AD in brackets tells you which route is active.

Command Use
show ip sla summary One line per operation with the last return code and RTT
show ip sla statistics 20 details Jitter, loss and MOS for a udp-jitter operation
show ip sla responder On the target: proves the responder is enabled and receiving
show track brief All track objects and their states
debug ip sla trace 10 Probe-by-probe detail (conditional-style: one operation only)

Lab: dual-ISP failover with a tracked default route

Topology: R1 (Catalyst 8000v) with Gi1 to ISP-A (IOSv) and Gi2 to ISP-B (IOSv). Both ISPs connect to an INTERNET router (IOSv) with Loopback0 8.8.8.8/32. Use the addresses in the diagram above; ISP-A to INTERNET is 10.100.1.0/30 and ISP-B to INTERNET is 10.100.2.0/30, each ISP has a static default to INTERNET, and INTERNET has static routes back to 203.0.113.0/30 and 198.51.100.0/30.

  1. Configure the IP SLA, track and static routes from the failover example on R1.
  2. Check show ip route static (primary via 203.0.113.1) and show track 1 (Up).
  3. On ISP-A, shut the link to INTERNET (not the link to R1). R1 Gi1 stays up.
  4. Watch show track 1 go Down after about 10 seconds, and show ip route static switch to [10/0] via 198.51.100.1. Run ping 8.8.8.8 repeat 1000 from R1 during the failure and count the lost packets.
  5. Restore ISP-A. The primary returns 30 seconds after the probe succeeds again.
  6. Remove ip route 8.8.8.8 255.255.255.255 203.0.113.1. Then try to remove source-interface from operation 10 and read the error: a scheduled operation cannot be edited. Delete it with no ip sla 10, recreate it as icmp-echo 8.8.8.8 with no source interface, and schedule it again. Repeat step 3 and watch the change count in show track 1 climb as the route flaps. Explain why, then restore the original configuration.
  7. Change the track to track 1 ip sla 10 state and set threshold 1 under the operation. Notice the track goes down even though the probe succeeds (Over threshold). Put it back.
  8. Add ip sla responder on INTERNET and a udp-jitter operation from R1 to 8.8.8.8 port 16384. Read show ip sla statistics 20 details.

Expected verification after step 4:

R1# show ip sla statistics 10 | include return code|failures
Latest operation return code: Timeout
Number of failures: 4
R1# show track 1 | include Reachability
  Reachability is Down

For a timed exercise that combines this with Flexible NetFlow, do Sim 09. The HSRP sim uses object tracking with FHRP.

Quick check

A track object uses ip sla 10 state. The probe returns Over threshold. Is the object up or down?

Down. state is up only on OK. With reachability it would be up, because Over threshold still means a reply was received.

Which operation and which target-side command measure jitter for voice?

udp-jitter (ideally with a codec and tos 184) on the source, and ip sla responder on the target.

Failover works in the lab but an hour later the default route moves to the backup ISP with no fault. What is the likely cause?

The operation was scheduled without life forever. The default life is 3600 seconds, so the operation stops, the track object goes down and the tracked route is withdrawn.

References