Table of Contents Link to heading

What IP SLA Does Link to heading

Info
Cisco IP SLA (Service Level Agreement) is an active measurement technology built into IOS that continuously sends synthetic test traffic to measure network performance metrics — latency, jitter, packet loss, and reachability — without requiring a dedicated hardware probe.

The key distinction between IP SLA and passive monitoring (NetFlow, SNMP):

  • Passive monitoring measures what is happening with real traffic — but only if traffic exists and only from the router’s perspective
  • IP SLA generates its own test packets on a schedule, measuring end-to-end performance regardless of whether real user traffic is flowing

This makes IP SLA valuable for:

  • Detecting path degradation before users report it
  • Triggering routing changes when a path becomes unreachable or degrades below threshold
  • Measuring voice/video path quality (latency, jitter, MOS)
  • Verifying SLA commitments from service providers
  • Detecting WAN link failures and driving conditional failover

IP SLA Operation Types Link to heading

Operation Type Measures Protocol Use Case
ICMP Echo Reachability, round-trip latency ICMP Basic connectivity and latency
UDP Echo Reachability, latency (UDP) UDP UDP path verification
UDP Jitter Latency, jitter, packet loss, MOS score UDP VoIP and video quality measurement
TCP Connect TCP session establishment time TCP Server application reachability
HTTP HTTP GET response time, transaction time HTTP Web service availability
DNS DNS query response time DNS Name resolution performance
DHCP DHCP lease acquisition time DHCP DHCP server health
Path Jitter Per-hop latency and jitter UDP Hop-by-hop analysis

IP SLA Architecture Link to heading

An IP SLA probe consists of:

  1. IP SLA operation: The probe definition — what to measure, how often, toward what target
  2. Schedule: When to start and how long to run (continuously or for a fixed duration)
  3. Threshold: Optional — trigger an action when a metric exceeds a defined value
  4. Tracking object: Links the IP SLA state (success/failure) to a routing or FHRP decision
  5. Reaction: Optional — log, send SNMP trap, or trigger an action when threshold is crossed

IP SLA requires an IP SLA Responder on the far end for UDP Jitter and other two-way measurements. For ICMP Echo, any host that responds to ICMP will work.

Configuration Link to heading

ICMP Echo Probe Link to heading

The simplest and most common probe — tests reachability and measures RTT to a target:

! Define probe: ICMP echo to 8.8.8.8 every 10 seconds
ip sla 1
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
 threshold 500
 timeout 3000
 frequency 10

! Schedule to start immediately and run forever
ip sla schedule 1 life forever start-time now
  • threshold 500: Mark the probe as failed if RTT exceeds 500 ms
  • timeout 3000: Wait 3000 ms for a reply before declaring the probe failed
  • frequency 10: Send one probe every 10 seconds

UDP Jitter Probe (Voice Quality Measurement) Link to heading

UDP Jitter requires an IP SLA Responder on the target device and provides the most detailed measurements — including per-direction latency, jitter, and an estimated MOS score for voice quality:

! On the source router
ip sla 2
 udp-jitter 10.1.1.1 5000 source-port 5001 num-packets 100 interval 20
 tos 184               ! DSCP EF (0xb8 = 184) — simulate voice traffic
 threshold 50
 frequency 60

ip sla schedule 2 life forever start-time now

! On the target router — enable IP SLA Responder
ip sla responder

Parameters:

  • 10.1.1.1 5000: Target IP and UDP port
  • num-packets 100: Send 100 packets per probe
  • interval 20: 20 ms between packets (simulates G.711 codec at 50 pps)
  • tos 184: Set DSCP EF to measure the voice-class path

HTTP Probe Link to heading 

ip sla 3
 http get http://10.1.1.100/index.html source-interface GigabitEthernet0/0
 threshold 5000
 frequency 60

ip sla schedule 3 life forever start-time now

The HTTP probe measures the full transaction time — TCP connection + HTTP GET + response received — providing end-to-end web application response time.

DNS Probe Link to heading 

ip sla 4
 dns 8.8.8.8 name-server 8.8.4.4
 frequency 30

ip sla schedule 4 life forever start-time now

IP SLA with Object Tracking Link to heading

The most operationally valuable use of IP SLA is combining it with object tracking to drive automatic routing changes based on measured reachability:

Conditional Static Routes (Floating Routes) Link to heading

A tracked static route is installed only when its tracked IP SLA probe is in the up state. If the probe fails, the route is withdrawn — and a floating static route with a higher administrative distance takes over:

