Do you have a dumb question that you're kind of embarrassed to ask in the main thread? Is there something you're just not sure about?
This is your opportunity to ask questions. No question too simple or too silly.
Culture war topics are accepted, and proposals for a better intro post are appreciated.
Jump in the discussion.
No email address required.
Notes -
What's a good book about TCP/IP networking? I am currently redoing my home network setup and I've realized my knowledge of networking is very fragmented. I know the right incantations, but I have no idea what they actually do.
Questions like this are pretty much in the wheelhouse of things like ChatGPT. It's really good at answering these high-level questions and providing good direction with the ability to dive deeper into each of the topics.
I asked on your behalf and everything looks pretty much like I would've written. https://chatgpt.com/share/677bd93a-310c-8004-9dcc-9b36c30fde8c
My take:
For home networking, unless you're setting up a homelab, you can probably ignore VLANs. Honestly, most of these are pretty much ignorable for what I'm expecting your use case of home network are concerned.
Anything vaguely modern in terms of a home router should handle all of these pretty transparently. Without getting into packet-level stuff, DHCP from the router will configure the clients and configure the default gateway to itself as well as prevent duplicate IPs (unless you're configuring them manually). DHCP itself tends to just work out of the box. UDP NATing, similarly, tends to just work. VLANs, at what I'm expecting is your scale, should likely just be ignored.
In my case, I have a small server rack that has a couple of NASes living in it along with a few switches (1GbE and 10GbE). The switches support VLANs, but even for what I'm doing, I'm far from needing any of the functionality it would provide. The router I'm using are a set of Eeros -- they can provide a mesh network, but for me all of them are hardwired to the switch.
If you're looking to experiment from a homelab perspective, that's another story. But it could be a really fun story. A common way of getting started there to get a solid grounding on the fundamentals is doing something like setting up a Raspberry Pi cluster and playing with those. It's a cheap and approachable way to learn these concepts.
I can already set up my home network (which is currently an x86 router, a custom-built NAS, a router working as a wireless AP and another router working as a wireless extender plus all the end-user devices), I want to understand why I am doing the things I am doing. I am sorry, but your ChatGPT log didn't exactly help with that. I'll see if asking it for a more textbook explanation from the ground up will work.
Much of this is really building on many decades worth of tech and it's hard to understand the why until you understand much of the whole stack.
Here's some of the whys, from my perspective in the order I would talk about them:
DHCP: when a device joins a network, it can broadcast on the network and ask for how it should configure it's network stack. Implicit in the request is the MAC (Media Access Control) address of the interface itself which provides the physical address of the interface. The DHCP server (in a home setting, usually in the router) assigns an IP from a block it manages and gives the rest of the networking details (gateway, subnet, etc) to the client. DHCP isn't strictly needed as the clients can be configured manually in many cases. Cheap IoT devices tend to rely on it.
Default Gateway: When you're sending any packet to something outside your local network, you send the packet to the gateway and it figures out how to get the packet to the destination. In a home setting, this will just be forwarding the packet upstream to your ISP. In a larger scale setting, it's going to consult things like BGP routing to figure out where to send things to. The beauty of IP is that the client doesn't need to worry about it and it's completely abstracted into the gateway itself.
Duplicate IPs: As mentioned before, every interface has a MAC address. When you're sending a packet on the network to another machine (i.e. not broadcast), you send the packet to the MAC address. But we're dealing with IP, not MACs. To translate from an IP address to a MAC address we send out a broadcast ARP (Address Resolution Protocol) request asking basically "will the device with IP xxx respond?" Broadcasts are received by all the machines on the network. The machine with the requested IP will respond. If there are multiple machines that are configured with the same IP, they'll all respond. What happens here is usually the first one wins. This is complicated by modern switches because they learn what IPs/MACs are on each of their ports. They'll likely assume there are two routes to the same host and weird things may happen. Lesson: don't do it, things break.
VLANs: From a switch perspective, it just controls what ports can talk to which other ports. If you have an 24-port switch, you can configure multiple VLANs such that, say, ports 1-12 can talk to each other, and 13-24 can talk to each other. It's setting up two "Virtual LANs." You can have a router that attaches to both of the VLANs to handle routing between them if you want. These are typically used to prioritize certain network traffic, or for security (e.g. a guest network can't talk to your servers).
UDP and NAT: Since there's no connection in UDP, the NAT device just remembers things like "when device XX using port YY sends a packet to internet address AA port BB, I sent the packet on my port PP. Later, if I get a packet from AA:BB on port PP, I'll look that up and forward the packet to XX:YY." The key here is that all IP packets have the source IP and port and destination IP and port. When it's doing NATing, it replaces the local IP (which isn't going to be publically routable) with it's own address and port. On the way back, it just does the reverse and replaces the destination IP/port (which is how the packet got to it in the first place) with the local network's addresses and ports and forwards.
Thanks, that was helpful!
How does it broadcast its request if it doesn't have an IP address?
The local network is defined by the network mask, right? So with 255.255.255.0 if I send something from 192.168.1.2 192.168.1.3 there's no need for the gateway to be set up, but 192.168.2.3 is outside the network and the packets will be routed to the gateway?
This makes me wonder how the packets are routed within the local network, actually. Let's say I'm sending a request from my PC (192.168.1.5) to my NAS (192.168.1.2). The PC is connected to my wireless switch/AP (192.168.1.4), and both the switch/AP and the NAS are connected to the wired router (192.168.1.1). How does the switch/AP know it should send the request to the wired router and not to one of its other LAN ports?
There are two kinds of network switches/hubs (well, there are more, but at least two). The dumb one just essentially pretend everybody is on the same bus, and so every port gets all the traffic from other ports. This of course is only good for very simple small networks. Smarter switch would remember which IPs and MAC addresses live on which ports and forward the packets accordingly. Of course, smarter switches are more expensive than the dumb ones. For bigger networks you'd have configuration capacity in the switch to tell it which networks live on which ports.
I don't think you'll see a true 'dumb switch' (technical term 'hub') in ethernet from a major store; I haven't seen a new one since back when 10/100mbps switches were just phasing in. But they definitely existed, and it wasn't uncommon for one person to be able to bog down an entire intranet.
In the modern day, the distinction between 'dumb' and 'smart' switches is usually going to emphasize 'smart' switches as having optional routing functionality, (aka 'layer 3 switching'). This technically means that the layer 3 switch has one or more ports that can be configured into a router mode, though in practice it'll be missing a lot of other functionality you'd expect from a small home or office router (almost always missing NAT/PAT, usually not having DHCP or DNS).
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link