- Cisco IOS IP SLAs Features Roadmap
- Cisco IOS IP SLAs Overview
- Configuring UDP Jitter Operations
- Configuring UDP Jitter Operations for VoIP
- Configuring a LSP Health Monitor with LSP Discovery
- Configuring IP SLAs for Metro-Ethernet
- Configuring UDP Echo Operations
- Configuring HTTP Operations
- Configuring TCP Connect Operations
- Configuring ICMP Echo Operations
- Configuring ICMP Path Echo Operations
- Configuring ICMP Path Jitter Operations
- Configuring FTP Operations
- Configuring DNS Operations
- Configuring DHCP Operations
- Configuring DLSw+ Operations
- Configuring a Multioperation Scheduler
- Configuring Proactive Threshold Monitoring of IP SLAs Operations
- Finding Feature Information
- Contents
- Prerequisites for ICMP Path Jitter Operations
- Restrictions for ICMP Path Jitter Operations
- Information About IP SLAs ICMP Path Jitter Operations
- How to Configure the IP SLAs ICMP Path Jitter Operation
Configuring Cisco IOS IP SLAs ICMP Path Jitter Operations
This document describes how to configure a Cisco IOS IP Service Level Agreements (SLAs) Internet Control Message Protocol (ICMP) Path Jitter operation to monitor hop-by-hop jitter (inter-packet delay variance). This document also demonstrates how the data gathered using the Path Jitter operations can be displayed and analyzed using Cisco IOS commands.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for IP SLAs ICMP Path Jitter Operations" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•Prerequisites for ICMP Path Jitter Operations
•Restrictions for ICMP Path Jitter Operations
•Information About IP SLAs ICMP Path Jitter Operations
•How to Configure the IP SLAs ICMP Path Jitter Operation
•Configuration Examples for IP SLAs ICMP Path Jitter Operations
•Feature Information for IP SLAs ICMP Path Jitter Operations
Prerequisites for ICMP Path Jitter Operations
•Before configuring any IP SLAs application, you can use the show ip sla application command to verify that the operation type is supported on your software image.
•In contrast with other IP SLAs operations, the IP SLAs Responder does not have to be enabled on either the target device or intermediate devices for Path Jitter operations. However, the operational efficiency may improve if you enable the IP SLAs Responder.
Restrictions for ICMP Path Jitter Operations
•The IP SLAs ICMP Path Jitter operation is ICMP-based. ICMP-based operations can compensate for source processing delay but cannot compensate for target processing delay. For more robust monitoring and verifying, use of the IP SLAs UDP Jitter operation is recommended.
•The jitter values obtained using the ICMP Path Jitter operation are approximates because ICMP does not provide the capability to embed processing times on routers in the packet. If the target router does not place ICMP packets as the highest priority, then the router will not respond properly. ICMP performance also can be affected by the configuration of priority queueing on the router and by ping response.
•The path jitter operation does not support hourly statistics and hop information.
•Unlike other IP SLAs operations, the ICMP Path Jitter operation is not supported in the RTTMON MIB. Path Jitter operations can only be configured using Cisco IOS commands and statistics can only be returned using the show ip sla commands.
•The IP SLAs Path Jitter operation does not support the IP SLAs History feature (statistics history buckets) because of the large data volume involved with Jitter operations.
•The following commands, available in Path Jitter configuration mode, do not apply to Path Jitter operations:
–history buckets-kept
–history distributions-of-statistics-kept
–history enhanced
–history filter
–history hours-of-statistics-kept
–history lives-kept
–history statistics-distribution-interval
–samples-of-history-kept
–lsr-path
–tos
–threshold
–verify-data
Information About IP SLAs ICMP Path Jitter Operations
ICMP Path Jitter Operation
The IP SLAs ICMP Path Jitter operation provides hop-by-hop jitter, packet loss, and delay measurement statistics in an IP network. The Path Jitter operation functions differently than the standard UDP Jitter operation, which provides total one-way data and total round-trip data.
The ICMP Path Jitter operation can be used a supplement to the standard UDP Jitter operation. For example, results from the UDP Jitter operation may indicate unexpected delays or high jitter values; the ICMP Path Jitter operation could then be used to troubleshoot the network path and determine if traffic is bottlenecking in a particular segment along the transmission path.
The operation first discovers the hop-by-hop IP route from the source to the destination using a traceroute utility, and then uses ICMP echoes to determine the response times, packet loss and approximate jitter values for each hop along the path. The jitter values obtained using the ICMP Path Jitter operation are approximates because ICMP only provides round trip times.
The ICMP Path Jitter operation functions by tracing the IP path from a source device to a specified destination device, then sending N number of Echo probes to each hop along the traced path, with a time interval of T milliseconds between each Echo probe. The operation as a whole is repeated at a frequency of once every F seconds. The attributes are user-configurable, as shown here:
How to Configure the IP SLAs ICMP Path Jitter Operation
•Configuring the IP SLAs Responder on a Destination Device (optional)
•Configuring an ICMP Path Jitter Operation on the Source Device (required)
•Scheduling IP SLAs Operations (required)
Configuring the IP SLAs Responder on a Destination Device

