I think the "The Worst Diagnostics In The World" section is a bit simplistic about what traceroute does tell you. It can tell you lots of thing beyond "you can reach all the way". Specifically, it can tell you at least some of the networks and locations your packet went through and it can tell you how far it definitely got. These are extremely powerful tools as they rule out lots of problems. It's useful to be able to hand an ISP a "look, I can reach X location in your network and then the traceroute died" and they can't wonder "are you sure your firewall isn't blocking it?"
It's still a super-common tool for communicating issues between networking teams at various ASes. That the author's ISP thought they were too small to provide reasonable support to is not a strike against traceroute. Rather, it's a strike against that ISP.
Traceroute was immensely helpful for me figuring out why my favorite video game tend to have large latency and massive lag spikes.
Geographically, where I lived, my connection should have been about 220 miles directly to Chicago. Instead, my connection traveled about 180 miles west to Minneapolis then 350 miles down to Chicago. Because this involved a bunch of extra network switches, my packets would often get buffered and sometimes delivered out of order (this was obvious by how the game worked).
A fiber provider came to town and solved all of my connection issues. Not only was the connection inherently faster, but it had fewer hops and was routed more directly to Chicago (where this game had a datacenter).
I think I went from nearly 100ms ping to 10ms ping.
Nice! Back in the day I provided remote support and occasionally ran trace to diagnose data transfer issues. The few times there was a problem with a hop, there wasn’t anything that could be done. But each time I was able to find either a news article on inclement weather or a post on the ISP website about a network issue. Worked with a guy that spotted a car wreck from trace. Well, it was down the street and so was the trunk cnx.
Traceroute has helped me solve a lot of problems quickly and easily.
A few weeks ago I was volunteering for a local political party and they had several services down. They had no idea where they were hosted, how they were hosted, why, etc.
I ran traceroute on all of them and within minutes I was able to tell which ones were hosted together and approximately where, and when I brought that to the team it was enough information to jog memories and map IPs and WHOIS data to various services, data from email searches, etc.
Without that it would have been a lot of guesswork, possibly for days.
It turned out most of them were hosted by a service which moved their accounts to a new IP. One other was hosted elsewhere and turned out to be broken for longer than they realized.
So you like a tool or protocol that returns random results based on the time of the day, your location on earth and some tea leaves someone reads while on crack?
Because this is basically what you get from using traceroute and the article explains why.
You can use it when you control the part of the network you are using it on, but it shouldn't be used for debugging infrastructure you don't own/control/trust.
You can definitely use it for debugging infrastructure you don't own/control just fine. You just need to understand what it's telling you and not believe that it's telling you anything else beyond what it is.
It, as well as the internet routing it's trying to observe, is going to give you different results at different times. It's not going to give you "random" results. Unless your routers literally use coinflips to decide whether to forward or drop icmp. Only then would it give random results.
> It's useful to be able to hand an ISP a "look, I can reach X location in your network and then the traceroute died" and they can't wonder "are you sure your firewall isn't blocking it?"
I know what you mean, but this is not a panacea IMO. I just had to deal with a network that was blocking outbound traffic, by protocol, on non-standard ports (eg, HTTP would work fine to port 80, but not to port 8000 - and the connection would only get killed about 3 or 4 packets in), and one of the admins just had me do a traceroute to the IP in question, and went "well, the traffic makes it outside of our network, so it's not our fault".
More to the point the article goes on at length about why traceroute is a bad tool, but it doesn't offer any alternatives. Sure traceroute has issues and it can lead you astray if you don't understand what it is doing, but there isn't anything better. As the article points out the "proper" traceroute from the RFC was never implemented. Some of the other complaints like if you traceroute too much it might bog down the CPU on the routers seems just petty.
About all the article can say is that you'll probably just find out that the problem is in some other network and fixing other people's networks is impossible so don't even try, which is a depressingly defeatist attitude.
> Some of the other complaints like if you traceroute too much it might bog down the CPU on the routers seems just petty.
This part is actually important, not a petty thing. Not because we should care (much) about cpu usage on routers; packet routing is (or should be) 100% hardware offloaded and CPU usage doesn't matter for the main business of a router. But, it's important to be aware that sending ICMP reports is CPU limited and routers have limited CPU resources so there are limits on the reports that will be sent. Then you need to know that measured loss at one hop may indicate loss from that hop or a busy router.
There's probably many better ways to present this information, but if the point is to argue that when things don't work, the best thing to do is wait a week and let things sort themselves out... Well I don't like that either.
It's still a super-common tool for communicating issues between networking teams at various ASes. That the author's ISP thought they were too small to provide reasonable support to is not a strike against traceroute. Rather, it's a strike against that ISP.