61–70 of 116 posts
It always amazes me in-depth HN gets on pretty much any subject, yet the most basic cursory network page gets massive response Is there simply a total lack of understanding of how networks work in the tech community?
Earlier quoted context omitted.
Traceroute doesn't even show you a path. It shows you a bunch of devices that happened to have a packet when its TTL expired. Every item listed in traceroute's output is a different packet and can take a different path towards the destination. On a different subject, why are people writing blogs about topics that are in the "literature" already?
In English, route is synonymous with 'path'. Feel free to submit a PR if you disagree: https://man.openbsd.org/traceroute
I miss traceroute. It seems like more and more, the linked page is hypothetical, and what I get in practice is a couple of hops, an arbitrary number of "* * *" lines, and maybe the last host or two. It's so nice when it works. $ traceroute youtube.com traceroute to youtube.com (142.250.114.91), 30 hops max, 60 byte packets 1 10.202.10.88 (10.202.10.88) 0.384 ms 0.356 ms 0.342 ms 2 10.202.35.103 (10.202.35.103) 36.386…
traceroute noob - what do the * * * mean? A host is choosing not to participate and dropping data or something?
It could be because they were filtered at the boundary of the network. If source IPs are private (RFC-1918 or carrier grade NAT space), those ICMP messages should get dropped. This is Best Current Practice (BCP) 38, if you wanted to read more about it.
Ever want to know why IPv6 is so important? This is another reason why. Troubleshooting networks without globally significant IP addresses on the intermediate hops is a real pain.
Traceroute doesn't see 90% of the machines your packet passes through. When your packet leaves a router at some-pop-some-port-wherever, that fiber isn't usually the same piece of glass that plugs into the next hop. There's a whole chain of amplifiers and possibly multiplexers that handle it between here and there. Some of those provide reliable transport service, giving you the illusion of a fiber that never breaks,…
The OSI model exists for a reason. You don't think about the life of the electrons going through your processors when you code. Traceroute is a view at a certain level of abstraction. It also doesn't tell you if your packet was delivered using ethernet, wifi or a token ring. It just doesn't matter.
No. This is not what this output means.
People should not read more into what traceroute says than what it actually does.
* * * means that traceroute did not get an ICMP time exceeded for that probe. that's it. It says nothing about if you can actually reach the destination.
Earlier quoted context omitted.
In English, route is synonymous with 'path'. Feel free to submit a PR if you disagree: https://man.openbsd.org/traceroute
This isn't an English language question. The technology in question doesn't guarantee a singular route or a path to a destination. Subsequent packets from an originating host to a destination host can follow different paths. Even during an activity such as a traceroute. A packet that reached its TTL at what is presented as hop 12 didn't necessarily traverse previous hops displayed by traceroute.
Traceroute doesn't see 90% of the machines your packet passes through. When your packet leaves a router at some-pop-some-port-wherever, that fiber isn't usually the same piece of glass that plugs into the next hop. There's a whole chain of amplifiers and possibly multiplexers that handle it between here and there. Some of those provide reliable transport service, giving you the illusion of a fiber that never breaks,…
The OSI model exists for a reason. You don't think about the life of the electrons going through your processors when you code. Traceroute is a view at a certain level of abstraction. It also doesn't tell you if your packet was delivered using ethernet, wifi or a token ring. It just doesn't matter.
There's an analogy to networking there, too. You don't necessarily need to know how wave-division multiplexing, BGP, or DNS work to communicate over the Internet. For some categories of problems, though, a little bit of knowledge allows you to punch just a bit above your level.
If the destination machine has disabled ping, what response is recieved?
Earlier quoted context omitted.
Traceroute doesn't even show you a path. It shows you a bunch of devices that happened to have a packet when its TTL expired. Every item listed in traceroute's output is a different packet and can take a different path towards the destination. On a different subject, why are people writing blogs about topics that are in the "literature" already?
It’s not guaranteed to be accurate, but tracing using the UDP/dublin strategy with a fixed dest port and varying src port per round can help to identify and visualize valid ECMP flows. I recently wrote some guidance [1] on using Trippy in this way. [1] https://github.com/fujiapple852/trippy?tab=readme-ov-file#ud...
Traceroute and mtr didn't use enough ports to show the issue clearly.
Earlier quoted context omitted.
Traceroute doesn't even show you a path. It shows you a bunch of devices that happened to have a packet when its TTL expired. Every item listed in traceroute's output is a different packet and can take a different path towards the destination. On a different subject, why are people writing blogs about topics that are in the "literature" already?
It’s not guaranteed to be accurate, but tracing using the UDP/dublin strategy with a fixed dest port and varying src port per round can help to identify and visualize valid ECMP flows. I recently wrote some guidance [1] on using Trippy in this way. [1] https://github.com/fujiapple852/trippy?tab=readme-ov-file#ud...