Electronic devices sometimes have test points on their circuit boards, and you may get documentation for those which tells you what to measure, how and how to interpret the values. These devices are analogous to a protocol with telemetry.
Devices that don't have such a thing are like hosts that may or may not give you an ICMP message. You're on your own, reverse engineering and guessing.
The author says that the latter approach isn't "real".
If an object is man-made, investigating it empirically using the scientific method, using whatever tricks are available, including the repurposing of its features, is off the table and the results are not real.
OK, a few idiots think that if traceroute shows node 6 and node 8, node 7 must be down. So what?
A few idiots probably also think that if they put an ohmmeter on a resistor that is soldered into a circuit, they can read off that resistor's resistance.
Or that if a 10V battery reads 8.5V, it's still 85% full!
>You're on your own, reverse engineering and guessing. The author says that the latter approach isn't "real". [...] ,
No, that isn't what the author is saying about "real". He's not saying that using some common sense problem-solving is "not real" as you're claiming.
Instead, he's saying official industry support for traceroute is what's "not real". Example quote: "For a good summary I highly recommend this presentation. But as good as that deck is, I always felt it left out a crucial piece of information: Traceroute, as far as the industry is concerned, does not exist."
To your credit, I don't think it's your fault for misinterpreting it since the author went for a "cute" title instead of just plainly stating limitations of traceroute in a non-dramatic way.
This following outlines the writing style the author used that inadvertently caused readers to hyperfocus on the word "real" instead of just agreeing or disagreeing on the actual points about "limitations of traceroute":
- step 1: define "not real" in a very specific idiosyncratic way so it conveniently creates a nice shock-value blog "title". E.g. "With the powers vested to me as author of this blog, I'm going to use "Not Real" to mean ... no modern-RFC, and no ironclad legally-binding SLA for ICMP/UDP/TTL responses from all network hosts, and no hidden performance hacks or dropping of packets, etc." (Basically, he's saying that there's no perfect cooperation/coordination between all actors in the network so that means "traceroute isn't real" in his constrained definition.) And bonus points for creating a special definition "not real" that is so nuanced that no casual reader could hold it in their head.
- step 2: write in a condescending way ("everyone was wrong") so that traceroute appears completely useless and any user is clueless for even trying it as a diagnostic tool
The author's writing style undermined the effect he wanted since the end result is a reader like you thinking he meant "reverse engineering as a problem-solving technique isn't real".
The author has latched onto one problem with traceroute, that hosts do not reliably generate the ICMP error. From that one thing (that everyone halfway knowledgeable in networking already knows) he generated a huge diatribe.
It's obvious that the author means "not real" in the same way that i = a[i++] returning a particular value on one C compiler is "not real". There are no engineering requirements anywhere which give you specifics that you can rely on.
Yes, traceroute is "not real" in a similar way.
What it means is that you probably don't want to be writing an application in which you run traceroute and have the code making important decisions based on what is scraped from the output.
Traceroute gives real information though: yes, that host #5 you see in the list really did drop the TTL-dead packet and sent you the ICMP notice. Yes, the repeated listing of hosts 9, 10, 9, 10, 9, 10 .. almost certainly mean they have a routing loop between them.
My argumentation is that people have to investigate and predict the behavior of systems that are not specified by any engineering requirements. For instance, we have meteorologists who predict the weather, imperfectly. The weather doesn't come with a metrics API and reference manual so meteorology isn't real. And look, it's often hardly better than a wild guess more than about 4 days out.
Maybe traceroute is like a weather radar. It tells you there are some droplets in the air out to the northeast, about 15 miles away. Maybe it's rain, maybe not; or is it a swarm of locusts? Those radars are useful nonetheless and pretty real.
I am a bit baffled by the arguments about what the author meant. (Needless to say, people who “prove” they can run `traceroute yahoo.com` are hopeless.)
Traceroute is a byproduct of a complex process that may match the forward path of real application traffic you send to some address. It may not if you have some local (transparent) proxy for certain protocols, or QoS in the middle (that may mis-classify your application traffic, unlike regular ICMP pings), or intrusion detection system, DoS protection system, or low level load balancer on the other end. The author invites to check another explanation multiple times, and it gives at least one example when replies from a certain hop are canonically sent by a different network hop. Some ISPs use IP addresses from private ranges, and they surface in traceroutes. Some ISPs lease others' infrastructure, and you see those IP addresses and DNS names inside their networks. Some ISPs deliberately mess with low TTL packets to cloak details like those from clients and competitors, and keep their physical network layout secret.
You need to know all of that, from ARP to BGP, to understand traceroute output. You also need to remember that one post in network engineering community a month ago that told that ISP M was bought by Corp N to guess that they are probably switching traffic from leased line between IX A and IX B to Corp N's own lines between City X and City Y, which might explain what you see. However, traceroute manual doesn't give you a list of 30 thick books to read in advance, nor does it contain the latest gossip about the state of ISP O's hardware in City Z. Therefore, unprepared user is not aware of all the possible complexities.
This reminds me of “helpful” websites that state that hosts with IP addresses of well known CDNs are located in California. Then people from all other the world run ping or traceroute, and deduce that they have a 10 ms RTT to California. Wow, such a great CDN!
Devices that don't have such a thing are like hosts that may or may not give you an ICMP message. You're on your own, reverse engineering and guessing.
The author says that the latter approach isn't "real".
If an object is man-made, investigating it empirically using the scientific method, using whatever tricks are available, including the repurposing of its features, is off the table and the results are not real.
OK, a few idiots think that if traceroute shows node 6 and node 8, node 7 must be down. So what?
A few idiots probably also think that if they put an ohmmeter on a resistor that is soldered into a circuit, they can read off that resistor's resistance.
Or that if a 10V battery reads 8.5V, it's still 85% full!