! IP SLA probe to primary ISP gateway
ip sla 10
 icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0
 frequency 5

ip sla schedule 10 life forever start-time now

! Track the IP SLA probe state
track 10 ip sla 10 reachability

! Primary default route — installed only when track 10 is up
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 10

! Secondary default route (floating) — higher AD, used when primary is down
ip route 0.0.0.0 0.0.0.0 198.51.100.1 5

When the probe to 203.0.113.1 fails, track 10 transitions to down, the primary default route is withdrawn from the routing table, and the floating static route with AD 5 takes over — automatically failing over to the secondary ISP.

HSRP Failover Triggered by IP SLA Link to heading

Combine IP SLA with HSRP interface tracking to fail over the gateway role when the active router’s WAN path is degraded:

! Probe toward upstream next-hop
ip sla 20
 icmp-echo 203.0.113.1
 frequency 5

ip sla schedule 20 life forever start-time now

track 20 ip sla 20 reachability

! Decrement HSRP priority when WAN probe fails
interface GigabitEthernet0/1
 standby 1 ip 10.10.10.1
 standby 1 priority 120
 standby 1 preempt
 standby 1 track 20 decrement 30

If the IP SLA probe fails, HSRP priority drops from 120 to 90 — below the standby’s 100 — triggering failover to the router with the functional WAN path.

Dual-ISP Failover with IP SLA Link to heading

Example

A branch router with two ISP connections (primary MPLS + backup internet):

! Probe to MPLS provider PE
ip sla 1
 icmp-echo 10.0.0.1 source-interface GigabitEthernet0/0
 frequency 5
 timeout 2000

ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability

! Primary route via MPLS (AD 1, installed when probe is up)
ip route 0.0.0.0 0.0.0.0 10.0.0.1 track 1

! Backup route via internet (AD 10, takes over when MPLS probe fails)
ip route 0.0.0.0 0.0.0.0 203.0.113.254 10

With this configuration:

  • Normal operation: all traffic exits via MPLS
  • MPLS failure (probe to 10.0.0.1 fails): primary route is withdrawn, internet backup activates within 5–10 seconds
  • MPLS recovery: primary route is reinstalled, traffic returns to MPLS

IP SLA Responder Link to heading

The IP SLA Responder is a feature enabled on a target Cisco device that allows it to respond accurately to UDP-based IP SLA probes. For ICMP probes, any device responds — no configuration needed. For UDP Jitter and UDP Echo probes:

! On the responder device
ip sla responder

! Or for a specific UDP port
ip sla responder udp-echo ipaddress 10.1.1.1 port 5000

The Responder timestamps both the arrival and departure of probe packets with hardware-level precision, enabling the source router to calculate one-way delay accurately — more precise than using software timestamps only.

Note
Without a Responder, UDP jitter probes cannot be used. The Responder must be enabled on the far-end device before the source schedules the probe. In multi-vendor environments where the far end is not Cisco, use ICMP echo probes instead.

Verification and Interpreting Results Link to heading 

! Check all configured SLA operations and their current state
show ip sla summary

! Detailed statistics for a specific operation
show ip sla statistics 1

! Historical statistics (aggregated)
show ip sla statistics 1 aggregated

! UDP Jitter specific — detailed per-direction metrics
show ip sla statistics 2

! Object tracking state
show track 10
show track brief

Key metrics in show ip sla statistics:

Metric Description Threshold guideline
RTT (Round-trip time) End-to-end latency for the probe < 150 ms for voice paths
Jitter (source-to-dest) Variation in one-way delay < 30 ms for VoIP
Packet loss Percentage of probes that received no response < 1% for voice
MOS score Mean Opinion Score (1–5, estimated from jitter/loss) > 3.5 for acceptable voice
Success/Return code Whether the last probe succeeded OK = passing, any other = failing

Operational Use Cases Link to heading

WAN failover: The most common production use — track reachability of the upstream ISP or MPLS PE, drive conditional static route withdrawal on failure.

VoIP path quality: UDP Jitter probes on voice paths provide continuous MOS monitoring. Configure ip sla react to generate SNMP traps when MOS drops below 3.5, enabling proactive alerting before users report call quality issues.

Service provider SLA verification: Run continuous ICMP or UDP Jitter probes toward the provider-managed CE or toward the far-end site. Use show ip sla statistics aggregated to produce hourly/daily statistics for SLA compliance reporting.

Application availability: TCP Connect probes to server ports verify that an application is actually accepting connections, not just that the IP is reachable. A server responding to ICMP but not to TCP/443 indicates an application failure, not a network failure.