Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The journey of an internet packet: Exploring networks with traceroute

sebastianmarines.com

Post reply on HN
Print view View original

51–60 of 116 posts

Re: The journey of an internet packet: Exploring networks with traceroute

#51

Post by myself248 »

latchkey wrote: post #31
myself248 wrote: post #23

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,…

> In my experience, this leads to two types of network engineers, separated by their understanding of these underlying realities. What's wrong with that? Certainly, someone with a complete picture is "better", but it is effectively two different types of problems. Do they need to be combined?

When everything's happy and packets are flowing as they should, there's absolutely nothing wrong with living at whatever layer of abstraction you wish.

But when something is broken, troubleshooting is a different animal. When people make assumptions based on their abstractions, they can waste a lot of time chasing a problem that can't exist, because the abstraction hides several more layers of complexity. Their mental model of the problem relies on a fantasy which they may not even realize is a fantasy.

It's unlikely for someone to accurately diagnose a fault that's several layers below where they're operating. Understanding that their abstractions are abstractions, and knowing when to hand things off to another layer of engineer, is critically important.

I mention it here because people aren't generally tracerouting things unless they suspect breakage somewhere. It's a troubleshooting tool. But people whose mental model of the network _only_ goes as low as the IP layer, are unlikely to do anything useful with traceroute unless the fault also happens to be at the IP layer.

Re: The journey of an internet packet: Exploring networks with traceroute

#52

Post by spelunker »

jerf wrote: post #37

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?

Re: The journey of an internet packet: Exploring networks with traceroute

#53

Post by sulandor »

TabTwo wrote: post #46
sulandor wrote: post #3

seems like clickbait traceroute uses udp to a high-port for discovery, not icmp-echo.

As a firewall-admin this comment really annoys me. Heres why: Lots of calls from people complaining their application is not working because the network is broken. Look! at! this! traceroute! supporting! my! complaint!!! Yeah, it is because udp from any to any is blocked on the firewall for good reasons while icmp traceroute is open. And be carefull because -I specifies the outgoint interface on some os, not the use…

most applications don't run over icmp so it is indeed sensible to not use it as a default.

Re: The journey of an internet packet: Exploring networks with traceroute

#54

Post by juancb »

myself248 wrote: post #23

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,…

And on the active networking component side of things it doesn't touch on MPLS which also doesn't modify the IP headers. You can enter a network in New York and get MPLS switched across the country via active network devices all the way to California and have it show up as a single hop on traceroute.

The explanation is great for a toy network bu in today's Internet the vast majority of routes are going to be asymmetrical and that requires running traceroutes from both ends and interpreting the results to find the faulty hop.

The author also doesn't cover equal cost multipath (ECMP) which is everywhere. With ECMP you have multiple ports that lead to the same. Next hop and packets are hashed based on some part of the fourtuple, sometimes five tuple including the input Port. In order to track down the faulty link, you need to pro each and every one of the ports which requires that you use a higher level protocol like UDP. Using icmp in this case will not show you an issue some percent of time, providing false negatives which makes it less useful.

Re: The journey of an internet packet: Exploring networks with traceroute

#55

Post by packetslave »

jerf wrote: post #37

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.

Re: The journey of an internet packet: Exploring networks with traceroute

#56

Post by icedchai »

ru552 wrote: post #25
chgs wrote: post #8

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?

Wait until DNS comes up again. I don't know how many DevOps, SRE, Senior Architects, etc. that I've worked with that just don't understand how names are resolved. There's a wide array of specialists that don't understand general fundamentals.

I also see this. Getting an MX record or TLS cert deployed is often a source of confusion, even with "seniors.'

Re: The journey of an internet packet: Exploring networks with traceroute

#57

Post by gosub100 »

chgs wrote: post #8

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 tools to set up a network actually did what I asked them to, this page would be simple. In another comment you compared it to a node.js script.

The difference between networking and programming is when you call a function it will actually do what you say, every time. In a network you can waste hours and get absolutely nowhere.

I've been in IT and software for 25 years at various levels both as a job and a hobby, and I can confidently say that networking is the biggest waste of time, most frustrating, and least rewarding aspect of working with computers. No matter what I try to set up, it never, I mean never works the way I want it to. And I've done plenty of projects to get a healthy sampling, some of them include NFS/CIFS, RDP, DHCPD+PXE, VPN, IPFW, BIND, iptables, SMTP/IMAP. Working with anything networking is absolute hell. Every single time. Guaranteed.

Re: The journey of an internet packet: Exploring networks with traceroute

#58

Post by kccqzy »

nullindividual wrote: post #28

This is a significantly better technical presentation on how traceroute works[0]; for example, unlike the illustrations in the linked article, traceroute does not necessarily take a symmetrical return path; the return path is hidden from the client -- the client only sees the forward path. [0] https://archive.nanog.org/sites/default/files/traceroute-201...

Nothing can be assumed to be take a symmetrical return path. Even if I send a normal packet to some server on the Internet, the server's reply may or may not come back using the same path. As a former Google employee, I remember vaguely that this is something Google occasionally does on purpose.

Re: The journey of an internet packet: Exploring networks with traceroute

#60

Post by archgoon »

myself248 wrote: post #51
latchkey wrote: post #31

Earlier quoted context omitted.

> In my experience, this leads to two types of network engineers, separated by their understanding of these underlying realities. What's wrong with that? Certainly, someone with a complete picture is "better", but it is effectively two different types of problems. Do they need to be combined?

When everything's happy and packets are flowing as they should, there's absolutely nothing wrong with living at whatever layer of abstraction you wish. But when something is broken, troubleshooting is a different animal. When people make assumptions based on their abstractions, they can waste a lot of time chasing a problem that can't exist, because the abstraction hides several more layers of complexity. Their menta…

Sounds like fun :)

You should write up a blog post where you had to debug some weird gnarly issues. A lot of us higher up the tech stack are pretty far removed from the signals level issues you're talking about but would love to hear about a low level debug session!

Post reply on HN