Networking Fundamentals: The Thing Everyone Skips and Shouldn't

If you ask most people where to start in DevOps or cloud engineering, you'll get answers like "learn Docker" or "get AWS certified." Almost nobody says "learn networking first," and that's a mistake — because every one of those tools sits directly on top of networking concepts, and skipping it means you're memorizing commands without understanding what they actually do.

I hit this wall myself. I could docker run things and get a VPC "working" by copy-pasting a tutorial, but the moment something broke — a container that couldn't reach another container, a service that was unreachable from outside a cluster, a security group that silently ate my traffic — I had no mental model to debug with. So I went back and actually built one, layer by layer, from a single IP address up to how Kubernetes routes traffic across a cluster. This post is that mental model, written the way I wish someone had explained it to me first.

Start With the Absolute Basics

IP Address — the identifier for a device or server on a network. Every machine that wants to send or receive data needs one, the same way every house needs an address for mail to find it.

DNS (Domain Name System) — the system that maps human-readable domain names to IP addresses. You type google.com, your machine asks a DNS server "what's the IP for this," and gets back something like 142.250.183.14. Nobody memorizes IP addresses; DNS is the reason you don't have to.

Ports — numbered channels on a server. A single machine can run many applications at once, and ports are how traffic knows which application it's meant for. A handful worth knowing cold:

If DNS gets you to the right server and the IP address gets you to the right machine, the port gets you to the right application on that machine.

Subnets, Routing, and Firewalls

Subnets let you divide one network into smaller, isolated segments — instead of every device on one flat network, you split things into groups (say, "web servers" and "databases") that can be controlled and secured separately.

The concept that trips up almost everyone learning this is subnetting math — figuring out how a subnet mask carves an IP range into smaller pieces. The trick is to get the concept solid first, using a subnet calculator to see what happens as you change the prefix length, before worrying about doing the binary math by hand. Once the concept clicks, the arithmetic underneath stops feeling arbitrary.

Routing is how traffic actually gets directed between subnets — the router looks at where a packet needs to go and forwards it along the correct path.

Firewalls sit in front of that traffic and decide what's allowed through and what isn't, based on rules you define (allow port 443, block everything else, that kind of thing). Half the "why can't my server talk to my database" bugs you'll hit in the real world come down to a firewall rule or a security group that's slightly wrong.

Private IPs, NAT, and How You Actually Reach the Internet

Private IP addresses are for communication inside a network — they're not routable on the public internet. Every home network and every cloud VPC uses private IP ranges internally.

NAT (Network Address Translation) is the mechanism that lets a device with a private IP reach the internet at all. Your router takes outbound traffic from your private IP, swaps it for a single public IP, sends it out, and translates the response back to the right internal device on the way in. This is the core job a router does — it's genuinely the key functionality that makes home and office networking work with a limited pool of public IP addresses.

Cloud Networking: VPCs, Gateways, and Route Tables

This is where networking fundamentals turn directly into cloud engineering skills, because everything above maps almost one-to-one onto how AWS, Azure, and GCP structure their networks.

• VPC (Virtual Private Cloud) — your own private, isolated network space inside a cloud provider. Everything you deploy lives inside one.
• Internet Gateway — the component that connects a public subnet to the actual internet. No internet gateway, no inbound or outbound internet traffic, full stop.
• Route Tables — the signposts that tell traffic within a subnet where to go. Every subnet is associated with a route table that decides, for each destination, which gateway or interface to send traffic through.
• Public vs. private subnets — a public subnet's route table sends internet-bound traffic to the Internet Gateway directly. A private subnet (where you'd put a database, for instance) has no such route — instead it goes through a NAT Gateway, which lets resources inside reach out to the internet (for updates, package installs) without ever being reachable from the internet.

This is the exact pattern behind "why is my database in a private subnet and my load balancer in a public one" — it's the cloud version of the private-IP-plus-NAT setup your home router has been doing the whole time, just with more explicit, auditable configuration.

Container Networking: Bridge and Overlay

Once you're working with containers, networking gets another layer.

A container bundles an application with all its code, runtime, libraries, and settings into one portable unit — the classic analogy is a food truck versus a restaurant. The restaurant depends entirely on its building; the food truck brings everything it needs and can run anywhere.

