[SOLVED] Question about traceroute

Oct 24, 2020
1
0
10
I was wondering if this is packet loss. When I perform the tracert command on Windows, the speeds are good and no requests get timed out, until the middle when everything is timed out. At the end it goes back to normal.
 
Solution
Mostly because the routers in the path have been configured to not respond to trace and/or they prioritize passing actual data over responding.

This is mostly done to prevent denial of service attacks against routers. Someone could generate so much trace and ping traffic that the router runs out of cpu capacity.

There are other possibilities that are more technical. Mostly they are related to fact that the list of router you see in a tracert are only the routers going from you to the end test server. The path coming back may follow a completely different set of routers and you will not see these. So some router in the path may only see the traffic going in a single direction the traffic may not pass through that router...

xenthia

Distinguished
Sep 20, 2012
183
20
18,665
I was wondering if this is packet loss. When I perform the tracert command on Windows, the speeds are good and no requests get timed out, until the middle when everything is timed out. At the end it goes back to normal.
There could be many things affecting your tracert performance or the final results. Specially on windows with many drivers and firewall and configurations.
I personally always only get the best of tracert results on Linux to be able to fully trust them.
 
Mostly because the routers in the path have been configured to not respond to trace and/or they prioritize passing actual data over responding.

This is mostly done to prevent denial of service attacks against routers. Someone could generate so much trace and ping traffic that the router runs out of cpu capacity.

There are other possibilities that are more technical. Mostly they are related to fact that the list of router you see in a tracert are only the routers going from you to the end test server. The path coming back may follow a completely different set of routers and you will not see these. So some router in the path may only see the traffic going in a single direction the traffic may not pass through that router coming back. This is why tracert has very little value when there are actual issue in the middle of the path. You need to actually get into the routers in the path to see where traffic is going. You can to some limited extent do this if the ISP has what is called a looking glass site up that lets you run some commands from their routers.

In any case there is nothing you can do about any of this. Pretty much you only have control of hop 1 in the trace (your router) and to some extent hop 2 (the ISP first router). Problems past this would need to be the ISP that does something. In many cases it is not even yoru ISP that owns the routers and they like you can do nothing but maybe call up the other ISP and ask. This assume they even have a business relationship with the other ISP.
 
Solution