Showing results for 
Search instead for 
Did you mean: 

Mesure of jitter based on ping command

Level 1
Level 1


I would like to measure the jitter based on ping command. From the ping command, I get the round-trip time. I'll get the latency by dividing the average round-trip time by 2. Then, I want to calculate that f.e. for 30 packets, and then calculate the jitter(difference between the previous and next average latency). Still, how can I get the information on the round-trip time for every packet sent in the terminal of my 7200 router in GNS3?

Maybe I can do that automatically using third-party software?
I want to calculate the jitter for f.e. 500 packets sent.

Any help will be much appreciated!


1 Accepted Solution

Accepted Solutions

Thank you both @MHM Cisco World and @Joseph W. Doherty for the clues and for pointing me towards IP SLA.
I performed the tests with it. Finally, I've managed to get to working the IPv6 version in

ip sla

configuration mode. I've used

c7200-adventerprisek9-mz.152-4.S4 image in GNS3 and configured udp-jitter

(there was no


with this version of IOS).
Additionally, I've managed to get the latency section working. I've synced sending, receiving, and all the routers along the path with the same NTP server(additionally, set the timezone and ntp update-calendar on all the routers). After checking the time on all of them I scheduled the

ip sla 

and indeed, the times showed up. 

View solution in original post

21 Replies 21

Joseph W. Doherty
Hall of Fame
Hall of Fame

"Stock" jitter would not be suitable for jitter measurements.

Dividing RTT by 2 doesn't really tell you latency, because latency is unique per direction.  For example a RTT of 20 ms, might comprise 5 ms latency outbound and 15 ms latency inbound, or 13 ms latency outbound and 7 ms latency inbound, or . . .

Unsure your 7200 IOS in GNS would support IP SLA (or the earlier RTR), but look into those features for the IOS version/variant you're using.

Thank you both @Joseph W. Doherty @MHM Cisco World for the answer. I did dig into the

IP sla

feature and managed to come up with a configuration. I wanted to send 500 packets once, with the size of 64/200/400 etc. which I wanted to be specified under the

ip sla 1

but there is no command related to packet size. 
I've search the internet but I couldn't find the parameter. It is needed for me to specify it because my research relies on it.

Additionally, I've noticed, that


doesn't support IPv6 as a destination/source IP. What would be the solution for this?

I would be grateful to receive any help! 

PEdge1(config)#ip sla 1

PEdge1(config-ip-sla)#icmp-jitter source-ip num-packets 500 interval 4

PEdge1(config-ip-sla-icmpjitter)#history hours-of-statistics-kept 1

PEdge1(config-ip-sla-icmpjitter)#tag ICMPJitterToCustA1

PEdge1(config-ip-sla-icmpjitter)#tos 160

PEdge1(config-ip-sla-icmpjitter)#vrf 101:CustA

PEdge1(config-ip-sla-icmpjitter)#packet-size 64  <- here i thought that i would include the command, but the packer-size is not supported


packet-size 100

PEdge1(config)#ip sla reaction-configuration 1 react rtt action-type trapOnly

PEdge1(config)#ip sla reaction-configuration 1 react jitterAvg action-type trapOnly

PEdge1(config)#ip sla reaction-configuration 1 react latencyDSAvg action-type trapOnly

PEdge1(config)#ip sla schedule 1 life-count 1 start-time now

Supported commands under icmp-jitter command: 
IP SLAs Icmp Jitter Configuration Commands:
default Set a command to its defaults
exit Exit operation configuration
frequency Frequency of an operation
history History and Distribution Data
no Negate a command or set its defaults
owner Owner of Entry
tag User defined tag
threshold Operation threshold in milliseconds
timeout Timeout of an operation
tos Type Of Service
vrf Configure IP SLAs for a VPN Routing/Forwarding instance

"Additionally, I've noticed, that


doesn't support IPv6 as a destination/source IP. What would be the solution for this?"

Probably, a later IOS version.  Here it's mentioned supported in IPv4 and IPv6.  Possibly you won't be able to find a new enough router/IOS to run in GNS3 using such a version.

