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

31–40 of 116 posts

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

#31

Post by latchkey »

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?

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

#33

Post by a-dub »

building a visualization system for traceroute in the mid 90s was how i taught myself java.

traceroute itself was wrapped by a perl rpc wrapper and then a perl www cgi script would take a list of hosts and then reach out to all of them to ask them to traceroute each other, then a java applet would render an interactive graph that you could rearrange as you saw fit.

interesting learning: internet routing can be asymmetric!

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

#34

Post by RandomThoughts3 »

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

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.

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

#35

Post by aftbit »

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?

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 run into some abstraction breaking implications only a few times in their career, while debugging a tricky bug or performance regression.

I imagine something similar is true for network engineers. Likely many can work for years at a time without worrying about fiber signal repeaters, other than that one weird packet loss issue that ends up getting traced back to a marginal optic in a cable vault somewhere.

Of course, none of this applies to the compiler engineers or the people who build the physical network layer. They are in the "second type" of engineer that actually needs to understand this stuff in depth in order to do their jobs on a day to day basis.

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

#36

Post by wang_li »

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?

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

#37

Post by jerf »

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 ms  36.370 ms  36.325 ms
     3  10.202.32.4 (10.202.32.4)  36.301 ms 10.202.32.3 (10.202.32.3)  36.301 ms 10.202.32.4 (10.202.32.4)  36.287 ms
     4  10.202.32.2 (10.202.32.2)  0.764 ms  1.279 ms  1.250 ms
     5  lo0-0.gw2.rin1.us.linode.com (45.79.12.102)  0.610 ms lo0-0.gw1.rin1.us.linode.com (45.79.12.101)  0.663 ms  0.650 ms
     6  ae62.r22.dfw01.ien.netarch.akamai.com (23.203.147.40)  0.986 ms  0.881 ms  0.837 ms
     7  72.14.204.254 (72.14.204.254)  1.164 ms 72.14.198.98 (72.14.198.98)  1.153 ms 142.250.47.248 (142.250.47.248)  2.926 ms
     8  * * *
     9  209.85.251.24 (209.85.251.24)  1.082 ms 142.251.71.114 (142.251.71.114)  1.302 ms  0.950 ms
    10  142.251.234.214 (142.251.234.214)  1.267 ms 216.239.58.16 (216.239.58.16)  3.296 ms 142.251.66.192 (142.251.66.192)  20.440 ms
    11  108.170.228.86 (108.170.228.86)  1.161 ms 108.170.228.82 (108.170.228.82)  4.548 ms 108.170.228.81 (108.170.228.81)  1.746 ms
    12  108.170.231.7 (108.170.231.7)  3.484 ms 108.170.229.87 (108.170.229.87)  3.071 ms 142.251.70.211 (142.251.70.211)  2.938 ms
    13  142.250.236.158 (142.250.236.158)  2.298 ms 216.239.51.220 (216.239.51.220)  27.388 ms 108.170.233.60 (108.170.233.60)  2.001 ms
    14  142.250.224.27 (142.250.224.27)  2.085 ms 142.250.224.25 (142.250.224.25)  1.994 ms 142.250.224.23 (142.250.224.23)  2.558 ms
    15  * * *
    16  * * *
    17  * * *
    18  * * *
    19  * * *
    20  * * *
    21  * * *
    22  * * *
    23  * * *
    24  rr-in-f91.1e100.net (142.250.114.91)  1.997 ms  1.981 ms 1.967 ms
Just an example. There's still a lot of stuff that works, but it just seems to me more and more often that when I have an actual problem I'm going to see a lot of * * *. So many things turning the requisite packets off.

(To save people excited to see if I've leaked something important some time, this comes from my Linode-hosted website's box, not my home connection.)

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

#38

Post by makestuff »

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?

Yes, I started my career in big tech and everything was so abstracted away I never really knew how it all worked as a junior. When I went to a startup and it was not longer all abstracted away I learned a ton about how it works (we were working on something cybersecurity related).

When I went back to big tech it really helped me out just knowing basic things about networking. For example, my manager joked that people should have to take an intro to DNS as part of their on-boarding to big tech.

I don't fault people for not knowing either, it was just never really a priority and the point was you shouldn't have to care. You should become an expert in your business domain and spend time solving business problems. Whether or not that was the right approach is up for debate though.

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

#40

Post by [deleted] »

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?

[deleted]
Post reply on HN