LogoفارسیFA

Hands-On Lab: Configuring IP SLA for Network Performance Monitoring

This hands-on lab configures an IP SLA operation to actively measure round-trip time and jitter to a remote destination, scheduling it to run continuously and reviewing the collected performance statistics.

IP SLA Performance MonitoringRound-Trip Time MeasurementJitter Operation

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure an IP SLA UDP jitter operation measuring performance to a remote destination, schedule it to run continuously, and review the collected round-trip time, jitter, and packet loss statistics it gathers over time.

Lab Purpose

IP SLA's reachability tracking was used earlier in this series purely as a binary up/down input for HSRP object tracking. IP SLA's broader purpose is active performance measurement — proactively generating synthetic traffic to continuously measure latency, jitter, and loss to a destination, providing objective data for capacity planning and SLA verification rather than only reachability status.

Lab Topology

R1 ---- WAN link ---- R2 (SLA responder)

R1: source of the SLA operation
R2: 172.20.50.2, target of measurement,
    configured to respond to SLA probes

Task 1: Configure R2 as an SLA Responder

Enable the IP SLA responder role on R2, required for accurate jitter measurement.

Task 2: Configure the Jitter Operation on R1

Configure an IP SLA UDP jitter operation on R1 targeting R2, specifying an appropriate source and destination port.

Task 3: Schedule the Operation to Run Continuously

Schedule the SLA operation to start immediately and run indefinitely.

Task 4: Allow the Operation to Collect Data

Let the operation run for several polling intervals to accumulate meaningful statistics.

Task 5: Review the Collected Performance Statistics

Examine the round-trip time, jitter, and packet loss data the operation has gathered.

Solution and Verification

R2(config)# ip sla responder

-- The responder timestamps probes as
-- precisely as possible on arrival and
-- departure, which is what enables accurate
-- one-way and jitter calculations rather
-- than just simple round-trip time

R1(config)# ip sla 10
R1(config-ip-sla)# udp-jitter 172.20.50.2 5000
R1(config-ip-sla-jitter)# frequency 30

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

-- Allowing several minutes to pass so
-- multiple 30-second polling cycles complete

R1# show ip sla statistics 10

Round Trip Time (RTT) for       Index 10
        Latest RTT: 24 ms
Latest operation start time: ...
Latest operation return code: OK
RTT Values:
        Number Of RTT: 10
        RTT Min/Avg/Max: 21/24/29 ms
Source to Destination Jitter Min/Avg/Max: 1/3/8 ms
Destination to Source Jitter Min/Avg/Max: 1/2/7 ms
Packet Loss Values:
        Loss Source to Destination: 0
        Loss Destination to Source: 0
Number of successes: 45
Number of failures: 0
-- Detailed, ongoing performance data --
-- far more than the simple up/down
-- reachability check used for HSRP tracking
-- in an earlier lab

Key Takeaway

The IP SLA responder role on R2 is what enables precise jitter and one-way delay measurement rather than only round-trip time — without a responder, R1 could still measure basic reachability and round-trip latency, but the granular jitter statistics this lab collected specifically depend on the responder's own timestamping of probe arrival and departure, making the responder configuration essential whenever detailed performance data (rather than simple reachability) is the actual goal.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue
Previous ArticleNext Article