81–90 of 116 posts
On the other hand traceroute isn’t real[0] 0: https://gekk.info/articles/traceroute.htm
this article is informative but misleading. i do the testing at a big ISP (your packets go over us for at least something). we test traceroute. we complain to vendors when traceroute doesn't work right. we do investigate weird traceroutes.
I'm in South East Asia -- are you sure?
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.
Both asymmetric routing and ECMP routing are visible from L3. In the latter case, the routing decision can utilize some L4 data, so some L4 frobbing to get useful data points in practice is necessary for useful real-world diagnosis.
I agree with others that the OSI model is a good metaphor and a framework for reasoning about networking, but it is far from perfect, and the reality for those designing and operating network protocols and devices is messy.
MPLS is admittedly invisible and there isn't a thing you can do about it in the same way that you can't expect traceroute to give you a view of the switch ports it went through on a LAN. Of course it is useful to understand and keep in mind the fact that there may be, sometimes huge, gaps in your traceroutes. A sudden huge jump in RTT from one hop to the next can be confusing when trying to understand and troubleshoot a network issue.
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,…
how-did-i-get-here: "A tool/website/article by @kognise about how routing on the Internet works."
Site: https://how-did-i-get-here.net/
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,…
DWDM protected waves, MPLS, etc, are all out of scope when someone does a traceroute, finds their traffic is going to Europe asks me about it, and then I see a local upstream has picked up Cogent as a transit provider, and Cogent is preferring their customer routes over routes from their Tier 1 settlement free peers.
But this article is very much a primer, it's using the unix format of traceroute and talking about ICMP.
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.
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…
To be fair, that entire traceroute never touches "the Internet". Everything after hop 6 is inside Google's backbone network, and everything before hop 7 is inside Linode/Akamai.
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?
If the destination machine has disabled ping, what response is recieved?
“ping” is ICMP ECHO_REQUEST and ICMP ECHO_RESPONSE. Traceroute uses ICMP TIME_EXCEEDED. So blocking only “ping” will not affect traceroute. And if you block all ICMP, you break your own internet: http://shouldiblockicmp.com/ >