IP SLA Configuration & Tracking

A router's routing table reflects the state of directly connected interfaces — but it has no visibility into what happens beyond the next hop. A static default route pointing to an ISP gateway stays in the routing table even after the ISP's upstream circuit fails, because the local interface is still up. Traffic silently blackholes. IP SLA (Service Level Agreement) solves this: it sends continuous active probes — ICMP echoes, TCP connections, HTTP requests, DNS queries — to any reachable target and reports whether that target responds within acceptable parameters.

Object Tracking is the bridge between IP SLA measurements and network actions. It watches an IP SLA operation and exposes its state — Up or Down — to other IOS features. When IP SLA declares a target unreachable, the tracked object transitions to Down, which can automatically remove a static route from the routing table, reduce an HSRP router's priority to trigger a failover, or trigger an EEM script. When the target recovers, the object returns to Up and the route or priority is restored — all without any administrative intervention.

Before starting, ensure you understand static routing from Static Route Configuration and HSRP from HSRP (First Hop Redundancy). For reading the routing table after tracked routes are installed or removed, see show ip route. IP SLA with syslog alerting (EEM integration) builds on the concepts here and is covered in IP SLA Syslog Alerting. For the broader context of route sources and administrative distance, see Administrative Distance and Route Sources.

1. IP SLA & Object Tracking — Core Concepts

How IP SLA Works

  IP SLA Architecture — Three Layers:

  ┌──────────────────────────────────────────────────────────────────┐
  │  Layer 1: IP SLA Operation                                       │
  │  Sends probes at a configured interval to a target               │
  │  ip sla 1                                                        │
  │   icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0         │
  │   frequency 10                                                   │
  │  ip sla schedule 1 life forever start-time now                   │
  │                           │                                      │
  │                    Probe every 10s                               │
  │                    ↓ 8.8.8.8 responds?                          │
  │                    YES → Operation state: Over Threshold (OK)    │
  │                    NO  → Operation state: Under Threshold (FAIL) │
  └──────────────────────────────────────────────────────────────────┘
                              │
                              ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │  Layer 2: Object Tracking                                        │
  │  Watches the IP SLA operation state and exposes Up/Down          │
  │  track 1 ip sla 1 reachability                                   │
  │                                                                  │
  │  SLA OK  → Track state: Up                                       │
  │  SLA FAIL → Track state: Down                                    │
  └──────────────────────────────────────────────────────────────────┘
                              │
                              ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │  Layer 3: Tracked Action                                         │
  │  IOS feature reacts to the tracked object state                  │
  │                                                                  │
  │  Option A — Floating static route:                               │
  │  ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1                   │
  │  Track Up   → route is in the routing table                      │
  │  Track Down → route is REMOVED from the routing table            │
  │                                                                  │
  │  Option B — HSRP priority decrement:                             │
  │  standby 1 track 1 decrement 20                                  │
  │  Track Up   → HSRP priority = configured value (e.g., 110)       │
  │  Track Down → HSRP priority = 110 - 20 = 90 (triggers failover)  │
  └──────────────────────────────────────────────────────────────────┘

IP SLA Probe Types

Probe Type	IOS Command	What It Tests	Common Use
ICMP Echo	`icmp-echo [target-IP]`	Round-trip reachability to any IP — like a continuous automated ping	Most common — tests ISP gateway, WAN endpoint, or any critical host
TCP Connect	`tcp-connect [IP] [port]`	Full TCP three-way handshake to a specific port — tests application layer availability	Verify a web server (port 80/443) or SMTP relay (port 25) is accepting connections
UDP Jitter	`udp-jitter [IP] [port]`	Sends UDP packets and measures jitter, latency, and packet loss — requires a Responder on the target	Voice/video quality monitoring — detect jitter before it impacts calls
HTTP	`http get [url]`	Full HTTP GET transaction — tests DNS, TCP, and HTTP response time	End-to-end web application monitoring from the router's perspective
DNS	`dns [hostname] name-server [IP]`	DNS resolution test — measures query response time	Verify DNS server availability and response time
Path Echo	`path-echo [target-IP]`	Like ICMP echo but discovers and tests each hop along the path — similar to traceroute	WAN path monitoring — detect which hop in the path is failing

IP SLA Key Parameters

Parameter	Command	Default	Description
Frequency	`frequency [seconds]`	60 seconds	How often the probe is sent. Lower = faster failure detection but more overhead
Timeout	`timeout [milliseconds]`	5000 ms	How long to wait for a response before marking the probe as failed
Threshold	`threshold [milliseconds]`	5000 ms	RTT threshold — probes over this value are counted as "over threshold" violations
Delay Down	`delay down [seconds]` (on track)	0 seconds	How long the SLA must be failing before the tracked object transitions to Down — prevents flapping
Delay Up	`delay up [seconds]` (on track)	0 seconds	How long the SLA must be succeeding before the tracked object returns to Up — prevents premature recovery

Object Tracking — What Can Be Tracked

Track Type	Syntax	Transitions Down When
IP SLA reachability	`track [id] ip sla [sla-id] reachability`	IP SLA probe does not receive a response (target unreachable)
IP SLA state	`track [id] ip sla [sla-id] state`	IP SLA operation result transitions from OK to Over Threshold
Interface line-protocol	`track [id] interface [int] line-protocol`	The tracked interface goes down at Layer 1 or Layer 2. See show interfaces.
Interface IP routing	`track [id] interface [int] ip routing`	IPv4 routing is disabled on the interface or the interface is down
Route reachability	`track [id] ip route [prefix/mask] reachability`	The specified prefix disappears from the routing table

2. Lab Topology & Scenario

