Exploring the Splunk Web Interface | Major Features and Preferences Welcome
to this in-depth guide to the Splunk Web interface! In this video, we
explore...
2 months ago
Thursday, October 28, 2010
Question 160
What would you configure to monitor jitter? You must provide an example using R1 and R2.
Subscribe to:
Post Comments (Atom)
3 comments:
simple udp-jitter monitor can be started and checked with ip sla
of course this can get way more complicated then this example
R1#sh run | s ip sla
ip sla 1
udp-jitter 10.0.0.2 16384
frequency 120
ip sla schedule 1 start-time now
R2#sh run | s ip sla
ip sla responder
R1#sh ip sla statistics
Round Trip Time (RTT) for Index 1
Latest RTT: 57 milliseconds
Latest operation start time: *09:09:24.929 UTC Fri Mar 1 2002
Latest operation return code: OK
RTT Values:
Number Of RTT: 10 RTT Min/Avg/Max: 10/57/129 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 8
Number of DS Jitter Samples: 8
Source to Destination Jitter Min/Avg/Max: 12/82/341 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/62/348 milliseconds
Packet Loss Values:
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 2
Number of failures: 0
Operation time to live: 3416 sec
R1#sh ip sla configuration
IP SLAs Infrastructure Engine-II
Entry number: 1
Owner:
Tag:
Type of operation to perform: udp-jitter
Target address/Source address: 10.0.0.2/0.0.0.0
Target port/Source port: 16384/0
Request size (ARR data portion): 32
Operation timeout (milliseconds): 5000
Packet Interval (milliseconds)/Number of packets: 20/10
Type Of Service parameters: 0x0
Verify data: No
Vrf Name:
Control Packets: enabled
Schedule:
Operation frequency (seconds): 120 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): 3600
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 4294967295
Enhanced History:
http://www.cisco.com/en/US/customer/docs/ios/ipsla/configuration/guide/12_4t/sla_12_4t_book.html
Thanks Dongle. The syntax and options vary depending on the IOS version. The other thing to mention is the criticality of time and the requirement for both devices to be configured to use NTP.
I have included a configuration from IOS version 12.4(25b).
R1
__
ip sla monitor 7
type jitter dest-ipaddr 10.0.0.2 dest-port 16384 source-ipaddr 10.0.0.1 codec g729a
ip sla monitor schedule 7 life forever start-time now
R2
__
ip sla responder
http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsoverv.html
From Cisco: Response Time Computation for Cisco IOS IP SLAs
Routers may take tens of milliseconds to process incoming packets, due to other high priority processes. This delay affects the response times because the reply to test packets might be sitting on queue while waiting to be processed. In this situation, the response times would not accurately represent true network delays. Cisco IOS IP SLAs minimizes these processing delays on the source router as well as on the target router (if Cisco IOS IP SLAs Responder is being used), in order to determine true round-trip times. Cisco IOS IP SLAs test packets use time stamping to minimize the processing delays.
When enabled, the Cisco IOS IP SLAs Responder allows the target device to take two time stamps both when the packet arrives on the interface at interrupt level and again just as it is leaving, eliminating the processing time. This time stamping is made with a granularity of sub-millisecond (ms). At times of high network activity, an ICMP ping test often shows a long and inaccurate response time, while an Cisco IOS IP SLAs test shows an accurate response time due to the time stamping on the responder.
Figure 3 demonstrates how the responder works. Four time stamps are taken to make the calculation for round-trip time. At the target router, with the responder functionality enabled time stamp 2 (TS2) is subtracted from time stamp 3 (TS3) to produce the time spent processing the test packet as represented by delta. This delta value is then subtracted from the overall round-trip time. Notice that the same principle is applied by Cisco IOS IP SLAs on the source router where the incoming time stamp 4 (TS4) is also taken at the interrupt level to allow for greater accuracy.
Figure 3 Cisco IOS IP SLAs Responder Time Stamping
An additional benefit of the two time stamps at the target router is the ability to track one-way delay, jitter, and directional packet loss. Because much network behavior is asynchronous, it is critical to have these statistics. However, to capture one-way delay measurements the configuration of both the source router and target router with Network Time Protocol (NTP) is required. Both the source and target need to be synchronized to the same clock source. One-way jitter measurements do not require clock synchronization.
Post a Comment