Bridge networks are Docker's default: a private network that exists only on a single host. Every container attached to the same bridge network can reach every other container on it using just the container name as a hostname — Docker handles the internal DNS resolution for you.

Overlay networks solve the problem bridge networks can't: containers that need to talk to each other across multiple hosts. Docker creates a virtual network layered on top of the underlying host networks so containers on different physical or virtual machines can still communicate as if they were on the same local network.

Kubernetes Networking: Pods, Services, and Ingress

Kubernetes automates container management at scale, and it introduces its own networking model on top of everything above.

• Pods are one or more containers running together as a unit — each Pod gets its own IP address. But Pods are disposable: when one dies and gets replaced, the replacement gets a new IP. This is the single biggest networking gotcha for anyone new to Kubernetes — you cannot rely on a Pod's IP staying stable.
• Services solve exactly that problem: a Service gives you a stable IP address and DNS name that never changes, no matter how many times the Pods behind it are created and destroyed. Your application talks to the Service, not to individual Pods.
• Ingress handles incoming traffic to the cluster from the outside world and routes it to the correct Service based on rules like hostname or URL path — it's effectively the front door and traffic cop for everything running inside.

Multiple Services can run inside a single cluster simultaneously, each fronting a different group of Pods, with Ingress deciding which requests go where.

Underneath It All: The Physical/Virtual Layer

• Network Interface — the physical or virtual connection between a server and the network. eth0 is the classic name for the main interface handling inbound and outbound internet traffic on a Linux server.
• The OS manages which incoming requests get routed to which port, and from there to which application.
• Virtualization lets you run multiple VMs on a single physical server. Unlike a bare-metal server, a VM is portable — you can capture its entire state as a snapshot file and move or restore it elsewhere.
• The Hypervisor sits between the physical server and the VMs running on it, allocating resources and routing network traffic between them.

Put together, this is the full stack: physical network interface → hypervisor and VMs → container runtime and its bridge/overlay networks → Kubernetes Pods, Services, and Ingress → your application. Microservices architecture — building an application as a collection of small, independent services — is what makes all of these networking layers matter in the first place, since those services have to find and talk to each other constantly across every layer above.

How to Actually Learn This (Not Just Read About It)

Reading a description of the TCP three-way handshake teaches you almost nothing compared to watching one happen. The way this stuff actually sticks is by observing it directly, not memorizing definitions:

• Open Wireshark and leave it open. Every concept you read about, go capture it. Learn about DNS, filter for DNS traffic, and watch your own machine send a query and get a response every time you type a domain name. Learn about the TCP handshake, filter for TCP, and watch the SYN → SYN-ACK → ACK sequence happen in real time.
• Build a small home lab with a few VMs. Route traffic through a pfSense firewall VM and write rules that actually do what you intend — then deliberately try to craft traffic that slips past a badly written rule, so you understand firsthand why firewall configuration is harder than it looks.
• Run Nmap against your own lab with different scan types, with Wireshark open at the same time, so you see the tool's output and the raw packets it generated side by side.
• Cisco Packet Tracer (free with a Cisco Networking Academy account) lets you drag routers and switches onto a canvas, wire them up, configure them through a simulated CLI, and watch traffic actually flow — without needing physical hardware.
• Once the fundamentals are solid, look up ARP spoofing to see why this all matters for security too: ARP has no authentication built in, which means on a local network you can broadcast fake ARP responses claiming to be the gateway and quietly route everyone else's traffic through your own machine. It's a genuinely eye-opening example of how a 1980s design decision that prioritized simplicity over security still shapes real attacks today.

Free Resources Worth Bookmarking

The Actual Point

None of this is exciting the way "learn Kubernetes" or "get AWS certified" sounds exciting. It's the unglamorous layer underneath both of those things — and it's exactly why skipping it produces engineers who can follow a tutorial but can't debug a real outage. Sit with it until the abstract stuff stops feeling abstract. That discomfort is there for a reason: it's exactly when the understanding actually forms, and everything you learn after it — Docker, Kubernetes, Terraform, cloud architecture — will make noticeably more sense once it has this to stand on.