07-16-2007 08:39 AM - edited 03-03-2019 05:53 PM
Hi,
When I traceroute to a destination ip address in the network from the router, the last hop to reach the destination has one timed out problem as below
router#traceroute <dest-ip> address
Type escape sequence to abort.
Tracing the route to <dest-ip> address
1 <next-hop> 4 msec * 0 msec
I am just curious and would like to understand the reason for the 2nd probe getting timed out. I am not finding bad links and so wondering why that probe should be dropped. This characteristics, I am seeing in most of the networks and its particularly for the last hop when traced from the router.
Thanks
Regards
Anantha Subramanian Natarajan
Solved! Go to Solution.
07-16-2007 12:43 PM
Anantha
I believe that the difference is that the response from the intermediate hop is not destination unreachable but is Time To Live Expired. The IOS does not throttle these messages like it does the destination unreachable messages.
HTH
Rick
07-16-2007 09:11 AM
The default in IOS is to rate limit the "iCMP destination unreachable" messages to two per second.
Please refer to the IOS documentation for more information on this default behavior:
Hope this helps,
07-16-2007 12:27 PM
Thank you very much and its really good to know .............
But I am just curious how the intermediate hop doesn't get timed out as below
router#traceroute
Type escape sequence to abort.
Tracing the route to
1 < first-hop> 12 msec 12 msec 16 msec
2 < second-hop> 12 msec * 12 msec
Is that something I am missing .....
Once again, thanks for this answer.
Regards
Anantha Subramanian Natarajan
07-16-2007 12:43 PM
Anantha
I believe that the difference is that the response from the intermediate hop is not destination unreachable but is Time To Live Expired. The IOS does not throttle these messages like it does the destination unreachable messages.
HTH
Rick
07-16-2007 03:42 PM
Rick,
As always, you are absolutely correct.
Regards,
07-16-2007 06:30 PM
Harold
Thanks for the confirmation.
HTH
Rick
07-17-2007 08:32 AM
Hi Rick,
Got it, Thank you very much ...
Regards
Anantha Subramanian Natarajan
07-17-2007 10:39 AM
Anantha
I am glad that we were able to help you resolve your questions. Thank you for using the rating system to indicate that your question was resolved (and thanks for the rating). It makes the forum more useful when people can read a question and can know that they will read an answer that did resolve the question. I encourage you to continue your participation in the forum.
HTH
Rick
07-17-2007 02:03 PM
Hi Rick,
You people deserve the rating and I always liked this forum because it gives me answers :) ..I mean understandable answers.
Once again thanks and bye
Regards
Anantha Subramanian Natarajan
07-17-2007 10:57 AM
Rick,
my 2 cents-
There could be one more reason for this behaviour - the intermideate nodes has to make only routing/switching function, while the destination node has to reply to the service (in this case icmp/trace). ping/tracert are categorised as low priority by default. So depending upon the free/busy status of end node, the destination node may able to reply tracert request in timely manner or may not.
regards
Rakesh
=====
07-17-2007 11:16 AM
Rakesh
Actually when each intermediate node receives the traceroute probe packet, decrements the TTL, and if it gets to zero, then they must discard the packet and they must generate the ICMP error message about time exceeded. So each intermediate node must generate error messages similar to the error generated by the destination router. So the processing load is pretty much the same in the intermediate nodes as it is in the destination.
HTH
Rick
07-17-2007 02:21 PM
got it. Thanks for this input.
regards
Rakesh
=====
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide