This chapter describes how to configure an IP Service Level Agreements (SLAs) UDP jitter operation to analyze round-trip delay, one-way delay, one-way jitter, one-way packet loss, and connectivity in networks that carry UDP traffic in IPv4 networks. This chapter also demonstrates how the data gathered using the UDP jitter operation can be displayed and analyzed using the Cisco software commands.
The IP SLAs UDP jitter operation can diagnose network suitability for real-time traffic applications such as voice over IP (VoIP), video over IP, or real-time conferencing.
Jitter means inter-packet delay variance. When multiple packets are sent consecutively from source to destination, for example, 10 ms apart, and if the network is behaving ideally, the destination should be receiving them 10 ms apart. But if there are delays in the network (such as queuing, arriving through alternate routes, and so on) the arrival delay between packets might be greater than or less than 10 ms. Using this example, a positive jitter value indicates that the packets arrived greater than 10 ms apart. If the packets arrive 12 ms apart, then positive jitter is 2 ms; if the packets arrive 8 ms apart, then negative jitter is 2 ms. For delay-sensitive networks such as VoIP, positive jitter values are undesirable, and a jitter value of 0 is ideal.
However, the IP SLAs UDP jitter operation does more than just monitor jitter. As the UDP jitter operation includes the data returned by the IP SLAs UDP operation, the UDP jitter operation can be used as a multipurpose data gathering operation. The packets IP SLAs generates carry packet sending sequence and receiving sequence information, and sending and receiving time stamps from the source and the operational target. Based on these, UDP jitter operations can measure the following:
Per-direction jitter (source to destination and destination to source)
Per-direction packet-loss
Per-direction delay (one-way delay)
Round-trip delay (average round-trip time)
As the paths for the sending and receiving of data may be different (asymmetric), the per-direction data allow you to more readily identify where congestion or other problems are occurring in the network.
The UDP jitter operation functions by generating synthetic (simulated) UDP traffic. The UDP jitter operation sends N UDP packets, each of size S, sent T milliseconds apart, from a source switch to a target switch, at a given frequency of F. By default, ten packet-frames (N), each with a payload size of 10 bytes (S)are generated every 10 ms (T), and the operation is repeated every 60 seconds (F). Each of these parameters are user-configurable as shown in the following table.
Table 1 UDP Jitter Operation Parameters
UDP Jitter Operation Parameter
Default
Configured Using:
Number of packets (N)
10 packets
udp-jitter command, numpackets option
Payload size per packet (S)
32 bytes
request-data-size command
Time between packets, in milliseconds (T)
20 ms
udp-jitter command, interval option
Elapsed time before the operation repeats, in seconds (F)
60 seconds
frequency (IP SLA) command
Prerequisites for Configuring IP SLAs UDP Jitter Operations
The prerequisites for configuring IP SLAs UDP jitter operations are:
Time synchronization, such as that provided by NTP, is required between the source and the target device in order to provide accurate one-way delay (latency) measurements. Time synchronization is not required for the one-way jitter and packet loss measurements, however. If the time is not synchronized between the source and target devices, one-way jitter and packet loss data are returned, but values of “0” are returned for the one-way delay measurements provided by the UDP jitter operation.
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.
Guidelines and Limitations for UDP Jitter Operations.xml
When using IP SLA UDP probes, you might experience RTT spikes of up to 200 ms on the Cisco Nexus 7000 NX-OS Supervisor 1 and spikes of up to 35 ms on the Cisco Nexus 7000 NX-OS Supervisor 2. These are both known issues with the netstack architecture.
When IP SLA traffic exceeds 100 kbps, IP SLA operations might timeout. You can enter the no copp profile command to avoid this issue.
Configuring and Scheduling a UDP Jitter Operation on the Source Device
This section describes how to configure and schedule a UDP jitter operation.
Configuring the IP SLAs Responder on the Destination Device
This section describes how to configure the responder on destination device.
Note
A responder should not configure a permanent port for the same sender. If the responder configures the permanent port for the same sender, even if the packets are successfully sent (no timeout or packet loss issues), the jitter values are zero.
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Switch> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configure terminal
Example:
Switch# configure terminal
Enters global configuration mode.
Step 3
Do one of the following:
ip sla responder
Example: Switch(config)# ip sla responder
ip sla responderudp-echo ipaddressip-addressportport
Example: Switch(config)# ip sla responder udp-echo
ipaddress 172.29.139.132 port 5000
-
(Optional) Temporarily enables the responder functionality on a Cisco device in response to control messages from source.
(Optional) Required only if protocol control is disabled on a source. Permanently enables the responder functionality on specified IP addresses and port.
Control is enabled by default.
Step 4
exit
Example:
Switch(config)# exit
(Optional) Exits global configuration mode and returns to privileged EXEC mode.
Configuring and Scheduling a Basic UDP Jitter Operation on the Source Device
This section describes how to configure and schedule a basic UDP jitter operation on the source device.
Tip
If the IP SLAs operation is not running and generating statistics, add the verify-data command to the configuration of the operation (while configuring in IP SLA configuration mode) to enable data verification. When enabled, each operation response is checked for corruption. Use the verify-data command with caution during normal operations because it generates unnecessary overhead.
Use the debug ip sla sender trace and debug ip sla sender error commands to help troubleshoot issues with an IP SLAs operation.
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Switch> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configure terminal
Example:
Switch# configure terminal
Enters global configuration mode.
Step 3
ip slaoperation-number
Example:
Switch(config)# ip sla 10
Begins configuration for an IP SLAs operation and enters IP SLA configuration mode.
Configures the IP SLAs operation as a UDP jitter operation and enters UDP jitter configuration submode.
Use the control disable keyword combination only if you disable the IP SLAs control protocol on both the source and target switches.
Step 5
frequencyseconds
Example:
Switch(config-ip-sla-jitter)# frequency 30
(Optional) Sets the rate at which a specified IP SLAs operation repeats.
Step 6
exit
Example:
Switch(config-ip-sla-jitter)# exit
Exits UDP jitter configuration submode and returns to global configuration mode.
Step 7
ip sla scheduleoperation-number [life {forever| seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | afterhh:mm:ss}] [ageoutseconds] [recurring]
Example:
Switch(config)# ip sla schedule 5 start-time now life forever
Configures the scheduling parameters for an individual IP SLAs operation.
Step 8
exit
Example:
Switch(config)# exit
(Optional) Exits global configuration mode and returns to privileged EXEC mode.
Step 9
show ip sla configuration [operation-number]
Example:
Switch# show ip sla configuration 10
(Optional) Displays configuration values including all defaults for all IP SLAs operations or a specified operation.
What to Do Next
To add proactive threshold conditions and reactive triggering for generating traps, or for starting another operation, to an IP SLAs operation, see the "Configuring Proactive Threshold Monitoring" section.
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 helps you to determine whether the service metrics are acceptable.
Configuring and Scheduling a UDP Jitter Operation with Additional Characteristics
This section describes how to configure and schedule a UDP jitter operation with additional characteristics.
The IP SLAs UDP jitter
operation does not support the IP SLAs History feature (statistics history
buckets) because of the large data volume involved with UDP jitter operations.
This means that the following commands are not supported for UDP jitter
operations:
history buckets-kept,
history filter,
historylives-kept,
samples-of-history-kept, and
show ip sla history.
The MIB used by IP SLAs
(CISCO-RTTMON-MIB) limits the hours-of-statistics kept for the UDP jitter
operation to two hours. Configuring a larger value using the
history hours-of-statisticshours global configuration change does not increase the
value beyond two hours. However, the Data Collection MIB can be used to collect
historical data for the operation. For information, see the
CISCO-DATA-COLLECTION-MIB at
http://www.cisco.com/go/mibs).
Tip
If the IP SLAs operation is not running and generating statistics, add the verify-data command to the configuration of the operation (while configuring in IP SLA configuration mode) to enable data verification. When enabled, each operation response is checked for corruption. Use the verify-data command with caution during normal operations because it generates unnecessary overhead.
Use the debug ip sla sender trace and debug ip sla sender error commands to help troubleshoot issues with an IP SLAs operation.
Before You Begin
Before configuring a UDP jitter operation on the source device, the IP SLAs Responder must be enabled on the target device (the operational target). The IP SLAs Responder is available only on Cisco NX-OS software based devices. To enable the responder, perform the task in the “Configuring the IP SLAs Responder on the Destination Device” section.
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Switch> enable
Enables privileged EXEC mode.
Enter your password
if prompted.
Step 2
configureterminal
Example:
Switch# configure terminal
Enters global configuration mode.
Step 3
ipslaoperation-number
Example:
Switch(config)# ip sla 10
Begins configuration for an IP SLAs operation and enters IP SLA
configuration mode.
Switch(config)# ip sla schedule 5 start-time now life forever
Configures the scheduling parameters for an individual IP SLAs
operation.
Step 20
exit
Example:
Switch(config)# exit
(Optional) Exits global configuration mode and returns to
privileged EXEC mode.
Step 21
showipslaconfiguration
[operation-number]
Example:
Switch# show ip sla configuration 10
(Optional) Displays configuration values including all defaults
for all IP SLAs operations or a specified operation.
What to Do Next
To add proactive threshold conditions and reactive triggering for generating traps, or for starting another operation, to an IP SLAs operation, see
the Proactive Configuring Proactive Threshold Monitoring
.
To view and interpret the results of IP SLAs operations, 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 Example for a UDP Jitter Operation
The following shows two operations that are configured as UDP jitter operations, with operation 2 starting five seconds after the first operation. Both operations will run indefinitely.
ip sla 1
udp-jitter 20.0.10.3 65051 num-packets 20
request-data-size 160
tos 128
frequency 30
ip sla schedule 1 start-time after 00:05:00
ip sla 2
udp-jitter 20.0.10.3 65052 num-packets 20 interval 10
request-data-size 20
tos 64
frequency 30
ip sla schedule 2 start-time after 00:05:05
On the target (destination) device:
ip sla responder
Feature History for UDP Jitter
This table includes only the updates for those releases that have resulted in additions or changes to the feature.