but there is no command related to packet size."

Possibly a later IOS version might support, or possibly not.

For most (?) practical purposes, packet size shouldn't be relevant, since it's a delta value of arrival times of multiple packets different from what's expected.

My idea @Joseph W. Doherty was to implement 6VPE and tunneling in MPLS IPv4 Core network and measure throughput, latency, and jitter of both of them and compare, which of these IPv6 transition mechanisms is faster, has lower latency and jitter. So I wanted to test it for both IPv4 and IPv6 and for different packet sizes(f.e. 64, 200, 400, etc.).

That's why I wanted in the first place to use a simple ping command and calculate the throughput and latency. With jitter, it's another story because as I mentioned, I would need to calculate the difference between the latency of n-1 and n repeat, take the absolute value, sum the values of every repeat and divide by the number of them. But it's a tedious process and I don't even know how to print every response (which will have RTT) -  I've also searched for a solution and couldn't find one.
Maybe these three metrics are a bad idea to measure and compare both of the transition mechanisms in GNS3. If so, I'm open to different suggestions.



I would suggest you go ahead and use what IP SLA offers.  If there are gross differences, IP SLA testing is likely to be "good enough" for "seeing" gross differences and/or differences from what should be expected from the technology being used.

The level of testing and/or detail you appear to be after, often is only needed when you're running down an issue why your overall performance isn't as expected, and even in such cases, what's unexpected often stems from not understanding the technology.


Perhaps a real case example, why I'm of such opinion, a couple of decades ago, a large Enterprise was offered "like" ATM circuits to replace frame-relay circuits, i.e. "like" in same bandwidth for about 15% less cost.

Well, that Enterprise jumped at reducing their data line costs by 15%.  So, they started to move to ATM and noticed WAN throughput performance dropped through the floor for the same "spec" circuits.  So, they asked me to investigate.

Many of the frame-relay links were DS1s with a "CIR" being some fraction of the full link bandwidth, e.g. CIR of 512 Kbps on a 1.5 Mbps link.  With frame-relay, you can "burst" over CIR, to max link bandwidth.

The replacement ATM links would be "like", e.g. SCR of 512 Kbps, PCR of 1.5 Mbps on a 1.5 Mbps DS1.

As in turned out, when ATM links were configured for SCR of 512 Kbps and PCR of 1.5 Mbps, the PCR is only good for a very short duration, like enough for one or two max size Ethernet frames, then the ATM interface maintains SCR.

FR, though, would run at full link rate unless you explicitly shaped your interface.

So, effectively, FR could run all the time at 1.5 Mbps, while ATM would average a max of 512 Mbps.  This is why such an impact was noticed.

First step was to "lie" to ATM interface, and set SCR to 1.5 Mbps.  Then FR and ATM DS1 should (?) perform the same.  However, ATM still averaged about 15% less (enough, still, to be quite noticeable) throughput.  (Hmm, what was the price difference, again?)

The reason ATM still had less throughput, a packet had to be split into ATM cells, each 53 bytes, with 48 bytes for payload.   I.e. you lose 9.5% bandwidth for "cell tax".  Then as every cell had to be exactly 53 bytes, you would need to pad out the last cell.  E.g. a 64 byte packet, like an ACK, would require two 53 bytes cells, i.e. you now lose about 40% of your bandwidth for overhead.  Lastly, if even one cell in a transmitted packet was lost, the whole packet would have to be retransmitted.

So, if someone had studied the technology or tried even the simplest of performance tests, on one ATM link, these gross differences, should not have gone unnoticed before the Enterprise committed to making a mass conversion to ATM.

Oh, BTW, ATM required new interface modules for the routers, and those ATM modules required an IOS feature upgrade (from IPBase to IPServices) which also increased contract maintenance costs. It surely "saved" money.

