91–100 of 116 posts
Earlier quoted context omitted.
I'm often tasked with explaining technical concepts to people with entry-level knowledge so simple, clear documents like this are very helpful resources.
Would a “a for loop in node js” or “serving an webpage in Python” get so much attention?
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…
Wackiest network I've seen in a while, and I've seen some real winners.
seems like clickbait traceroute uses udp to a high-port for discovery, not icmp-echo.
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.
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 hobb…
The hardest part of configuring the services you list is not the networking, but all the non-networking topics you need to be familiar with: zone file syntax; cipher suite selection; OS-specific security policy and permissions models; PKI administration; PXE ROM peculiarities, etc.
Once you're confident with arp, addressing/subnetting, routing tables, and a few other tools like netstat and `dig` you can quickly eliminate the network as the cause of the issue and focus on grokking the application itself.
Earlier quoted context omitted.
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.
So it hits the Internet once between Akamai and Google I guess?
For it to be hitting "the Internet" you'd expect to see hops on a Tier 1 carrier like AT&T, Lumen, etc. and/or an ISP like Comcast, Spectrum, etc.
Earlier quoted context omitted.
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 hobb…
> NFS/CIFS, RDP, DHCPD+PXE, VPN, IPFW, BIND, iptables, SMTP/IMAP The hardest part of configuring the services you list is not the networking, but all the non-networking topics you need to be familiar with: zone file syntax; cipher suite selection; OS-specific security policy and permissions models; PKI administration; PXE ROM peculiarities, etc. Once you're confident with arp, addressing/subnetting, routing tables, a…
Earlier quoted context omitted.
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
I don't know if it's missing in people's course work or what, but I've had to use http://www.tcpipguide.com/free/diagrams/ipencap.png many a times to explain how stuff like VPNs work, correct statements like "firewalls don't have a routing table, firewalling is layer 4", explain things like MTU and payload size, or why certain traffic doesn't go beyond a broadcast segment normally.
Personally I think this is one of the better visualizations.
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,…
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 traceroute’s defense, it is trace route — for sure it doesn’t tell you anything about the devices that don’t operate at the IP level. Those devices either don’t affect the IP “route” abstraction (e.g., signal boosters) or do so in ways that end up plausibly visible in the next hop. There’s a reason the network layer abstraction is so strong, and an analogy to CPU ISAs here that have a similar strength. TCP, simila…
"Is the digital loop carrier doing any IP-level routing?"
"No, but..."
