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 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه