10.1 IP Service Level Agreements (IP SLA) Probes, Responder, and Route Tracking

IP Service Level Agreements (IP SLA) Probes, Responder, and Route Tracking

High-availability enterprise networks require continuous performance validation across campus cores, wide-area network (WAN) edges, and hybrid-cloud transit links. Passive network monitoring tools—such as Simple Network Management Protocol (SNMP) polling and Flexible NetFlow (FNF)—analyze production traffic as it traverses interfaces. However, passive monitoring cannot evaluate path health when circuits are idle, nor can it isolate unidirectional packet loss or verify application-layer service responsiveness before production users experience service degradation.

Cisco IP Service Level Agreements (IP SLA) resolves these limitations by executing active network monitoring. Embedded within Cisco IOS XE, IP SLA generates synthetic, deterministic traffic probes across the data plane to measure critical network performance metrics, including round-trip time (RTT), unidirectional latency, packet delay variation (jitter), packet loss, and server transaction completion times. Integrating IP SLA with Enhanced Object Tracking (EOT) enables infrastructure to dynamically alter forwarding paths, floating static routes, and First Hop Redundancy Protocol (FHRP) gateway priorities when path quality falls below defined thresholds.

---

IP SLA Operational Architecture and Probe Types

An IP SLA deployment consists of an IP SLA source router that originates synthetic test traffic and a target destination. Depending on the metric evaluated, the target destination may be an arbitrary IP endpoint (such as an external web server or default gateway) or a cooperating Cisco device running the IP SLA responder process.

+-----------------------+                         +-----------------------+
|    IP SLA SOURCE      |                         |   IP SLA RESPONDER    |
|   (Probing Router)    |                         |    (Target Router)    |
+-----------------------+                         +-----------------------+
           |                                                  |
           |--- 1. Control Msg (UDP 1967) Negotiate Port ---->|
           |<-- 2. Control Response (Port 5000 Allocated) ----|
           |                                                  |
           |--- 3. Probe Packet [T1 Timestamp] -------------->| [T2 Timestamp]
           |                                                  |   (Processing)
           |<-- 4. Probe Reply  [T4 Timestamp] ---------------| [T3 Timestamp]

1. ICMP Echo Probes

The icmp-echo operation transmits standard ICMP Echo Request packets toward a destination IP address and calculates the total round-trip time (RTT) upon receiving ICMP Echo Replies. ICMP echo operations require no specialized configuration on the target device, making them universally compatible with third-party routers, firewalls, and public Internet endpoints. However, ICMP echo probes cannot measure unidirectional delay or jitter, and network security appliances frequently deprioritize or rate-limit ICMP traffic, leading to false-positive latency alerts.

2. UDP Jitter Probes and the IP SLA Responder

Real-time voice and video collaboration streams demand strict bounds on latency and packet delay variation. The udp-jitter probe transmits a sequence of UDP datagrams containing internal timestamps at configured intervals (such as 10 packets sent 20 ms apart). To calculate accurate one-way latency, packet jitter, and directional packet loss, the target device must run the IP SLA responder.

The IP SLA responder eliminates target-device CPU scheduling delays from measurement metrics through a dedicated control protocol:

1. Control Transaction: The source router connects to the responder over UDP port 1967 (the IP SLA control port). The source requests that the responder open a dynamic UDP port (for example, UDP port 5000) for the test duration.
2. Probe Generation (T1): The source records timestamp T1 as the probe packet leaves its egress interface.
3. Target Ingress (T2): The responder receives the probe on the negotiated port and records timestamp T2.
4. Target Egress (T3): After internal processing, the responder records timestamp T3 immediately before transmitting the reply packet.
5. Source Ingress (T4): The source receives the reply and records timestamp T4.

Using these four timestamps, the source computes precise directional metrics independent of target operating system overhead:

• One-Way Forward Latency: T2 - T1
• One-Way Reverse Latency: T4 - T3
• Target Processing Time: T3 - T2
• True Network Round-Trip Time: (T4 - T1) - (T3 - T2)

If clocks are synchronized using NTP or PTP across both endpoints, unidirectional latency calculations achieve microsecond-level accuracy. Furthermore, by evaluating the inter-arrival gaps between consecutive packets, the probe calculates positive and negative jitter, out-of-order packet delivery, and Mean Opinion Score (MOS) voice quality ratings.

3. TCP Connect and HTTP Application Probes

