I agree with this statement and am pleased you’re offering more than that, it makes for a good read and highlights things I hadn’t thought of myself. So, cheers for provoking thought, and thanks to Random Geek, too. I noticed that traceroute is meant for network troubleshooting and that it’s good to get a trace in both directions, although this is not always possible because plenty of systems block loose-sourced packets at their borders as a security measure these days.

There are some limitations to traceroute. Most notably, traceroute uses ICMP packets which are usually very low on the QoS (Quality of Service) scale. In other words, backbone providers typically decrease the priority of ping and traceroute because they really aren’t that critical. It’s good for a basic test, but isn’t really a good source of actual info. For congestion type of info, the only place you’ll get real data is from the router.

Second, when you traceroute, you’re only seeing your route to the destination. You don’t see the destination’s route back to you. Traffic on the internet is often not asymmetric meaning you could go through an entirely different set of routers (or even Internet providers) in either direction. This can put you on a wild goose chase if some link is broken on the return path because from your side, it appears that it’s the last router in the chain before it stops.