Lastly, there's nothing wrong with using ATM, and it does offer some features that FR doesn't.  One useful feature, was the ATM modules were IMUX capable, i.e. you could connect multiple DS1s and the bundle would act as a single link with the aggregate bandwidth of bundle (in principle, much like MLPPP, but wire-rate).  Very handy to replace one FR DS1 with two ATM DS1s, which more than replaced the lost bandwidth for a single FR DS1 vs. ATM DS1.  ;  )

Thank you @Joseph W. Doherty for this amazing response and clarification. I think I'll go with IP sla for testing both cases.
The issue is that I'm not able to use sla for IPv6 with 7200 - c7200-adventerprisek9-mz.152-4.M7. I tried to search the Internet for the appropriate version of ISO and maybe the router and came across CSR1000v. I added the template for csr1000v-universalk9.16.12.03-serial IOS version to GNS3 and still no support for the IPv6 sla.
Maybe you had a chance to configure sla for IPv6 and are aware of the type of router and IOS I could try in GNS3?


"Maybe you had a chance to configure sla for IPv6 . . ."

Sorry, I have not.

". . . are aware of the type of router and IOS I could try in GNS3?"

If Cisco still offers what they call their Feature Navigator, that may lead to what IOS versions support IPv6 and SLA, knowing that, you should then be able to find what routers accept that IOS variant.


connect host  to each CE side 
run the


 for size (I check there is no command to change size) you can config IP mtu in host with value you want 
this make sure that only specific value will pass through MPLS Core 

host here is Router that run

icmp-jitter and ip mtu

config in CE interface 

I did try to connect VPC to my CustomerA(CE) router, but there is no MTU configuration inside its console. I can configure MTU for the CE router's interface the host is connected to and the MTU range is 1500-1530 so still not satisfying.
Please correct me if I'm wrong about something.

friend I clear in my reply use router as host 


this will give you automatic info. about jitter in your network 
now packet size, we can not control packet size but we can config CE to fragment the packet and send the number we want 
in end we want to test your network jitter for specific packet size whatever the packet size source from router origin the traffic or from CE that fragment the packet, 

I tried to set up


on host Router1 but unfortunately,


failed. It is probably due to a lack of VRF configuration. I can't specify on Router 1

 vrf in icmp-jitter

configuration mode.
I did issue the configuration on PEdge1, results are below. 
> "[...]we can config CE to fragment the packet and send the number we want in end[...]"
So basically I can set the MTU in the range of  <1500-4470> size, and by setting it to 1600, the packets will be sent with 1600 bytes size.

Two more things that worry me.
1. In the configuration of IP sla I did issue a number of packets equal to 500, but in the 

show ip sla stat

I see that only 330 packets got processed and 170 were not. What's the reason for it?
2. Another thing is that I don't see any values in a latency section. Is it because my configuration is wrong?


Cisco IOS IP SLAs Command Reference - icmp-echo through probe-packet priority [Support] - Cisco

Screenshot (567).png

for the packet 330, this is correct since there is 170 unprocessed packet (check output you share)

1. Of course that 330 were processed and 170 were not is correct, but I wanted to know why only 330 of them get processed. I guess it's because some of the packets got unprocessed because they did not meet the default thresholds in

ip sla reaction-configuration. 

I did set up the new configuration of 

ip sla reaction-configuration

with thresholds of 1 1 ms. I thought that it would set every packet off and all 500 of them will be processed. What am I missing?

2. The thing about the latency still does bother me. I don't know why setting the threshold to 1 ms did not set it off.

PEdge1(config)#ip sla reaction-configuration 1 react rtt action-type trapOnly threshold-type immediate threshold-value 1 1

PEdge1(config)#ip sla reaction-configuration 1 react jitterAvg action-type trapOnly threshold-type immediate threshold-value 1 1

PEdge1(config)#ip sla reaction-configuration 1 react latencyDSAvg action-type trapOnly threshold-type immediate threshold-value 1 1

PEdge1(config)#ip sla reaction-configuration 1 react latencySDAvg action-type trapOnly threshold-type immediate threshold-value 1 1


Review Cisco Networking for a $25 gift card