• tcp-connect: Measures the time required to complete a full three-way TCP handshake (SYN, SYN-ACK, ACK) with a target server on a designated TCP port (such as port 80 for HTTP, 443 for HTTPS, or 25 for SMTP). This validates whether an application listening daemon is operational without transferring data.
• http: Evaluates upper-layer web application performance by executing an HTTP GET or HEAD request against a target Uniform Resource Identifier (URI). The probe measures DNS resolution latency, TCP connection time, HTTP request-to-response latency, and total page download time.

Comparison of IP SLA Probe Operations

---

Probe Scheduling and Operational Parameters

Configuring an IP SLA operation requires defining operational parameters within probe configuration mode, followed by committing the probe to the active execution scheduler:

• frequency <seconds>: Specifies how often the probe operation repeats (default is 60 seconds). For voice jitter testing, frequency is commonly set to 10–30 seconds.
• timeout <milliseconds>: Defines the duration the source waits for a reply before declaring the individual packet or transaction timed out (default is 5000 ms).
• threshold <milliseconds>: Sets the upper performance limit that triggers an internal threshold-crossing event without marking the probe completely unreachable. If RTT exceeds the threshold, the probe state transitions to OverThreshold.
• ip sla schedule: Activates the probe in the scheduler. Parameters include:
  • start-time now: Begins probe execution immediately.
  • start-time pending: Keeps the probe configured but dormant until triggered by an external process or management tool.
  • life forever: Keeps the probe running indefinitely until manually removed.
  • life <seconds>: Restricts probe lifespan to a fixed operating window.

---

Enhanced Object Tracking (EOT) Architecture

While IP SLA collects detailed performance statistics, routing engines cannot natively parse raw latency or jitter values directly from probe tables. Enhanced Object Tracking (EOT) provides the critical abstraction layer between IP SLA metrics and client processes such as static routes, Virtual Router Redundancy Protocol (VRRP), and Hot Standby Router Protocol (HSRP).

+-------------------------------------------------------------+
|                     IP SLA PROBE 10                         |
|         (Measures ICMP/UDP Latency and Packet Loss)         |
+-------------------------------------------------------------+
                               |
                               v
+-------------------------------------------------------------+
|                 ENHANCED OBJECT TRACKING (EOT)              |
|         track 1 ip sla 10 state / reachability              |
|         Damping Engine: delay down 10 up 5                  |
+-------------------------------------------------------------+
                               |
            +------------------+------------------+
            |                                     |
            v                                     v
+---------------------------+       +---------------------------+
|   ROUTING ENGINE (RIB)    |       |   FHRP GATEWAY (HSRP)     |
|   ip route 0.0.0.0 ...    |       |   standby 1 track 1       |
|   track 1                 |       |   decrement 20            |
+---------------------------+       +---------------------------+

Tracking State vs. Reachability

When linking a tracking object to an IP SLA operation, the engineer must choose between two distinct tracking modes:

1. track <id> ip sla <probe-id> reachability: Tracks whether the target is communicating. The track object reports UP as long as probe replies are received within the configured timeout window. If the target drops packets or becomes unreachable, the track transitions to DOWN. It ignores the threshold setting.
2. track <id> ip sla <probe-id> state: Tracks whether the target satisfies performance thresholds. If the probe receives replies within the timeout window, but the calculated RTT exceeds the configured threshold value, the IP SLA engine marks the return code as OverThreshold. Under state tracking, an OverThreshold condition causes the track object to transition to DOWN, allowing failover based on latency degradation even when the path remains nominally reachable.

Hysteresis and Damping Delays

Intermittent WAN circuits and micro-congested links can experience rapid flapping between acceptable and degraded states. If an EOT object reacts instantaneously to every failed probe, routing protocols flap routes repeatedly, consuming CPU cycles and dropping transit sessions. The delay down <seconds> up <seconds> command dampens track state transitions:

track 1 ip sla 10 state
 delay down 10 up 5

With this configuration, the track object remains UP until the probe reports a degraded state continuously for 10 seconds. Conversely, when the circuit recovers, the track object waits 5 consecutive seconds of verified healthy performance before restoring the primary path.

---

Automated Failover: Static Routing and FHRP Integration

1. Floating Static Route Failover

Enterprise branches often terminate a primary high-bandwidth circuit (such as a fiber Direct Internet Access circuit) alongside a secondary backup connection (such as cellular 5G or broadband). If the fiber provider experiences an upstream failure while the local physical interface remains up, standard static routes remain in the Routing Information Base (RIB), creating a black hole.