This lab covers two real-world IP SLA use cases on a dual-ISP enterprise edge router. NetsTuts_R1 has two WAN connections — a primary ISP (ISP-A) and a backup ISP (ISP-B). IP SLA probes monitor reachability through each ISP. Object tracking ties the probe results to floating static routes and HSRP priority, enabling fully automatic failover without any manual intervention or dynamic routing protocol on the WAN.

                                NetsTuts_R1
              ┌──────────────────────────────────────────────┐
              │                                              │
  [LAN]───────┤ Gi0/0                    Gi0/1 (Primary WAN) ├─── ISP-A
  10.0.0.0/24 │ 10.0.0.1/24      203.0.113.1/30             │    203.0.113.2
              │                  GW: 203.0.113.2             │    Probes 8.8.8.8
              │                                              │
              │                  Gi0/2 (Backup WAN) ─────────┤─── ISP-B
              │                  198.51.100.1/30             │    198.51.100.2
              │                  GW: 198.51.100.2            │    Probes 8.8.4.4
              └──────────────────────────────────────────────┘
                         │
                         │ Gi0/3 (LAN — HSRP active)
                         │ 10.0.0.1/24
                    ─────┴─────
                         │
               [NetsTuts_R2] (HSRP standby)
               10.0.0.2/24

  IP SLA Operations:
  SLA 1 → icmp-echo 8.8.8.8 via Gi0/1  (probes through ISP-A)
  SLA 2 → icmp-echo 8.8.4.4 via Gi0/2  (probes through ISP-B)

  Object Tracking:
  Track 1 → watches SLA 1 (ISP-A reachability)
  Track 2 → watches SLA 2 (ISP-B reachability)

  Tracked Actions:
  A: Floating static routes — primary via ISP-A (AD 1), backup via ISP-B (AD 5)
     Track 1 Down → primary route removed → backup route takes over
  B: HSRP tracking — R1 priority decrement on ISP-A failure
     Track 1 Down → R1 HSRP priority drops → R2 becomes active gateway

Element	Detail	Purpose
IP SLA 1	ICMP echo to 8.8.8.8 via Gi0/1, every 10s	Monitors reachability through ISP-A primary WAN
IP SLA 2	ICMP echo to 8.8.4.4 via Gi0/2, every 10s	Monitors reachability through ISP-B backup WAN
Track 1	Monitors SLA 1 reachability, delay down 15s	Provides stable Up/Down state for ISP-A
Track 2	Monitors SLA 2 reachability, delay down 15s	Provides stable Up/Down state for ISP-B
Primary default route	0.0.0.0/0 via 203.0.113.2, AD 1, track 1	Active when ISP-A is reachable
Backup floating static route	0.0.0.0/0 via 198.51.100.2, AD 5, track 2	Active only when ISP-A fails and ISP-B is reachable

3. Step 1 — Configure Interfaces

All interfaces must be up and IP reachable before IP SLA probes can be started. IP SLA uses the routing table to source its probe packets — the interface and next-hop must be reachable. See Basic Interface Configuration for interface setup fundamentals:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── LAN interface ────────────────────────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#description LAN-Segment
NetsTuts_R1(config-if)#ip address 10.0.0.1 255.255.255.0
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

! ── Primary WAN — ISP-A ──────────────────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#description Primary-WAN-ISP-A
NetsTuts_R1(config-if)#ip address 203.0.113.1 255.255.255.252
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

! ── Backup WAN — ISP-B ───────────────────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/2
NetsTuts_R1(config-if)#description Backup-WAN-ISP-B
NetsTuts_R1(config-if)#ip address 198.51.100.1 255.255.255.252
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

Verify Connectivity to Both ISP Gateways

NetsTuts_R1#ping 203.0.113.2
!!!!!
Success rate is 100 percent (5/5)

NetsTuts_R1#ping 198.51.100.2
!!!!!
Success rate is 100 percent (5/5)

Both ISP gateways must be directly reachable before configuring IP SLA. The ICMP echo probes in this lab target 8.8.8.8 and 8.8.4.4 — addresses beyond the ISP gateways — so the gateways themselves must forward the probe packets. If either gateway ping fails, resolve the physical or addressing issue before proceeding. Verify interface states with show ip interface brief.

4. Step 2 — Configure IP SLA Operations

Each IP SLA operation is a numbered instance — the number is local to the router and used to reference the operation in tracking and scheduling commands. Configuration is in two parts: define the probe parameters, then schedule it to start:

SLA 1 — Monitor ISP-A Reachability

! ── IP SLA operation 1 — probe through ISP-A ─────────────
NetsTuts_R1(config)#ip sla 1
NetsTuts_R1(config-ip-sla)#icmp-echo 8.8.8.8 source-interface GigabitEthernet0/1
NetsTuts_R1(config-ip-sla-echo)#frequency 10
NetsTuts_R1(config-ip-sla-echo)#timeout 3000
NetsTuts_R1(config-ip-sla-echo)#threshold 2000
NetsTuts_R1(config-ip-sla-echo)#exit
NetsTuts_R1(config)#exit

! ── Schedule SLA 1 — start immediately, run forever ──────
NetsTuts_R1(config)#ip sla schedule 1 life forever start-time now

Breaking down the configuration: icmp-echo 8.8.8.8 source-interface GigabitEthernet0/1 — sends ICMP echo probes to 8.8.8.8, always sourced from Gi0/1 (the ISP-A interface). The source-interface is critical — without it, the probe sources from the best-path outgoing interface, which defeats the purpose when testing a specific WAN link. frequency 10 — probe every 10 seconds (default is 60). Faster probing means faster failure detection at the cost of slightly more traffic. timeout 3000 — wait 3 seconds for a response before counting the probe as failed. threshold 2000 — RTTs above 2000ms are counted as threshold violations even if the probe technically succeeds. ip sla schedule 1 life forever start-time now — starts the operation immediately and keeps it running indefinitely. Without the schedule command, the SLA operation is defined but never runs.

SLA 2 — Monitor ISP-B Reachability

! ── IP SLA operation 2 — probe through ISP-B ─────────────
NetsTuts_R1(config)#ip sla 2
NetsTuts_R1(config-ip-sla)#icmp-echo 8.8.4.4 source-interface GigabitEthernet0/2
NetsTuts_R1(config-ip-sla-echo)#frequency 10
NetsTuts_R1(config-ip-sla-echo)#timeout 3000
NetsTuts_R1(config-ip-sla-echo)#threshold 2000
NetsTuts_R1(config-ip-sla-echo)#exit

