Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

False latency on traceroutes

Hi,

i'm trying to isolate a problem i'm currently having on my network. here is an example trace:

from L3 switch (6509) to 3845

trace 172.17.3.116 sour 172.17.114.2

Type escape sequence to abort.

Tracing the route to 172.17.3.116

  1 172.17.126.53 20 msec 4 msec 0 msec

  2 172.17.3.54 4 msec 4 msec 0 msec

  3 172.17.3.116 148 msec *  140 msec

(hop 1 and 2 are in Manila and hop 3 is in US)

from a PC to 3845

Tracing route to 172.17.3.116 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  172.17.114.3 --> L3 switch above (6509)

  2    <1 ms    <1 ms    <1 ms  172.17.126.53

  3     1 ms    <1 ms     1 ms  172.17.3.56

  4    18 ms    29 ms    22 ms  172.17.3.116

Trace complete.

You'll notice in the second trace that this is not possible. At best, latency from Manila to US is around 140ms. Just wondering if any of you have encounterd this and could tell me what causes this, maybe just the PC or could it be my network?

Thanks and appreciate the help!

Geoffrey

Everyone's tags (2)
3 REPLIES

False latency on traceroutes

Hi

it is not pure network latencys, there is cpu latencys too.

response to the ICMP packets is not a first priority of cpu.

New Member

False latency on traceroutes

thanks ttemirgaliyev  for replying.

Understood that there are cpu latencys as well but if there were shouldn't the replies be higher or at least timed out. In this case, the replies are much faster.

Hall of Fame Super Silver

False latency on traceroutes

Geoffrey

The results that you post do seem a bit strange. I have a couple of observations and a suggestion.

- the hop after 172.17.126.53 is not the same in the traceroutes. The trace from the switch has  172.17.3.54 4 as the next hop while the trace from the PC has 172.17.3.56 as the next hop. Does this raise the possibility that there are different paths toward the destination. Perhaps different paths have different performance characteristics?

- the traceroute from the switch would be using UDP packets while the tracert from the PC will be sending ICMP. Is it possible that there is some QOS or traffic shaping or some thing going on that would treat UDP differently from ICMP?

- is it possible that there is some kind of route setup/activation going on (this could involve things like resolving ARP, or possibly activating some on demand circuit, or some kind of buffering) such that the first one is slow because things need to get set up and the second is faster because the path is already set up?

- if you do the traceroute twice or three times from each source before going on to the next is the switch traceroute always longer/slower? Or if you reverse the order and tracert from the PC before traceroute from the switch do you see the same difference in performance?

HTH

Rick

430
Views
0
Helpful
3
Replies
CreatePlease login to create content