Note An IP SLAs Responder is not required on either the target device or intermediate devices for Path Jitter operations. However, operational efficiency may improve if you enable the IP SLAs Responder.
Prerequisites
The networking device to be used as the responder must be a Cisco device and you must have connectivity to that device through the network.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip sla responder
4. exit
DETAILED STEPS
Configuring an ICMP Path Jitter Operation on the Source Device
Perform only one of the following procedures in this section:
•Configuring the IP SLAs Responder on a Destination Device
•Configuring an ICMP Path Jitter Operation with Additional Parameters
Configuring a Basic ICMP Path Jitter Operation
SUMMARY STEPS
1. enable
2. configure terminal
3. ip sla operation-number
4. path-jitter {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname}] [num-packets packet-number] [interval milliseconds] [targetOnly]
5. frequency seconds
6. end
DETAILED STEPS
Examples
In the following example, the targetOnly keyword is used to bypass the hop-by-hop measurements. With this version of the command, echo probes will be sent to the destination only.
Router(config)# ip sla 1
Router(config-ip-sla)# path-jitter 172.17.246.20 num-packets 50 interval 30 targetOnly
Configuring an ICMP Path Jitter Operation with Additional Parameters
SUMMARY STEPS
1. enable
2. configure terminal
3. ip sla operation-number
4. path-jitter {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname}] [num-packets packet-number] [interval milliseconds] [targetOnly]
5. frequency seconds
6. owner owner-id
7. request-data-size bytes
8. tag text
9. timeout milliseconds
10. vrf vrf-name
11. exit
DETAILED STEPS
Scheduling IP SLAs Operations
Restrictions
•The frequency of all operations scheduled in a multioperation group must be the same.
•Operation ID numbers are limited to a maximum of 125 characters. Do not give large integer values as operation ID numbers.
SUMMARY STEPS
1. enable
2. configure terminal
For individual IP SLAs operations only:
3. ip sla schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]
For multioperation scheduler only:
4. ip sla group schedule group-operation-number operation-id-numbers schedule-period schedule-period-range [ageout seconds] [frequency group-operation-frequency] [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}]
5. exit
6. show ip sla group schedule
7. show ip sla configuration
DETAILED STEPS
Examples
In the following example, a Path Jitter operation is configured to run over a VPN using the VRF "red" to the CE at 10.3.30.130:
Router# configure terminal
Enter configuration commands, one per line. End with the end command.
Router(config)# ip sla 7
Router(config-ip-sla)# path-jitter 10.3.30.130
Router(config-ip-sla-pathJitter)# vrf red
Router(config-ip-sla-pathJitter)# exit
Router(config)# ip sla schedule 7 start-time now life forever
Troubleshooting Tips
Use the debug ip sla trace and debug ip sla error commands to help troubleshoot issues with an IP SLAs operation.
What to Do Next
To view and interpret the results of an IP SLAs operation use the show ip sla statistics command. Checking the output for fields that correspond to criteria in your service level agreement will help you determine whether the service metrics are acceptable.
Configuration Examples for IP SLAs ICMP Path Jitter Operations
•Example: Configuring a Path Jitter Operation
Example: Configuring a Path Jitter Operation
The following example shows the output when the ICMP Path Jitter operation is configured. Because the path jitter operation does not support hourly statistics and hop information, the output for the show ip sla statistics command for the path jitter operation displays only the statistics for the first hop.
The following example shows the output when the ICMP Path Jitter operation is configured.
Router# configure terminal
Router(config)# ip sla 15011
Router(config-sla-monitor)# path-jitter 10.222.1.100 source-ip 10.222.3.100 num-packets 20
Router(config-sla-monitor-pathJitter)# frequency 30
Router(config-sla-monitor-pathJitter)# exit
Router(config)# ip sla schedule 15011 life forever start-time now
Router(config)# exit
Router# show ip sla statistics 15011
Round Trip Time (RTT) for Index 15011
Latest RTT: 1 milliseconds
Latest operation start time: 15:37:35.443 EDT Mon Jun 16 2008
Latest operation return code: OK
---- Path Jitter Statistics ----
Hop IP 10.222.3.252:
Round Trip Time milliseconds:
Latest RTT: 1 ms
Number of RTT: 20
RTT Min/Avg/Max: 1/1/3 ms
Jitter time milliseconds:
Number of jitter: 2
Jitter Min/Avg/Max: 2/2/2 ms
Packet Values:
Packet Loss (Timeouts): 0
Out of Sequence: 0
Discarded Samples: 0
Operation time to live: Forever
Additional References
Related Documents
|
|
---|---|
Cisco IOS commands |
|
Cisco IOS IP SLAs commands |
|
Cisco IOS IP SLAs: general information |
"Cisco IOS IP SLAs Overview" chapter of the Cisco IP SLAs Configuration Guide. |
Standards
|
|
---|---|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by features in this document. |
— |
MIBs
RFCs
|
|
---|---|
RFC 18891 |
RTP: A Transport Protocol for Real-Time Applications; see the section "Estimating the Interarrival Jitter" |
1 Support for the listed RFC is not claimed; listed as a reference only. |
Technical Assistance
Feature Information for IP SLAs ICMP Path Jitter Operations
Table 1 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Note Table 1 lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.