Networking for Beginners: How DevOps Engineers Think About the Network

Networking is the part of DevOps that quietly underlies everything else. A container that "can't connect to the database" is usually a networking problem wearing a different costume. This guide covers the fundamentals you'll actually lean on when troubleshooting.

IP addresses and subnets

Every device on a network needs an address to be reachable, an IP address (like 192.168.1.10). A subnet mask determines which part of that address identifies the network, and which part identifies the specific device on it. Addresses on the same subnet can talk to each other directly; anything outside it has to go through a router.

ip addr show          # view this machine's network interfaces and addresses

DNS: turning names into addresses

Nobody wants to type an IP address to visit a website. DNS (Domain Name System) is the system that translates a name like opsquiz.org into the actual IP address browsers and apps need to connect to.

dig opsquiz.org           # query DNS directly and see the full response
nslookup opsquiz.org      # a simpler, older alternative to dig

If a service works fine when you connect by IP but fails by domain name, that's a strong signal the problem is specifically in DNS resolution, not general connectivity.

Ports: one address, many services

An IP address gets you to a machine; a port number gets you to the right service running on it. A web server typically listens on port 80 (HTTP) or 443 (HTTPS), SSH on 22, and so on. Two different applications on the same machine simply listen on two different ports.

ss -tuln                          # list all listening TCP/UDP ports on this machine
nc -zv localhost 8080             # check whether something is listening on port 8080

TCP vs UDP, briefly

Most application traffic (HTTP, databases, SSH) runs over TCP, which guarantees delivery and correct ordering, at the cost of a bit of overhead to set up the connection. UDP skips that guarantee entirely: it's faster and simpler, used where occasional lost data is acceptable (video streaming, DNS lookups themselves, some monitoring protocols).

Firewalls: the gatekeepers

A firewall decides which traffic is allowed in or out, based on rules matching things like source IP, destination port, or protocol. In the cloud, this often takes the form of security groups (AWS) or similar constructs, rather than a traditional standalone firewall appliance. A service that works when accessed from inside a network but times out from outside it is a classic firewall-rule symptom.

Load balancers

A load balancer sits in front of multiple servers and spreads incoming traffic across them, so no single server gets overwhelmed and a failed server can be quietly removed from rotation. This is also why "it works when I hit the server directly, but not through the load balancer" is a meaningful, specific clue: the load balancer itself, or its health checks, are worth investigating separately from the app.

Your troubleshooting toolkit

ping 8.8.8.8              # is the destination reachable at all?
traceroute opsquiz.org    # which hops does traffic pass through to get there?
curl -v https://opsquiz.org  # make an actual HTTP request and see the full exchange

ping and traceroute test basic reachability; curl actually speaks the application-level protocol, which is why it's often the better first tool when an app-level request is failing but the network itself seems fine.

Where to go next

These fundamentals become directly relevant the moment you start working with Docker's container networking or Kubernetes Services, both of which are really just structured ways of solving these same routing and discovery problems. Try the Networking quiz on OpsQuiz to test what you've just learned, then check out our Kubernetes fundamentals guide next.