It all really comes down to time. Sometimes it can take dozens of seconds or more for a traceroute to complete (especially if it is resolving domain names) whereas you can issue a multitude of pings in that period of time.
Additionally, I like to use a repeated ping to test a particular path sometimes. On the Windows command line, I add a -t to enable the continuous ping and monitor the results over time as I make changes to the network. Similarly, you can do this on a Cisco device by using the repeat keyword and then putting in a large value, like 1000.
Although you do get much the same information from a simple ping and a simple tracroute, you must remember that they work very differently. Depending on the platform, traceroute uses Layer 4 protocols like UDP while ping uses only Layer 3 ICMP. Knowing these differences will also help you in understanding the results you see.
I would just like to verify one thing. When a router receives a packet with a TTL of 1, the router can still process and accept it if its destined for itself, correct? Because for example, eBGP messages use a TTL of 1 by default and they’re not dropped by the destination BGP neighbor.
However, if the router receives a packet with a TTL of 1 that still needs to be forwarded, it will just drop the packet and send back an ICMP Time Exceeded message, right?
And one more thing related to this, when exactly is the TTL decremented? The moment the router receives the packet or the moment it realizes it has to forward it somewhere, so it decrements it and ends with 0.
Hi, If you have traceroute latency at router 6 (out of 10) and router 7,8,9 work fine. Then what does that tell you? Does traceroute I tell you anything about latency? Can it cause a slow network?
According to the RFC 791, the TTL is incremented when the “header is processed”. In a router, that would be when the packet is processed for routing, that is, the process by which the exit interface is being determined.
First of all, remember that the output of the traceroute command shows the round trip time of echo requests from the source of the traceroute to each individual hop. So any delay you may see on one of the traceroute responses is the total delay from the source to that particular hop. (See this NetworkLessons note for more details.)
If router 6 has latency, and routers 7, 8, and 9 do not, this is not an indication that there’s something wrong with router 6. Remember, to get to routers 7, 8, and 9, you go through router 6. So if you don’t have latency after your echo request to router 6, then it’s not an issue of router 6 alone.
One question that you may ask yourself, is do I have response times from hop 6 that are consistently slow? Every time? If so, then there may be an issue with how router 6 processes responses to traceroute. It may be configured to put a smaller priority on such processes, and thus you are getting slower responses.
Ultimately, you should only be concerned with the performance of end-to-end communication with the intended destination, rather than a single entry in the traceroute responses. Does that make sense?