The journey of an internet packet: Exploring networks with traceroute • Hacker News Board

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

#41

Post by latchkey » Wed, Aug 28, 2024, 3:05 PM UTC

aftbit wrote: post #35

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?

I think you're reading the connotation into this. In my opinion, there is nothing wrong with being a higher level engineer. There's plenty of work "above the fold" so to speak. For example, I think it behooves every software engineer to have a general grasp of how CPUs work, what speculative execution is, how CPU caching and invalidation works, etc, but the average webdev doesn't really need to know this, and might r…

> I think you're reading the connotation into this.

I am reading the connotation into this and asking about it. 4 paragraphs of talking only about tech and then it diverged into a personal statement at the end.

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

#42

Post by FujiApple » Wed, Aug 28, 2024, 3:17 PM UTC

wang_li wrote: post #36

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...

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...

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

#43

Post by nullindividual » Wed, Aug 28, 2024, 3:19 PM UTC

wang_li wrote: post #36

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...

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

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

#44

Post by Hikikomori » Wed, Aug 28, 2024, 3:25 PM UTC

bc569a80a344f9c wrote: post #20

sulandor wrote: post #3

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

I agree that this doesn’t seem to have been written by someone that actually understands the topic. Even the network diagram at the beginning is not very good. Can you create network architectures where 10.0.0.1 and 10.0.0.2 are not layer 2 adjacent? Yes, but they’re fairly complex and would imply that a lot of other necessary information is missing from the diagram. And should you use such an architecture as an exam…

/31 linknets are common in the ISP world, it might even be /32 loopback of those devices, who knows.

I do agree that its bad but not for the same reason. On the diagram it looks like router IPs are their loopback IPs rather than the link IP, as we know a traceroute response comes from the interface the packet came in and that IP is used in the response. Seems like the creator tried to simplify the diagram and excluded linknets but made it more confusing instead.

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

#45

Post by Hikikomori » Wed, Aug 28, 2024, 3:26 PM UTC

mannyv wrote: post #22

dec0dedab0de wrote: post #19

Earlier quoted context omitted.

nothing from that machine, but the way the ttls work, it doesn’t affect the responses from routers along the way. Same if the destination doesn’t exist at all.

Totally untrue. Network admins will often disable traceroute responses because security. Edit: the less someone knows about your internal topology the better. Security through obscurity does work.

Windows disables ping by default for what I'm guessing is security.

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

#46

Post by TabTwo » Wed, Aug 28, 2024, 3:32 PM UTC

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 of ICMP.

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

#47

Post by FuriouslyAdrift » Wed, Aug 28, 2024, 3:34 PM UTC

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

A lot of ISP internal networks is going to be running over MPLS or encapsulation. You're not going to see any of those hops. The packet will just look like it teleported from the CPE to the Internet.

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

#48

Post by Hikikomori » Wed, Aug 28, 2024, 3:36 PM UTC

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

Not sure why this matters for anyone not working for the ISP that those packets go through, and people working there would know about it. And they're mostly completely passive devices like filters.

Traceroute is what we have, and its mostly enough as you can say at which hop things went wrong, then its up the ISP to figure out what devices they need to look at.

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

#49

Post by spelunker » Wed, Aug 28, 2024, 3:43 PM UTC

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?

Absolutely. I'm a software dev and have been doing this for many years, but never had to think about the network much. I recently went down a BGP/AS rabbit hole and found it _fascinating_, and that's just the tip of the iceberg - go up or down the OSI stack and there's all kinds of stuff I didn't know about!

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

#50

Post by yusyusyus » Wed, Aug 28, 2024, 3:45 PM UTC

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

as a predominantly wave-purchaser than builder, it matters when it matters and it doesn’t when it doesn’t.

we get by fairly well assuming l1 is working as designed when the light is on and not throwing errors.. at least on day-to-day ops. planning/sourcing is a bit of a different thing.

one note to your point though, back when people were still regularly picking up OC3s or doing frame relay or whatever, it was certainly more day-to-day to understand these things, but cant really fault anyone since most of that junk has gone away and we’re left with the happy ethernet handoff. especially in small scale DC/enterprise. cloud, too, made us care less.