There’s a particular kind of network outage that’s worse than a full link failure — the “it’s slow but not down” kind, where users complain and you have no hard data to point to. That’s exactly the problem IP SLA was built to solve, and once I started using it properly, half my “is it the network?” debates ended in minutes instead of hours because I finally had numbers instead of guesses. This guide walks through IP SLA from the ground up: what it measures, how to configure it, and how to actually use the data it gives you.
What IP SLA Is and Why It Exists
Cisco IOS IP SLA (formerly known as Service Assurance Agent, SAA) is a feature built into Cisco routers and switches that actively generates synthetic traffic to measure network performance metrics: latency, jitter, packet loss, availability, and even application-layer response times like HTTP or DNS. Unlike passive monitoring tools that only see traffic that already exists, IP SLA proactively probes the network on a schedule you define, which means you get consistent, comparable measurements over time — exactly what you need for capacity planning, SLA verification with an ISP, or triggering automatic failover.
Networking Fundamentals: How IP SLA Operations Work
An IP SLA configuration is built around a few core concepts:
- Operation (probe) type: Defines what kind of traffic is generated and measured — ICMP echo, UDP jitter, TCP connect, HTTP, DNS, and many others.
- Source and target: The router where the operation runs (the “source”) and the device or IP being tested (the “target,” sometimes called the “responder”).
- Responder: For advanced operations like UDP jitter, the target Cisco device runs an IP SLA Responder process that timestamps packets to give more accurate one-way and round-trip statistics than a plain ping could.
- Scheduling: Operations run on a schedule — continuously, at intervals, or for a fixed lifetime — and store historical statistics you can query later.
- Track objects: IP SLA integrates with Enhanced Object Tracking (EOT), letting you tie a route, next-hop, or interface state to the result of an SLA operation — this is how you build automatic failover based on real reachability testing rather than just “is the interface up.”
Step 1: Basic ICMP Echo Operation
This is the simplest operation — essentially an automated, continuously logged ping.
Router(config)# ip sla 1
Router(config-ip-sla)# icmp-echo 203.0.113.1 source-interface GigabitEthernet0/1
Router(config-ip-sla-echo)# frequency 30
Router(config-ip-sla-echo)# timeout 5000
Router(config-ip-sla-echo)# exit
Router(config)# ip sla schedule 1 life forever start-time now
This probes 203.0.113.1 every 30 seconds from GigabitEthernet0/1, indefinitely.
Step 2: UDP Jitter Operation for Voice/Video Quality Monitoring
If you’re supporting VoIP or video conferencing, latency alone doesn’t tell the whole story — jitter and packet loss matter just as much. This requires an IP SLA Responder on the target device.
On the target router:
Router(config)# ip sla responder
On the source router:
Router(config)# ip sla 2
Router(config-ip-sla)# udp-jitter 10.1.2.1 16400 source-interface GigabitEthernet0/1
Router(config-ip-sla-jitter)# frequency 60
Router(config-ip-sla-jitter)# exit
Router(config)# ip sla schedule 2 life forever start-time now
Step 3: HTTP Operation for Application-Layer Monitoring
Router(config)# ip sla 3
Router(config-ip-sla)# http get http://10.1.3.10/health
Router(config-ip-sla-http)# frequency 120
Router(config-ip-sla-http)# exit
Router(config)# ip sla schedule 3 life forever start-time now
This is genuinely useful for confirming that an application isn’t just pingable but actually responding correctly at Layer 7.
Step 4: TCP Connect Operation
Useful for confirming a specific service port is reachable, without needing a full HTTP transaction.
Router(config)# ip sla 4
Router(config-ip-sla)# tcp-connect 10.1.4.5 443 source-interface GigabitEthernet0/1
Router(config-ip-sla-tcp)# frequency 30
Router(config-ip-sla-tcp)# exit
Router(config)# ip sla schedule 4 life forever start-time now
Step 5: Tying IP SLA to Object Tracking for Automatic Failover
This is where IP SLA earns its keep in production networks — using a probe result to drive routing decisions.
Router(config)# track 10 ip sla 1 reachability
Router(config-track)# delay down 10 up 5
Router(config-track)# exit
Router(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 10
Router(config)# ip route 0.0.0.0 0.0.0.0 198.51.100.1 250
Here, the primary default route is installed only while track object 10 (backed by IP SLA operation 1) reports the primary gateway as reachable. If it fails, the route is withdrawn and the higher administrative-distance backup route takes over automatically — a clean, hardware-based failover mechanism that doesn’t rely on a routing protocol convergence process.
Step 6: Verifying IP SLA Operations
Router# show ip sla configuration 1
Router# show ip sla statistics 1
Router# show ip sla statistics aggregated 1
Router# show track 10
Expected output from show ip sla statistics 1:
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest RTT: 24 milliseconds
Latest operation start time: 14:32:10 UTC Wed Jul 29 2026
Latest operation return code: OK
Number of successes: 118
Number of failures: 2
Operation time to live: Forever
And show track 10:
Track 10
IP SLA 1, reachability
Reachability is Up
3 changes, last change 00:12:44
Delay up 5 secs, down 10 secs
These two commands together tell you almost everything you need: is the target reachable, what’s the round-trip time trend, and is the tracked object currently influencing routing.
Practical Lab: Dual-ISP Failover with IP SLA
Build a lab with a branch router connected to two ISPs — a primary fiber link and a backup LTE/broadband link. Goal: automatically fail over the default route if the primary ISP’s gateway (or, better, a reliable upstream target like the ISP’s next hop or a public anycast address) becomes unreachable.
Router(config)# ip sla 1
Router(config-ip-sla)# icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0
Router(config-ip-sla-echo)# frequency 10
Router(config-ip-sla-echo)# threshold 200
Router(config-ip-sla-echo)# timeout 1000
Router(config-ip-sla-echo)# exit
Router(config)# ip sla schedule 1 life forever start-time now
Router(config)# track 1 ip sla 1 reachability
Router(config-track)# delay down 6 up 10
Router(config-track)# exit
Router(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1
Router(config)# ip route 0.0.0.0 0.0.0.0 198.51.100.1 200
A frequency 10 with timeout 1000 gives you fast detection, while the delay down 6 on the track object avoids flapping on a single missed probe — a balance every good failover design needs.
Real-World Enterprise Scenario
At a retail company with dozens of branch sites, the network team needed hard evidence for an ISP SLA dispute over “guaranteed” latency and packet loss figures. Instead of relying on anecdotal complaints, they deployed IP SLA UDP jitter operations from every branch router to a central hub, logging statistics continuously and exporting them via SNMP to a monitoring platform. When the data consistently showed latency spikes exceeding the ISP’s contracted threshold during business hours, it became a documented, timestamped case rather than a subjective argument — and led to real compensation credits from the provider.
Security Best Practices
- Restrict which source interfaces and target IPs are used in operations — don’t probe arbitrary external addresses that could be mistaken for reconnaissance or abuse traffic.
- If exposing an IP SLA Responder, be aware it listens for control messages on UDP 1967 by default; restrict access with ACLs on devices facing untrusted networks.
- Avoid overly aggressive probe frequencies on low-bandwidth or metered WAN links (e.g., LTE failover circuits), since probes themselves consume bandwidth and, on metered links, cost money.
- Use authentication for IP SLA control messages where supported, particularly across WAN links you don’t fully control.
Optimization and Performance Tuning
- Match probe frequency to the actual detection requirement — a 10-second frequency makes sense for a critical failover link, but a 300-second frequency is plenty for general trend monitoring on a stable circuit.
- Use
thresholdandtimeoutvalues deliberately; a threshold too close to normal baseline RTT will generate noisy, false “over-threshold” events. - For failover scenarios, tune
trackdelay up/down timers to balance fast failover against flap protection — I generally start withdelay down 10 up 20and adjust based on observed link behavior. - Aggregate statistics using
ip sla statistics aggregationand appropriate history retention config, rather than only relying on the latest single sample, to see meaningful trends instead of noise.
Troubleshooting and Common Mistakes
- Forgetting
ip sla schedule: A very common beginner mistake — the operation is configured but never actually starts running because the schedule command was skipped. - Missing responder on UDP jitter targets: Without
ip sla responderon the target, jitter measurements will be inaccurate or the operation will fail outright. - Using the wrong source-interface: If your probe source interface doesn’t match the actual egress path for real traffic, your measurements won’t reflect reality.
- Track object not referenced anywhere: Configuring
trackwithout attaching it to a route, interface, or other action means it’s collecting data but not actually doing anything. - Clock/time sync issues affecting jitter accuracy: For two-way active measurement without responder timestamps being trusted, ensure NTP is properly synchronized on both ends.
Frequently Asked Questions
Does IP SLA generate real user traffic or synthetic traffic? Synthetic — it’s purpose-built probe traffic, not a sample of actual application traffic, though operation types like HTTP get can closely mimic real application behavior.
Can IP SLA run on switches, or only routers? Many Cisco Catalyst switches support IP SLA as well, though the available operation types can be more limited than on ISR/ASR routers depending on the platform and IOS/IOS-XE version.
How is IP SLA different from just scripting pings? IP SLA integrates natively with IOS features like Enhanced Object Tracking, SNMP MIBs, and historical statistics storage, and can measure things a simple ping can’t, like jitter, one-way delay (with proper time sync), and application-layer response codes.
What’s a reasonable probe frequency for a production WAN failover design? This depends on your tolerance for false positives versus detection speed, but many enterprises land between 5 and 15 seconds for critical failover links, paired with sensible track delay timers to avoid flapping.
Summary
IP SLA turns “I think the network is fine” into “here’s the measured latency, jitter, and packet loss over the last 24 hours.” Configuring it well means choosing the right operation type for what you’re actually trying to measure, scheduling it properly, and — when it matters most — tying it into Enhanced Object Tracking so your router can react automatically to real reachability and performance problems instead of just logging them. Once you have this running across your critical paths, performance conversations with ISPs, application teams, and management get a lot more grounded in fact.
References
- Cisco IOS IP SLAs Configuration Guide, cisco.com/c/en/us/support/ios-nx-os-software
- Cisco IOS IP SLAs Command Reference —
ip sla,ip sla responder,ip sla schedule,track - Cisco documentation on Enhanced Object Tracking (EOT)