NetsTuts_R1(config)#ip sla schedule 2 life forever start-time now

SLA 2 mirrors SLA 1 but uses Gi0/2 as the source interface, targeting a different probe destination (8.8.4.4 — Google's secondary DNS, also reachable via most ISPs). Using a different target IP per ISP means a response to SLA 2 cannot be misattributed to ISP-A, and the two probes are completely independent.

Optional: TCP Connect Probe (Application-Layer Testing)

! ── SLA 10 — verify a web server is accepting HTTP ───────
NetsTuts_R1(config)#ip sla 10
NetsTuts_R1(config-ip-sla)#tcp-connect 203.0.113.10 80 source-interface GigabitEthernet0/1
NetsTuts_R1(config-ip-sla-tcp)#frequency 30
NetsTuts_R1(config-ip-sla-tcp)#timeout 5000
NetsTuts_R1(config-ip-sla-tcp)#exit

NetsTuts_R1(config)#ip sla schedule 10 life forever start-time now

TCP connect probes perform a full TCP three-way handshake to the target port. This tests Layer 4 availability — a server could respond to ICMP pings but have its web service down. TCP connect catches this where ICMP echo cannot. The probe opens a TCP connection, verifies the SYN-ACK, sends a RST to cleanly close, and records the result. No SLA Responder is needed on the target for TCP connect probes.

5. Step 3 — Configure Object Tracking

Object tracking converts the numeric IP SLA result into a named Up/Down state that IOS features can react to. The delay parameters prevent route or HSRP flapping during brief probe failures — a single missed probe does not immediately trigger a route change:

! ── Track 1 — watches SLA 1 (ISP-A) reachability ─────────
NetsTuts_R1(config)#track 1 ip sla 1 reachability
NetsTuts_R1(config-track)#delay down 15 up 10
NetsTuts_R1(config-track)#exit

! ── Track 2 — watches SLA 2 (ISP-B) reachability ─────────
NetsTuts_R1(config)#track 2 ip sla 2 reachability
NetsTuts_R1(config-track)#delay down 15 up 10
NetsTuts_R1(config-track)#exit

track 1 ip sla 1 reachability creates tracked object 1 that mirrors the reachability state of SLA operation 1. When SLA 1 receives responses, Track 1 is Up. When SLA 1 stops receiving responses, Track 1 transitions to Down. delay down 15 up 10 introduces damping: the SLA must fail continuously for 15 seconds before Track 1 goes Down (preventing a single dropped probe from triggering failover), and must succeed for 10 seconds before Track 1 returns to Up (preventing premature recovery on a flapping link). Choosing appropriate delay values depends on the SLA frequency — with a 10-second frequency, a 15-second down delay means approximately 1–2 missed probes before failover triggers.

Track Interface Line-Protocol (Alternative Tracking)

! ── Track 10: watches the physical state of Gi0/1 ────────
! ── Simpler than IP SLA but only detects local interface
! ── failure — cannot detect upstream ISP circuit failure
NetsTuts_R1(config)#track 10 interface GigabitEthernet0/1 line-protocol
NetsTuts_R1(config-track)#delay down 5 up 5
NetsTuts_R1(config-track)#exit

Interface line-protocol tracking is simpler to configure but has a critical limitation: it only detects local interface failures (cable unplugged, CPE device down). It cannot detect upstream ISP failures where the local interface stays up but the ISP's circuit is dead. Check show interfaces to see current interface states. IP SLA probing to a far-end target is the only way to detect end-to-end path failures — which is why it is the preferred method for WAN failover.

6. Step 4 — Tracked Floating Static Routes

A floating static route is a static route with a higher administrative distance than the primary route, so it remains hidden in the routing table until the primary route is removed. Combining floating static routes with object tracking creates fully automatic WAN failover: the primary route is only installed when Track 1 is Up, and the backup route activates when the primary is removed. See Static Route Configuration for static routing fundamentals:

! ── PRIMARY default route — ISP-A ────────────────────────
! ── AD 1 (default for static) — installed when Track 1 is Up
! ── Removed from routing table when Track 1 goes Down ────
NetsTuts_R1(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.2 track 1

! ── BACKUP default route — ISP-B ─────────────────────────
! ── AD 5 — only visible when primary route is gone ───────
! ── Installed when Track 2 is Up and primary is Down ─────
NetsTuts_R1(config)#ip route 0.0.0.0 0.0.0.0 198.51.100.2 5 track 2

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]

The track 1 keyword at the end of the primary static route tells IOS: "only install this route in the routing table while Track 1 is Up. Remove it when Track 1 goes Down." The backup route uses administrative distance 5 (higher than the primary's default of 1) so it is never preferred while the primary exists, but becomes the active default route the moment the primary is removed. The track 2 on the backup adds an additional condition — the backup route is only installed if ISP-B itself is reachable. This prevents the backup from activating if ISP-B is also down.

Verify Routing Table — Normal Operation (Both ISPs Up)

NetsTuts_R1#show ip route
Codes: C - connected, S - static ...

Gateway of last resort is 203.0.113.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 203.0.113.2
      10.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        10.0.0.0/24 is directly connected, GigabitEthernet0/0
C        203.0.113.0/30 is directly connected, GigabitEthernet0/1
C        198.51.100.0/30 is directly connected, GigabitEthernet0/2

Only the primary default route (AD 1 via 203.0.113.2) appears in the routing table. The backup route (AD 5 via 198.51.100.2) is hidden — it exists in the configuration but is suppressed because a lower-AD route to the same destination already exists. This is normal and correct operation. See show ip route for route table interpretation.

Verify Routing Table — ISP-A Failure (Primary Route Removed)

! ── Simulate ISP-A failure — Track 1 transitions to Down ─
! ── (In production this happens automatically via SLA probes)
! ── After ~15 seconds (delay down timer), routing changes:

NetsTuts_R1#show ip route
Codes: C - connected, S - static ...

Gateway of last resort is 198.51.100.2 to network 0.0.0.0

S*    0.0.0.0/0 [5/0] via 198.51.100.2
      10.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        10.0.0.0/24 is directly connected, GigabitEthernet0/0
C        203.0.113.0/30 is directly connected, GigabitEthernet0/1
C        198.51.100.0/30 is directly connected, GigabitEthernet0/2

The routing table now shows the backup route (AD 5 via 198.51.100.2) as the gateway of last resort. The primary route has been automatically removed because Track 1 went Down. Traffic from the LAN now exits through ISP-B without any manual intervention. When ISP-A recovers, SLA probes resume receiving responses, Track 1 returns to Up after the 10-second up delay, and the primary route is re-installed — preempting the backup route automatically.

7. Step 5 — HSRP Priority Tracking

HSRP tracking links gateway redundancy to WAN health. Without it, R1 could remain the HSRP active gateway even after its ISP-A link fails — LAN hosts keep sending traffic to R1, which then blackholes it because the primary WAN is down. With HSRP tracking, R1 reduces its priority when ISP-A fails, causing R2 (which may have a working WAN connection) to take over as the active gateway. See FHRP — HSRP, VRRP & GLBP Lab for the complete HSRP setup:

! ── Configure HSRP on R1's LAN interface ─────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#standby version 2
NetsTuts_R1(config-if)#standby 1 ip 10.0.0.254
NetsTuts_R1(config-if)#standby 1 priority 110
NetsTuts_R1(config-if)#standby 1 preempt

! ── Link Track 1 to HSRP — decrement priority on failure ─
NetsTuts_R1(config-if)#standby 1 track 1 decrement 20
NetsTuts_R1(config-if)#exit

! ── R2 HSRP config (default priority 100) ─────────────────
! ── Configured on NetsTuts_R2 ────────────────────────────
! NetsTuts_R2(config)#interface GigabitEthernet0/0
! NetsTuts_R2(config-if)#standby version 2
! NetsTuts_R2(config-if)#standby 1 ip 10.0.0.254
! NetsTuts_R2(config-if)#standby 1 priority 100
! NetsTuts_R2(config-if)#standby 1 preempt

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]

The HSRP tracking logic works as follows: Normal operation: R1 priority = 110, R2 priority = 100. R1 is the HSRP Active gateway (higher priority wins). LAN hosts use 10.0.0.254 as their default gateway, traffic flows through R1 to ISP-A. ISP-A failure: Track 1 goes Down. R1's HSRP priority drops by 20 to 90. R2 still has priority 100. R2 is now higher — with preempt enabled on R2, R2 takes over as Active. LAN hosts' traffic now flows through R2. ISP-A recovery: Track 1 returns to Up. R1's priority returns to 110. With preempt on R1, R1 reclaims Active. The decrement value (20) must be large enough to push R1 below R2's priority — always verify: R1_priority - decrement < R2_priority.

Verify HSRP Tracking — Normal State

NetsTuts_R1#show standby GigabitEthernet0/0
GigabitEthernet0/0 - Group 1 (version 2)
  State is Active
    3 state changes, last state change 00:08:14
  Virtual IP address is 10.0.0.254
  Active virtual MAC address is 0000.0c9f.f001
    Local virtual MAC address is 0000.0c9f.f001 (v2 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.984 secs
  Preemption enabled
  Active router is local
  Standby router is 10.0.0.2
  Priority 110 (configured 110)
  Track object 1 state Up decrement 20
  IP redundancy name is "hsrp-Gi0/0-1" (default)

Priority 110 (configured 110) — current and configured priorities are the same, confirming Track 1 is Up and no decrement is active. Track object 1 state Up decrement 20 — the track object is Up and the decrement value is 20. When Track 1 goes Down, this line will show "state Down" and the active priority will drop to 90.

Verify HSRP During ISP-A Failure

! ── After Track 1 goes Down (ISP-A failure simulated) ────
NetsTuts_R1#show standby GigabitEthernet0/0
GigabitEthernet0/0 - Group 1 (version 2)
  State is Standby
    4 state changes, last state change 00:00:18
  Virtual IP address is 10.0.0.254
  Active virtual MAC address is 0000.0c9f.f001
    Local virtual MAC address is 0000.0c9f.f001 (v2 default)
  Preemption enabled
  Active router is 10.0.0.2, priority 100 (expires in 8.192 sec)
  Standby router is local
  Priority 90 (configured 110, track 1 decrement 20)
  Track object 1 state Down decrement 20

State is Standby — R1 has yielded the Active role to R2. Priority 90 (configured 110, track 1 decrement 20) — IOS explicitly shows the configured value, the decrement, and the resulting effective priority. Track object 1 state Down — confirms the failover was triggered by IP SLA detecting ISP-A failure. LAN traffic is now flowing through R2.

8. Step 6 — Verifying IP SLA Statistics

show ip sla statistics — Current Results

NetsTuts_R1#show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: 14 milliseconds
Latest operation start time: 08:42:30 UTC Sun Mar 08 2026
Latest operation return code: OK
Number of successes: 87
Number of failures: 0
Operation time to live: Forever

IPSLA operation id: 2
        Latest RTT: 18 milliseconds
Latest operation start time: 08:42:33 UTC Sun Mar 08 2026
Latest operation return code: OK
Number of successes: 85
Number of failures: 0
Operation time to live: Forever

Both SLA operations are running successfully. Latest RTT = round-trip time of the most recent probe in milliseconds — 14ms for ISP-A, 18ms for ISP-B. Low and consistent RTT values indicate healthy WAN paths. Latest operation return code: OK = the most recent probe succeeded and RTT was below the threshold. Number of successes / failures = cumulative probe results since the operation started. Zero failures confirms stable connectivity on both links. Operation time to live: Forever = the schedule uses life forever — the operation runs indefinitely and does not expire.

show ip sla statistics — After ISP-A Failure

NetsTuts_R1#show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 08:55:20 UTC Sun Mar 08 2026
Latest operation return code: Timeout
Number of successes: 87
Number of failures: 9
Operation time to live: Forever

IPSLA operation id: 2
        Latest RTT: 18 milliseconds
Latest operation start time: 08:55:23 UTC Sun Mar 08 2026
Latest operation return code: OK
Number of successes: 97
Number of failures: 0
Operation time to live: Forever

SLA 1 is now failing — Latest RTT: NoConnection/Busy/Timeout and return code: Timeout confirm no response was received within the 3000ms timeout window. Number of failures: 9 — nine consecutive probe failures have occurred. With the 10-second frequency and 15-second delay-down timer, the Track 1 object transitioned to Down after approximately 15 seconds of continuous failure (~2 probe failures). SLA 2 (ISP-B) continues to succeed normally — confirming the backup path is healthy.

show ip sla statistics detail

NetsTuts_R1#show ip sla statistics 1 detail
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
Type of operation: icmp-echo
        Latest RTT: 14 milliseconds
Source Address: GigabitEthernet0/1 (203.0.113.1)
Destination Address: 8.8.8.8
Latest operation start time: 08:42:30 UTC Sun Mar 08 2026
Latest operation return code: OK
Threshold: 2000 ms
Threshold count: 0
Number of successes: 87
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never

The detailed view confirms the probe configuration: source address (203.0.113.1 on Gi0/1), destination (8.8.8.8), threshold (2000ms), and threshold violation count. The Operational state: Active confirms the schedule is running. Last time this entry was reset: Never — the counters have not been cleared since the operation started.

show track — Object Tracking State

NetsTuts_R1#show track
Track 1
  IP SLA 1 Reachability
  Reachability is Up
    1 change, last change 00:14:22
  Delay up 10 secs, down 15 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 14
  Tracked by:
    Static IP Routing 0
    HSRP GigabitEthernet0/0 1

Track 2
  IP SLA 2 Reachability
  Reachability is Up
    0 changes, last change never
  Delay up 10 secs, down 15 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 18
  Tracked by:
    Static IP Routing 0

show track is the central status dashboard for all tracked objects. Reachability is Up — both ISP paths are healthy. 1 change, last change 00:14:22 on Track 1 — confirms there was a previous failover and recovery event 14 minutes ago, providing an audit trail. Tracked by: — shows exactly which features are listening to this track object: Track 1 is used by both a static route (Static IP Routing 0) and HSRP Group 1 on Gi0/0. This cross-reference is invaluable for impact analysis — before removing a track object, confirm everything that depends on it.

show ip sla configuration — Verify SLA Definition

NetsTuts_R1#show ip sla configuration 1
IP SLAs Infrastructure Engine-II
Entry number: 1
Owner:
Tag:
Type of operation to perform: icmp-echo
Target address/Source address: 8.8.8.8/203.0.113.1
Source Interface: GigabitEthernet0/1
Type Of Service parameters: 0x0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 3000
Frequency (seconds): 10
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 2000
Distribution Statistics:
  Number of statistic hours kept: 2
  Number of statistic distribution buckets kept: 1
  Statistic distribution interval (milliseconds): 20
Enhanced History:

Verification Command Summary

Command	What It Shows	Primary Use
`show ip sla statistics`	All SLA operations — latest RTT, return code, success/failure counts, time to live	Primary health check — instantly see if any probe is failing and how many times
`show ip sla statistics [id] detail`	Full detail for one SLA — source/destination, threshold, state, reset history	Deep-dive a specific probe — confirm source interface, timeout, threshold violations
`show ip sla configuration [id]`	Complete configuration of one SLA — all parameters as configured	Verify SLA is defined correctly before troubleshooting statistics
`show ip sla summary`	Brief one-line-per-operation summary — state, RTT, return code	Quick overview when many SLA operations are configured
`show track`	All track objects — state (Up/Down), change count, last change time, what is using each track	Central tracking dashboard — see current state and what features depend on each track object
`show track [id]`	Detail for one tracked object — SLA association, delays, tracked-by list	Confirm a specific track is tied to the right SLA and feature
`show track brief`	Concise one-line per tracked object — ID, type, state, change count	Quick state check across all track objects simultaneously
`show ip route`	Routing table — confirms tracked static routes are installed or removed	Verify failover worked — primary route should be absent when Track is Down
`show standby [int]`	HSRP group detail — state, priority (actual vs configured), track state	Confirm HSRP tracking is active and priority decrement is or is not applied
`show ip route [prefix]`	Detail on a specific route — AD, metric, age, next-hop	Confirm the correct default route is installed during normal and failover states

9. Troubleshooting IP SLA & Tracking Issues

Problem	Symptom	Cause	Fix
SLA always shows Timeout / failures	`show ip sla statistics` shows return code Timeout and rising failure count from the moment it starts	Most common causes: (1) no route to the probe target — the SLA operation cannot reach 8.8.8.8 because no default or specific route exists yet, (2) wrong source-interface — probes are sourced from an interface that cannot reach the target, (3) an ACL blocking ICMP on the path	Manually ping the target from the correct source: `ping 8.8.8.8 source GigabitEthernet0/1`. If this fails, fix the routing issue first. If ping works but SLA still fails, check ACLs on the path. Verify source-interface in `show ip sla configuration [id]`
SLA probe never starts	`show ip sla statistics` shows the entry but Latest RTT shows "—" and success count is 0	The `ip sla schedule` command was not entered, or was entered with a future start time that has not arrived yet	Check with `show ip sla configuration [id]` — look at "Next Scheduled Start Time". If missing schedule, add `ip sla schedule [id] life forever start-time now`. The schedule command is separate from the SLA definition and is mandatory for probes to run
Tracked route not removed on failure	SLA shows failures and Track shows Down, but `show ip route` still shows the primary static route	The `track` keyword is missing from the static route command — the route was configured without tracking and is a plain static route unaffected by the track state	Check with `show run \| include ip route`. If the route lacks the `track [id]` keyword, remove it and re-add with tracking: `no ip route 0.0.0.0 0.0.0.0 203.0.113.2` then `ip route 0.0.0.0 0.0.0.0 203.0.113.2 track 1`
Route flapping during intermittent ISP issues	The routing table alternates rapidly between primary and backup routes every few minutes — logs show constant track state changes	The delay timers on the track object are too short (or zero) — a single probe failure immediately triggers a Down transition, and a single success triggers Up again	Increase the delay timers: `track [id]` → `delay down 30 up 20`. Also consider increasing the SLA frequency (less frequent probing = slower reaction to transient failures). The down delay should be at least 2–3× the SLA frequency to absorb intermittent failures
HSRP not failing over despite Track going Down	`show track` confirms Track 1 is Down but R1 remains HSRP Active and R2 does not take over	Either (1) the `standby 1 track 1 decrement 20` command is missing on R1, or (2) the decrement is too small — R1's priority after decrement is still higher than R2's priority, or (3) R2 does not have `standby 1 preempt` configured	Verify the decrement math: R1 configured priority (110) minus decrement (20) = 90, which must be LESS than R2's priority (100). Confirm R2 has `preempt`. Check R1 with `show standby` to see both the configured and effective priority. Add the track command if missing. See FHRP Lab for HSRP troubleshooting.
Both routes disappear when primary ISP fails	Track 1 goes Down, primary route removed — but backup route also does not appear in routing table	Track 2 (ISP-B) is also Down — the backup route has `track 2` applied and ISP-B is also unreachable, or the backup route was configured without the correct AD value and was never a floating backup	Check `show ip sla statistics 2` and `show track 2`. If ISP-B probe is also failing, the backup WAN has an issue. If ISP-B is fine, check the track 2 configuration. Also verify the backup route has a higher AD than the primary: `show run \| include ip route 0.0.0.0`

Key Points & Exam Tips

IP SLA sends continuous active probes — ICMP echo, TCP connect, UDP jitter, HTTP, DNS — to measure reachability and performance. Unlike interface tracking, IP SLA can detect remote path failures even when the local interface stays up, making it essential for WAN failover.
IP SLA configuration requires two separate commands: (1) define the operation with ip sla [id] and its parameters, and (2) schedule it with ip sla schedule [id] life forever start-time now. Without the schedule command, the probe is defined but never runs — the most common IP SLA configuration mistake.
source-interface in the SLA probe is critical for WAN path testing. Without it, the probe uses the best-path outgoing interface — which may not be the WAN link you intend to test. Always specify the source interface when monitoring a specific WAN path.
Object tracking bridges IP SLA measurements to IOS actions. track [id] ip sla [sla-id] reachability exposes the SLA state as a simple Up/Down that static routes, HSRP, and EEM can react to. Use delay down [s] up [s] on the track object to prevent flapping — a minimum of 2–3× the SLA frequency is recommended.
A tracked static route uses the track [id] keyword at the end of the ip route command. The route is installed when the track is Up and automatically removed when the track goes Down. The backup floating route (higher AD) then becomes active. See Administrative Distance.
For HSRP tracking, the decrement value must push the tracked router's effective priority below the standby router's priority. Formula: active_priority - decrement < standby_priority. Also ensure the standby router has preempt configured or it will not take over even when it becomes highest priority. See FHRP Lab.
show ip sla statistics is the primary verification command. A return code of OK means the probe succeeded. Timeout means no response was received within the timeout window. Rising failure count with no successes indicates a persistent path failure.
show track shows the current Up/Down state of every track object, the number of state changes, when the last change occurred, and critically — which features (static routes, HSRP) are currently listening to each track. This cross-reference is essential for impact analysis before making changes.
Interface line-protocol tracking (track [id] interface [int] line-protocol) only detects local interface failure — it cannot detect upstream ISP failures. IP SLA probing to a remote target is the only method that provides true end-to-end path verification. Verify interface states with show interfaces.
On the CCNA exam: know the two-step IP SLA configuration (define + schedule), the purpose of the track keyword on a static route (route removed when track is Down), the HSRP tracking decrement arithmetic, and how to read show ip sla statistics output (return code OK vs Timeout, success/failure counts).

Next Steps: IP SLA integrates naturally with several other technologies covered in this lab library. For the HSRP configuration that this lab extends with tracking, see HSRP (First Hop Redundancy), FHRP — HSRP, VRRP & GLBP Lab, and VRRP & GLBP. For floating static route fundamentals without tracking, revisit Static Route Configuration. To extend IP SLA into automated alerting — sending SNMP traps or syslog messages when an SLA probe fails — see IP SLA Syslog Alerting, Syslog Configuration, and the EEM (Embedded Event Manager) lab. For a complete picture of how the routing table processes multiple routes and AD values, review Administrative Distance, Route Sources, and show ip route.

TEST WHAT YOU LEARNED

1. An IP SLA ICMP echo operation is fully configured with all parameters, but `show ip sla statistics` shows zero successes and zero failures with no RTT value. What is missing?

A. The source-interface command was not specified inside the SLA operation B. The probe target (e.g., 8.8.8.8) is unreachable — probes are being sent but timing out immediately C. The ip sla schedule [id] life forever start-time now command was never entered. Defining an IP SLA operation only creates the probe template — a separate schedule command is required to actually start sending probes. Without it, the operation is defined but completely dormant D. The track object must be configured before the IP SLA operation will start sending probes

Correct answer is C. IP SLA requires two completely separate commands to function: the operation definition (ip sla [id] with its probe type and parameters) and the schedule (ip sla schedule [id] life forever start-time now). The operation definition alone creates a dormant template — no probes are sent, no statistics accumulate, and the RTT field shows no value. This is the single most common IP SLA configuration error. If the probe were configured but timing out, you would see rising failure counts and a return code of Timeout. Zero successes AND zero failures with no RTT means the probe has never run at all — the schedule is the missing piece. Option D is incorrect — object tracking is configured after IP SLA and depends on it, not the other way around.

2. Why is the `source-interface` parameter critical when using IP SLA to monitor a specific WAN link?

A. Without source-interface, the router sources probes from its best-path outgoing interface based on the routing table. If a default route already exists via ISP-A, probes intended to test ISP-B would also exit via ISP-A — both SLA operations would pass or fail together and the backup path test would be meaningless. Specifying source-interface GigabitEthernet0/2 forces probes to exit only through ISP-B regardless of the routing table B. source-interface is only required for UDP jitter probes — ICMP echo probes do not need it C. source-interface sets the DSCP marking on probe packets so they are prioritised by QoS policies on the WAN link D. source-interface is required only when the probe destination is a private IP address — public IP probes always use the correct interface automatically

Correct answer is A. The routing table governs how packets are forwarded — including IP SLA probe packets. In a dual-WAN scenario with a default route via ISP-A, all traffic (including SLA probes) goes through ISP-A unless told otherwise. If SLA 2 is supposed to test ISP-B but lacks a source-interface, it routes through ISP-A and successfully probes 8.8.4.4 via ISP-A. When ISP-B fails, SLA 2 still succeeds (because it is using ISP-A), Track 2 stays Up, and the backup route never activates — completely defeating the purpose of the dual-path monitoring. The source-interface forces the probe to use a specific outgoing interface, ensuring SLA 2 tests only ISP-B's path regardless of the routing table state.

3. What is the purpose of the `delay down 15 up 10` command on a track object?

A. It sets the IP SLA probe frequency to 15 seconds for failures and 10 seconds for successes B. It delays the IP SLA schedule — probes start 15 seconds after configuration and stop 10 seconds after a failure C. It sets the HSRP hello timer to 15 seconds and the hold timer to 10 seconds D. It introduces damping to prevent flapping — the SLA must report failure for 15 continuous seconds before the track object transitions to Down (preventing a single dropped probe from triggering failover), and must report success for 10 continuous seconds before the track returns to Up (preventing premature recovery on a briefly flapping link)

Correct answer is D. The delay timers are a critical stability mechanism. Without delay timers (default is 0 seconds for both), a single probe failure immediately transitions the track to Down and removes the static route, then a single probe success immediately restores it. On an intermittent WAN link, this causes the routing table to flip every few seconds — a condition called route flapping that creates instability for all active connections. The delay timers absorb transient failures: delay down 15 means 15 seconds of continuous failure before the track goes Down, and delay up 10 means 10 seconds of continuous success before the track returns Up. With a 10-second probe frequency, a 15-second down delay requires 1–2 consecutive probe failures to trigger — distinguishing a real outage from a single dropped packet.

4. R1 has HSRP configured with priority 110, Track 1 with decrement 20, and R2 has HSRP priority 100. Track 1 goes Down. Will R2 become the HSRP Active router?

A. Yes — whenever Track 1 goes Down on R1, R2 always becomes Active regardless of priority values B. Yes, but only if R2 has standby 1 preempt configured. R1's effective priority drops to 90 (110-20=90), which is below R2's 100. R2 is now higher priority and will preempt to become Active — but only if preempt is enabled on R2. Without preempt, R2 stays Standby even though it has higher priority C. No — priority only changes when the interface physically goes down, not when a track object changes state D. No — R1 remains Active because it was already the Active router before Track 1 went Down

Correct answer is B. Two conditions must both be true for the failover to work: (1) R1's effective priority must drop below R2's priority — in this case 110-20=90 which IS below R2's 100, so the math works. (2) R2 must have preempt configured. In HSRP, a router with higher priority does not automatically take over from a lower-priority Active router — preemption must be explicitly enabled. Without standby 1 preempt on R2, R2 stays in Standby even after R1's priority drops below 100. This is a very common HSRP tracking misconfiguration — the decrement is correct but the failover never happens because preempt was forgotten on the standby router. Always verify both the decrement math AND the preempt configuration. See FHRP Lab for more.

5. What is the key difference between tracking `ip sla [id] reachability` versus tracking an `interface [int] line-protocol` for WAN failover?

A. Interface tracking works for both Layer 2 and Layer 3 failures; IP SLA only detects Layer 3 failures B. IP SLA tracking requires an SLA Responder on the remote end; interface tracking works without any remote configuration C. Interface line-protocol tracking only detects local interface failures (the cable or CPE going down — confirm with show interfaces) — it cannot detect upstream ISP circuit failures where the local port stays up but the ISP's backbone is down. IP SLA probing to a remote target beyond the ISP detects end-to-end path failures including upstream issues invisible to the local interface state D. They are functionally identical — interface tracking and IP SLA tracking both probe the same path and produce the same result

Correct answer is C. This is the fundamental limitation of interface-based tracking. When an ISP's upstream circuit fails, the physical connection between the router and the ISP's CPE (modem/router) usually remains up — the local Gi0/1 interface stays in up/up state. Interface line-protocol tracking sees "interface up" and reports Track Up, so the static route remains in the routing table and traffic continues to blackhole into the dead ISP circuit. IP SLA probing to 8.8.8.8 (beyond the ISP) would detect this failure because probe packets traverse the ISP's circuit and receive no response. This is why IP SLA with a far-end probe target is the correct solution for WAN failover — it tests the entire path, not just the last-mile connection. Option B is incorrect — ICMP echo IP SLA does not require a Responder on the remote end; only UDP jitter probes require a Responder.

6. In `show ip sla statistics`, SLA 1 shows "Latest operation return code: Timeout" and "Number of failures: 4". What does this indicate, and what should the engineer check next?

A. The last four probes to the target received no response within the timeout window — the path to the probe target is likely down. The engineer should manually ping the target from the same source interface to confirm: ping 8.8.8.8 source GigabitEthernet0/1. Also check show track 1 to see if the track has transitioned to Down and triggered a routing change B. The SLA probe is functioning correctly — Timeout is the expected return code when the probe completes faster than the timeout threshold C. The SLA operation needs to be rescheduled — 4 failures means it has exceeded its retry limit and stopped running D. The probe target (8.8.8.8) has responded but with RTT above the configured threshold — this is normal during network congestion

Correct answer is A. A return code of "Timeout" means the probe sent an ICMP echo and received no response within the configured timeout period (3000ms in this lab). Combined with 4 consecutive failures, this strongly indicates the path to 8.8.8.8 via Gi0/1 is not working. The correct diagnostic sequence is: (1) verify the path manually with a source-pinged ping to the same target, (2) check the track state to see if failover has triggered, and (3) check the routing table to confirm the backup route is active. Option D describes an "Over Threshold" return code — that would mean a response was received but RTT exceeded the threshold. "Timeout" specifically means no response at all, not a slow response. IP SLA operations do not stop after failures — they continue probing indefinitely per the schedule (life forever), so the operation is still running despite the failures.

7. Which command shows which features (static routes, HSRP groups) are currently relying on a specific track object?

A. show ip sla statistics — lists all consumers of each SLA operation B. show ip route track — shows all routes using tracked objects C. show ip sla configuration — lists the features associated with each SLA D. show track [id] — the "Tracked by:" section at the bottom of the output lists every feature currently monitoring that track object, including static routes (Static IP Routing) and HSRP groups (HSRP GigabitEthernet0/0 1). This is essential before removing a track object to understand the blast radius

Correct answer is D. The show track [id] command output includes a "Tracked by:" section that cross-references every IOS feature currently consuming that track object's Up/Down state. For example: "Tracked by: Static IP Routing 0, HSRP GigabitEthernet0/0 1" means both a static route and HSRP Group 1 on Gi0/0 depend on this track. This is critical operational knowledge — before modifying or removing a track object, you must know what will be affected. If you remove Track 1 without knowing that HSRP depends on it, you may inadvertently break gateway redundancy. The show track (without an ID) shows all track objects with their "Tracked by" lists simultaneously, providing a complete dependency map in one command.

8. A primary static default route has `track 1` applied. Track 1 goes Down. Moments later, `show ip route` shows no default route at all — not even the backup. What is the most likely explanation?

A. The backup static route was not saved with write memory and was lost on a reload B. The backup static route also has a track applied (track 2) and Track 2 is also Down — the backup route's condition is not met. Both ISP paths are failing simultaneously, causing both tracked routes to be removed from the routing table C. The backup route has the same AD as the primary route — they are competing and both are removed D. The ip sla schedule for SLA 2 expired and stopped monitoring ISP-B

Correct answer is B. In this lab, the backup route is configured as ip route 0.0.0.0 0.0.0.0 198.51.100.2 5 track 2 — it has its own track condition. If ISP-B is also experiencing problems, Track 2 goes Down and the backup route is also removed. The result is a routing table with no default route — a complete internet outage. This scenario highlights an important design consideration: always have an "escape hatch" — either a third static route without tracking (last-resort with very high AD like 254) or a local probe target (just the ISP gateway, not a far-end address) that would only fail on complete physical failure. The tracked backup route approach works well for dual-ISP failover, but the scenario of both paths failing simultaneously must be considered in the design.

9. What is an IP SLA TCP connect probe, and what does it detect that an ICMP echo probe cannot?

A. A TCP connect probe uses ICMP type 13 (timestamp) instead of type 8 (echo) — it measures NTP synchronisation rather than basic reachability B. A TCP connect probe requires a Cisco SLA Responder on the target — it cannot probe non-Cisco devices C. A TCP connect probe performs a full TCP three-way handshake to a specific port number on the target. It detects application-layer failures: a server may respond to ICMP ping (Layer 3 is working) but its web service on port 80 may be down. ICMP echo only confirms Layer 3 reachability; TCP connect confirms a specific service is actually accepting connections D. A TCP connect probe is identical to ICMP echo but uses TCP SYN packets instead of ICMP — the result and detection capability are the same

Correct answer is C. TCP connect probes test at Layer 4 (transport layer) rather than Layer 3. A server can be fully reachable via ping (ICMP echo succeeds) but have its application service completely unavailable — the TCP port is not listening, the application has crashed, or an ACL is blocking that specific port while allowing ICMP. An ICMP echo SLA would show the server as reachable (OK) in this scenario, while a TCP connect probe to port 80 would show a failure. TCP connect SLA is particularly valuable for monitoring critical services: web servers (80/443), mail relays (25), and DNS servers (53). Option B is incorrect — TCP connect probes do not require a Responder. Only UDP jitter probes (which need two-way timestamp exchange) require a Cisco SLA Responder on the target device.

10. An engineer wants to add an IP SLA probe but does not want to disrupt the existing tracked route during configuration. They plan to configure the SLA operation and schedule it, then create the track object, and finally add the `track` keyword to the existing static route. Is this approach correct?

A. No — the track object must always be created before the SLA operation or the binding will fail B. No — IOS requires the static route with the track keyword to be configured first, then the track object, then the SLA C. Yes, but only if the SLA schedule uses a delayed start time: start-time after 00:05:00 D. Yes — this is the correct and safe approach. Adding a track [id] keyword to an existing static route requires removing and re-adding the route, which causes a brief routing disruption. The existing route can be left in place as a plain static route while the SLA and track objects are built and verified. Once the SLA shows return code OK and the track shows Up, the static route can be replaced with the tracked version — minimising the window during which the route could be incorrectly removed

Correct answer is D. This is the correct operational approach for adding IP SLA tracking to a production network with minimal disruption. The order matters because adding the track keyword to a static route requires a no ip route followed by a new ip route ... track [id] — there is a brief moment where the static route is absent from the routing table. By building and verifying the SLA and track objects first (without touching the route), you ensure the track object is already Up before the route depends on it. If you added the route with tracking while the SLA was still warming up, the track might briefly show Down (SLA not yet receiving responses), removing the route prematurely. Building SLA → verify OK → build track → verify Up → update route is the safest sequence.

Back to Home