The IP Service Level Agreements (SLAs) UDP jitter operation diagnoses network suitability for real-time traffic applications such as VoIP, video over IP, or real-time conferencing.

Jitter means inter-packet delay variance. When multiple packets are sent consecutively from a source to a destination, for example, 10 ms apart, and if the network is behaving ideally, the destination should receive the packets 10 ms apart. But if there are delays in the network (like 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 packets arrived greater than 10 ms apart. If packets arrive 12 ms apart, then positive jitter is 2 ms; if packets arrive 8 ms apart, negative jitter is 2 ms. For delay-sensitive networks like 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 data returned by the IP SLAs UDP operation, the UDP jitter operation can be used as a multipurpose data gathering operation. The packets that IP SLAs generate carry packet-sending and receiving sequence information, and sending and receiving time stamps from the source and the operational target. Based on this information, UDP jitter operations are capable of measuring 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 paths for sending and receiving data may be different (asymmetric), the per-direction data allows 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. Asymmetric probes support custom-defined packet sizes per direction with which different packet sizes can be sent in request packets (from the source device to the destination device) and in response packets (from the destination device to the source device).

The UDP jitter operation sends N number of UDP packets, each of size S, T milliseconds apart, from a source device to a destination device, at a given frequency of F. In response, UDP packets of size P is sent from the destination device to the source device. 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 is user-configurable, so as to best simulate the IP service that you provide, as shown in the table below.

The IP SLAs operations function by generating synthetic (simulated) network traffic. A single IP SLAs operation (for example, IP SLAs operation 10) repeats at a given frequency for the lifetime of the operation.

IP SLAs UDP jitter is the most widely-used IP SLAs operation for measuring metrics such as round-trip time, one-way delay, jitter, and packet loss. The accuracy of measurements depends on the location where the time stamps are taken while the packet moves from the sender to responder, and back.

Typically, time stamps for IP SLAs operations are taken in the IP SLAs process at the Route Processor (RP). This time-stamp location results in inaccurate and inconsistent measurements because the time stamps are subject to scheduling delays experienced at the RP. QFP time stamping moves the location of the time stamping from the RP to the Cisco Packet Processor (CPP).

However, to measure the one-way delay, the clocks on the source and target devices must be synchronized. Because device CPP clocks cannot be synchronized directly to an external clock source, the RP clocks are synchronized with an external clock source and SNTP is used to synchronize RP and Forwarding Processor (FP) clocks. The accuracy of the RP-FP synchronization is poor. To address this issue, the enhanced UDP jitter probe in the QFP Time Stamping feature stores both the RP and CPP time stamps. RTT and jitter calculations utilize the CPP time stamps, and one-way calculations continue to be based on RP time stamping. Therefore, 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. One-way latency values are computed using RP time stamps are corrected by applying estimated-correction algorithms based on CPP time stamps.

QFP time stamping includes an enhanced UDP probe and enhanced responder. The devices on which the UDP probe and IP SLAs responder are configured must both be running Cisco software images that support QFP time stamping and the optimized time stamp location (for more accurate RTT measurements). If the UDP jitter operation is targeted to an responder on a device that does not support the optimized time stamp location, the IP SLAs probe will fail.

Note	A responder should not configure a permanent port for the same sender. If the responder configures a permanent port for the same sender, even if the packets are successfully sent (no timeout or packet-loss issues), the jitter values will be zero.

1.    enable


2.    configure terminal


3.    Do one of the following:

• ip sla responder
• ip sla responder udp-echo ipaddress ip-address port port

4.    exit

Device> enable

Device# configure terminal

Device(config)# ip sla responder

Device(config)# ip sla responder udp-echo ipaddress 172.29.139.132 port 5000

Device(config)# exit

1.    enable


2.    configure terminal


3.    Enter one of the following commands:

• 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]
• ip sla group schedule group-operation-number operation-id-numbers {schedule-period schedule-period-range | schedule-together} [ageout seconds] frequency group-operation-frequency [life {forever | seconds}] [start-time {hh:mm [:ss] [month day | day month] | pending | now | after hh:mm [:ss]}]

4.    end


5.    show ip sla group schedule


6.    show ip sla configuration

Device> enable

Device# configure terminal

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

Device(config)# ip sla group schedule 10 schedule-period frequency

Device(config)# ip sla group schedule 1 3,4,6-9 life forever start-time now 

Device(config)# ip sla schedule 1 3,4,6-9 schedule-period 50 frequency range 80-100

Device(config)# end

Device# show ip sla group schedule

Device# show ip sla configuration