EOT resolves this by binding the primary static route to an IP SLA tracking object. A floating static route with a higher administrative distance serves as the backup:

! Primary default route bound to Track 1
ip route 0.0.0.0 0.0.0.0 192.0.2.1 track 1
!
! Backup floating static route through secondary provider (AD = 200)
ip route 0.0.0.0 0.0.0.0 198.51.100.1 200

If Track 1 transitions to DOWN, the primary route is immediately evicted from the RIB and Cisco Express Forwarding (CEF) table. The backup floating route with administrative distance 200 is dynamically installed without delay.

2. First Hop Redundancy Protocol (HSRP/VRRP) Priority Decrement

In dual-router campus aggregation designs, access switches send traffic to an active HSRP virtual IP hosted on Router 1. If Router 1 loses its upstream WAN transit link while its downstream LAN interface remains healthy, access clients continue sending traffic to Router 1, forcing traffic across an inter-switch transit link. Binding EOT to HSRP enables dynamic priority decrementing and preemption:

interface GigabitEthernet0/0/1
 description LAN Interface to Access Layer
 ip address 10.10.10.2 255.255.255.0
 standby 1 ip 10.10.10.1
 standby 1 priority 110
 standby 1 preempt
 standby 1 track 1 decrement 20

If upstream probe Track 1 fails, Router 1 decrements its HSRP priority from 110 to 90. Because Router 2 is configured with default priority 100 and preemption enabled (standby 1 preempt), Router 2 immediately assumes the active forwarding role, directing client traffic directly toward the surviving upstream path.

---

End-to-End CLI Configuration Walkthrough

The following configuration demonstrates a complete deployment: Router 1 runs a UDP jitter probe toward Router 2 (the IP SLA responder), monitors threshold criteria via EOT, and triggers static route failover.

Step 1: Configure the IP SLA Responder (Router 2)

Router2# configure terminal
Router2(config)# ip sla responder

Step 2: Configure the IP SLA Probe (Router 1)

Router1# configure terminal
Router1(config)# ip sla 10
Router1(config-ip-sla)# udp-jitter 192.168.12.2 5000
Router1(config-ip-sla-udp-jitter)# frequency 10
Router1(config-ip-sla-udp-jitter)# timeout 2000
Router1(config-ip-sla-udp-jitter)# threshold 50
Router1(config-ip-sla-udp-jitter)# exit
!
! Schedule probe to start immediately and run indefinitely
Router1(config)# ip sla schedule 10 life forever start-time now

Step 3: Configure Enhanced Object Tracking (Router 1)

Router1(config)# track 1 ip sla 10 state
Router1(config-track)# delay down 10 up 5
Router1(config-track)# exit

Step 4: Apply Tracking to Routing and Gateway Redundancy (Router 1)

! Tracked primary static default route
Router1(config)# ip route 0.0.0.0 0.0.0.0 192.168.12.2 track 1
!
! Floating backup default route via secondary link
Router1(config)# ip route 0.0.0.0 0.0.0.0 198.51.100.1 200

---

CLI Verification and Diagnostics

Verifying operational status requires examining probe statistics, tracking states, and the routing table.

1. show ip sla summary

Provides an immediate tabular view of all configured probes, their operation types, target destinations, and operational return codes:

Router1# show ip sla summary
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending

ID   Type        Destination       Stats  Return Code  Last Run
-----------------------------------------------------------------------
*10  udp-jitter  192.168.12.2:5000 OK     OK           4 seconds ago

If latency exceeds the configured threshold, the return code displays OverThreshold.

2. show ip sla statistics

Displays granular latency, jitter, packet loss, and timestamp data for active probes:

Router1# show ip sla statistics 10
Round Trip Time (RTT) for   Index 10
        Latest RTT: 12 ms
Latest operation start time: 14:10:02 UTC Wed Oct 7 2026
Latest operation return code: OK
Number of successes: 420
Number of failures: 0
Operation time to live: Forever
Latency one-way positive jitter: 2 ms
Latency one-way negative jitter: 1 ms
Packet Loss - Source to Destination: 0
Packet Loss - Destination to Source: 0

3. show track

Validates the operational state of the EOT abstraction layer, showing transition history and damping timers:

Router1# show track 1
Track 1
  IP SLA 10 state
  State is Up
    1 change, last change 00:32:15 ago
  Delay up 5 secs, down 10 secs
  Latest sub-index: OK
  Latest return code: OK
  Tracked by:
    Static code