Can you help me explain trace route in a very detailed way?! Well of course I know the purpose and how to use it but I just need to grab or explain something to our operations group about its output. They're so used to identifying latencies based on traces. Like for example, there's a website that they need to access where all their tools or application resides. Then they claim that there's latency, what they do is they conduct trace route and if they see a very high number somewhere in the middle, they are already assuming that this hop is causing the overall latency. Like the trace has total of 15 hops but at the 8th hop, it displays 500ms average but from 9th to 15th hop is low. And if you do a ping, the RTT is very low. I know there are routers that doesn't prioritize ICMPs that's why they response time is quite high.
I just need to know how to explain these things to them. In a very simple term and in a technical term. Thanks guys. :)
:: I'm hoping that I can get something different from this URL, http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTE4NSZuYW5vZzQ1&nm=nanog45
The times against each hop are the round trip times for each of the three probes for that one hop.
This link explains the Cisco IOS traceroute well:
It also has a section on performance which explains why a ping or traceroute is not a great measure of delay.
You could consider IP SLA for your customer as this is a much better way of determining the actual delay.
Really cool link...
Is there a link that explains why high response time sometimes appear on a trace route but it doesn't mean that the link is congested. There are people around here in the office that thinks all the values seen on a trace route is the response time of overall latency. Everytime they see a very high value in the middle of a trace, they want to reroute the traffic. Thanks.
In IP SLA (Fig 5 of the link) there are 2 timestamps at the target router, Time it arrives target router and time it leaves. So that gives a clear picutre whether link is congested or Target Router is busy.
Whereas in traceroute you dont know why latency is high due to cogestion or router took more time to process.
You will find during troubleshooting that responses from/to a router may appear slower than responses from/to traffic passing thru the router.
That's the reason you may find traceroutes or ping to the router to have a higher latency than traceroutes or ping to devices behind the router.
Add my 1 cent...
The one reason high response time on a trace from my understanding, Most ISPs are not willing to share their network topology to outside world from the security aspect, such as DOS attack,
so they hide the ICMP response packets, or response only one ICMP TTL exceeded message,when the traceroute packet reach the other side of the its network.
So you wont see the path inside the ISP network, but actually the packet was passed throu a lot of routers or nodes already
Thanks for the really cool link too.. Will keep this on my bookmarks.
But what about my question earlier, how can I tell them that a trace route to an internet website with one 500ms in the middle of the trace doesn't mean that the internet has a latency. Thanks.
I think my first link explains that question too. The reasons are:
1) Hosts, Servers and Routers class replying with ICMP as low priority so if they have web traffic or other more important traffic to deal with first they will always process that traffic before replying to ICMP.
2) The ICMP / UDP used in ping and traceroute does not get the same QoS as web traffic and will most likely be best effort across the whole path.
3) Any good web server administrator would be rate limiting pings or non web traffic to their web server.
So the reason why one probe might suddenly show a higher round trip time is because the server or links in the path were busy dealing with more important traffic first.