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

71–80 of 116 posts

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

#71

Post by johannes1234321 »

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

Below the IP layer there is always the physical layer somewhere with all the complications.

Traceroute also doesn't show VPNs or other transports.

But it shows the TCP hops and the timing, thus gives me the tools to see who to call or which routing table or wore to analyse or fix. When doing that I got to lok at that connection.

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

#72

Post by spelunker »

mccoyc wrote: post #63
spelunker wrote: post #52

Earlier quoted context omitted.

traceroute noob - what do the * * * mean? A host is choosing not to participate and dropping data or something?

Traceroute works by observing Internet Control Message Protocol (ICMP) time to live/hop count exceeded messages and noting the source IP of those messages. There's plenty of resources you can search on to learn more about this. When you see * * *, it means that for that given TTL value, no corresponding ICMP messages were returned to the source. It could be because they were filtered at the boundary of the network. I…

Great info, ty!

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

#73

Post by latchkey »

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…

Thanks for the clarity in your response. I think we are pretty well aligned.

It is human stacking of the OSI model. The person in the ditch repairing the line probably doesn't care about traceroute, but the person with traceroute probably should care about what happens in the ditch.

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

#74

Post by mcmcmc »

Hikikomori wrote: post #48
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.

It definitely helps to understand it when you are trying to explain to the ISP that it’s their problem. Knowing what you’re talking about will get your issue resolved much more quickly.

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

#75

Post by treve »

RandomThoughts3 wrote: post #34
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.

The OSI model hasn't been accurate representation of ip networking since pretty much day 1. It was made specifically for a different protocol, but in the stack we use today some layers are better split up in 2, some protocols exists in multiple layers. It's a nice metaphor but I think it's time to drop it!

https://computer.rip/2021-03-27-the-actual-osi-model.html

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

#77

Post by groby_b »

mcmcmc wrote: post #74
Hikikomori wrote: post #48

Earlier quoted context omitted.

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.

It definitely helps to understand it when you are trying to explain to the ISP that it’s their problem. Knowing what you’re talking about will get your issue resolved much more quickly.

That depends who's doing the talking. You're a large business with a dedicated connection and your own network engineering team? Yeah, totally matters.

You're a single consumer, or a small business? Your dialog is limited to "Yes, I switched the router on and off. Yes, my local network works. No, I can reach the website over my phone, this is your problem".

Repeat three times, then get the inevitable reply of "it'll be up again in the next 24 hours".

Unless you're a network engineer, this really doesn't matter.

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

#79

Post by lostemptations5 »

nullindividual wrote: post #66
wang_li wrote: post #62

Earlier quoted context omitted.

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.

You'll learn pedantry gets tiring when you get older. How traceroute is understood and displayed to the end user constitutes a route. If you have an issue with how the developers of traceroute framed it, that's on you.

OP was the pedant in this case, unfortunately (for you).
Post reply on HN