Networking Fundamentals for DevOps Engineers

Most of the outages you will chase as a DevOps engineer are not application bugs. They are networking problems wearing an application’s clothes: a service that “won’t start” because it can’t reach its database, a deploy that “broke the API” because DNS is returning a stale address, a health check that flaps because a firewall silently drops half the packets. The application logs blame the network; the network team blames the application; and the person who can actually read the network wins the argument and fixes the incident.

This lesson builds the mental model for the rest of the series. We are going to define every core networking term from scratch — no assumed knowledge beyond the Linux command line — and then tie them all together with one question that turns out to be the through-line for the entire course: what actually happens when you run curl https://example.com? Once you can answer that in six clear steps, you have a map. Every troubleshooting tool in later lessons just inspects one point on that map.

What You Will Learn

• The core vocabulary: hosts, interfaces, MAC and IP addresses, subnets, CIDR, gateways, routing, DNS, ports, and protocols.
• What TCP and UDP are, and why the difference matters operationally.
• The client/server model that underpins nearly every service you run.
• A conceptual, end-to-end walkthrough of a single curl request.
• A simplified troubleshooting stack you can apply to any connectivity failure to find the broken layer first.
• A practical 5-layer view of the OSI model built for diagnosis, not exams.

What Is a Network?

A network is simply two or more computers that can exchange data. The individual machines are called hosts — your laptop, a cloud VM, a container, a database server, a router. Anything with a network address that can send or receive traffic is a host.

Hosts talk to each other through interfaces. An interface is the connection point between a host and a network — usually a network card, physical or virtual. Run ip link and you will see them: lo (the loopback interface a host uses to talk to itself), eth0 or ens3 (a wired or cloud NIC), docker0 or veth* (virtual interfaces Docker creates). A single host can have many interfaces, each on a different network — which is why a container that reaches one network but not another is an interface-and-routing story, not an application one.

Every interface has a MAC address (Media Access Control address) — a hardware identifier like 02:42:ac:11:00:02. MAC addresses only have meaning on the local network segment (the hosts that can talk directly without a router between them); they are how frames reach the right NIC on your local link. You rarely configure them, but you will meet them again with ARP and the data-link layer later in the series.

IP Addresses, Subnets, and CIDR

A MAC address gets a frame across the local wire, but it does not scale — you cannot route by hardware address across the internet. That job belongs to the IP address (Internet Protocol address). An IP address is a logical, routable identifier for an interface, like 192.168.1.42 (IPv4) or 2001:db8::1 (IPv6). When people say “the server’s address,” they mean its IP.

IP addresses are grouped into subnets — ranges of addresses that share a network and can reach each other directly. The subnet boundary is defined by a netmask, and the modern shorthand for writing it is CIDR (Classless Inter-Domain Routing) notation: an address, a slash, and a number.

192.168.1.42/24
        │      │
    address    prefix length (network bits)

The /24 means “the first 24 bits identify the network, the last 8 identify the host.” So 192.168.1.0/24 is a subnet containing 192.168.1.1 through 192.168.1.254 (with .0 as the network address and .255 as broadcast). A /16 is a bigger network; a /32 is a single host. You will read CIDR constantly: security group rules, Kubernetes pod CIDRs, VPC ranges, firewall allow-lists. If two hosts are in the same subnet, they talk directly. If they are not, traffic has to leave the subnet — and that is where gateways come in. We work through addressing and prefix math with real examples in the IP addresses, subnets, and CIDR lesson.

🛠️ DevOps Perspective — When you allow 10.0.0.0/8 in a security group or set a pod network CIDR in a cluster, you are speaking exactly this language. Misreading a prefix length (/24 vs /16) is a classic cause of “why can this host reach that one but not this other one?”

Gateways and Routing

A default gateway is the host on your local subnet — typically your router — that forwards traffic bound for other networks. When your machine wants an address that is not in any local subnet, it hands the packet to the gateway to move it closer to the destination.

The rules deciding where each packet goes live in the routing table. Every host has one. For any destination IP the host asks: is this address local (send directly), or does it need a gateway (send to the router)? The most specific matching route wins; if nothing else matches, the default route (0.0.0.0/0) sends the packet to the default gateway.

Routing is just this decision, repeated hop by hop across the internet, until the packet reaches the destination host. We will read and reason about the routing table directly in the Linux routing lesson.

Ports and Protocols

An IP address gets traffic to the right host. A port gets it to the right program on that host. A port is a 16-bit number (0–65535) that identifies a specific service or connection endpoint. Port 443 is conventionally HTTPS, 22 is SSH, 5432 is PostgreSQL, 53 is DNS. When a server “listens on a port,” it has claimed that number and is waiting for connections. The combination of an IP address and a port — 192.168.1.42:443 — is a socket, the full address of one endpoint of a conversation.

A protocol is the agreed-upon set of rules for a conversation — the grammar both sides follow. HTTP is a protocol for the web. DNS is a protocol for name lookups. SSH is a protocol for encrypted shells. These are all application protocols, and underneath them sit the two transport protocols you must know: TCP and UDP.

TCP

TCP (Transmission Control Protocol) is the reliable, connection-oriented transport. Before any data flows, the two sides establish a connection with a three-way handshake, and every byte is acknowledged, ordered, and retransmitted if lost. If a packet drops, TCP resends it; the application sees a clean, in-order stream. HTTP, HTTPS, SSH, and most database protocols run on TCP because they cannot tolerate missing or scrambled data.

UDP

UDP (User Datagram Protocol) is the lightweight, connectionless alternative. There is no handshake and no built-in retransmission — you send a datagram and hope it arrives. That sounds worse, but for some workloads it is exactly right: DNS lookups, VoIP, video streaming, and metrics where speed matters more than guaranteed delivery. We contrast the two in detail, with ss output, in the TCP vs UDP lesson.

🏭 Why This Matters in Production — “Connection refused” and “connection timed out” mean very different things, and the difference is a TCP concept. Refused means a host answered and rejected the port (nothing listening, or a firewall REJECT). Timed out means nothing answered at all (a firewall DROP, wrong route, or a host that is down). Same symptom in a dashboard; completely different root cause.

The Client/Server Model

Nearly every service you operate follows the client/server model. A server is a program that listens on a port and waits. A client is a program that initiates a connection to that port and makes a request. The server does not reach out to clients; it responds. Your browser is a client to a web server; curl is a client; kubectl is a client to the Kubernetes API server; your app is a client to its database.

   CLIENT                          SERVER
 (curl / app)                  (nginx / API)
      │                              │
      │  ── connect to IP:443 ──▶    │   listening
      │      TCP / IP                │   on port 443
      │  ◀────── response ───────    │
      │                              │
   initiates                     responds

Keep this picture in mind: when connectivity breaks, you are always asking whether the client’s request reached a listening server, and if not, where along the path it stopped. That path is what curl traverses — so let’s trace it.

What Actually Happens When You Run curl?

This is the section to remember. Type this on any Kali box:

curl https://example.com

It looks like one action. It is actually six distinct stages, each of which can fail independently and each of which a later lesson teaches you to inspect. Walk through them conceptually:

1. DNS resolution. example.com is a name, not an address, and the network can only route to addresses. So curl first asks a resolver to translate the name into an IP. If this step fails, you get Could not resolve host — a pure DNS problem, and nothing else has even been attempted yet. This is the DNS troubleshooting lesson.

2. Route selection. Now curl has an IP, say 93.184.216.34. The kernel consults the routing table: is this address on a local subnet, or does it need the default gateway? It picks an outgoing interface and a next hop. If there is no matching route, you get No route to host or Network unreachable.

3. TCP connection (the three-way handshake). With a route chosen, the kernel opens a TCP connection to port 443 on the server. This is the handshake:

  CLIENT                         SERVER
    │  ─────────  SYN  ────────▶  │   "can we talk?"
    │  ◀───────  SYN-ACK  ──────  │   "yes, can you?"
    │  ─────────  ACK  ────────▶  │   "confirmed"
    │        connection established

If the port is closed or rejected, this is where Connection refused appears. If packets vanish into a firewall, this is where it hangs and eventually times out.

4. TLS negotiation. Because we asked for https://, once the TCP connection is up, curl and the server perform a TLS handshake: they agree on a cipher, the server presents its certificate, curl verifies that certificate against trusted authorities and checks the hostname matches. An expired or mismatched certificate fails here — after a perfectly healthy TCP connection — which is why cert errors are so often misdiagnosed as “the server is down.”

5. HTTP request. Only now does the actual application conversation begin. curl sends an HTTP request over the encrypted channel: GET / HTTP/1.1, a Host: example.com header, and so on.

6. HTTP response. The server replies with a status line (HTTP/1.1 200 OK), headers, and the response body, which curl prints. A 200 means the whole stack worked. A 502 or 503 means every network layer succeeded and the application is the problem — a genuinely useful thing to know, because it points your investigation somewhere completely different.

🔎 Troubleshooting Tip — Every failure of curl maps to exactly one of these six stages. The skill is not memorizing fixes; it is identifying which stage broke from the error message, then reaching for the one tool that inspects that stage. Could not resolve host → DNS. Connection refused → port/listener. SSL certificate problem → TLS. 502 Bad Gateway → application. The rest of this series is one lesson per stage.

The Troubleshooting Stack

Read that curl walkthrough bottom-up and you get a diagnostic ladder. When something can’t connect, you check the layers in order and find the lowest broken one first — because a break low down makes everything above it look broken too.

  Application   ← HTTP 5xx, app logic, timeouts
      ▲
     TLS        ← cert expired / hostname mismatch
      ▲
     Port       ← is anything listening? refused?
      ▲
     DNS        ← does the name resolve at all?
      ▲
    Gateway     ← can we reach the default route?
      ▲
     Route      ← is there a route to the target?
      ▲
   Interface    ← is the NIC up with an address?

The single most common mistake juniors make is debugging top-down: staring at application logs while the real problem is three layers below. If DNS is broken, the app cannot work — checking its config is wasted time. So the discipline is: find the broken layer first, then fix it. Start low (is the interface up? is there a route?) and climb until something fails. That failing layer is your incident.

🛠️ DevOps Perspective — This ladder is why “have you tried restarting it?” is such a weak first move. Restarting rerolls the dice; it does not tell you which layer failed. A restart that happens to fix a DNS cache issue teaches you nothing and will not save you when it recurs at 3 a.m. Diagnosis — Observe, Hypothesize, Test, Identify the layer, Correct, Validate — is repeatable. Guessing is not.

A Practical 5-Layer View of OSI

You may have seen the seven-layer OSI model. For day-to-day DevOps troubleshooting, a simplified five-layer view maps more cleanly onto the tools you actually run:

Layer	Name	What lives here	Typical tools
L7	Application	HTTP, DNS, SSH, TLS	curl, dig, ssh
L4	Transport	TCP, UDP, ports	ss, nc, nmap
L3	Network	IP addresses, routing	ip addr, ip route, ping
L2	Data Link	MAC addresses, ARP, VLAN	ip neigh, ip link
L1	Physical	NIC, cable, Wi-Fi	ip link, driver logs

This is not a replacement for the formal model — it is a working shorthand. When someone says “it’s a layer 3 problem,” they mean routing or addressing. “Layer 7” means the application protocol itself. Being able to place a symptom on this table, and name the tool that inspects that layer, is most of what fast network troubleshooting is.

Try It Yourself

🧪 Try It — On any Kali machine (or any Linux host), run the pieces of the curl story yourself and watch each stage in isolation:

ip -brief addr        # interfaces + their IP addresses (L1/L3)
ip route              # your routing table + default gateway (L3)
dig +short example.com  # DNS resolution only (L7 name → IP)
curl -v https://example.com   # the whole stack, verbosely

The -v (verbose) flag on curl is the payoff. Read its output top to bottom and you will see the exact six stages narrated live: the resolved IP, Trying 93.184.216.34:443..., Connected, the TLS handshake lines (SSL connection using..., certificate details), then the > GET / request and < HTTP/1.1 200 OK response. That verbose output is the troubleshooting stack, printed for you. Learn to read it and you have a diagnostic superpower.

Common Problems

• Could not resolve host — DNS failed. The name never became an IP, so nothing after step 1 ran. Check your resolver config and try dig.
• Connection refused — you reached the host, but the TCP port rejected you. Nothing is listening, it’s on a different port, or a local firewall is issuing a REJECT.
• Connection timed out — packets are disappearing silently. A firewall DROP, a wrong route, a down host, or a cloud security group / network policy blocking the path.
• No route to host / Network unreachable — routing failed. There is no route to the destination, or the gateway is unreachable.
• SSL certificate problem — TCP connected fine; TLS verification failed. Expired cert, wrong hostname, or an untrusted issuer. The network is healthy — the certificate is not.
• 502 / 503 — every network layer worked; the application (or its upstream) is failing. Stop looking at the network and read the app logs.

Troubleshooting Workflow

Observe   → what's the exact error / symptom?
Hypothesize → which layer does that error point to?
Test      → run the one tool for that layer
Evidence  → what does the output actually say?
Identify  → confirm the broken layer
Correct   → fix that layer only
Validate  → re-run curl; confirm 200 end-to-end

Apply this to every connectivity incident in the series. The error message chooses the layer; the layer chooses the tool; the tool gives you evidence, not a guess.

What You Learned

• A network connects hosts, which attach to it through interfaces identified locally by MAC addresses.
• IP addresses are routable host identifiers; subnets and CIDR notation define which addresses can talk directly.
• The default gateway and the routing table decide how packets leave the local subnet; routing repeats that decision hop by hop.
• DNS turns names into IPs; ports identify programs; protocols define the conversation.
• TCP is reliable and connection-oriented (with a three-way handshake); UDP is fast and connectionless.
• The client/server model underpins every service: clients initiate, servers listen and respond.
• Running curl https://example.com is really six stages — DNS → route → TCP → TLS → HTTP request → HTTP response — and every failure maps to exactly one of them.
• The troubleshooting stack (Application → TLS → Port → DNS → Gateway → Route → Interface) tells you to find the lowest broken layer first, and the 5-layer OSI view names the tool for each layer.

You now have the map. Next, we start walking it from the bottom: in Part 2, Network Interfaces with iproute2, you’ll use the ip command to read interfaces and addresses on a real host — the L1/L3 foundation everything above depends on. You can also return to the Kali Linux hub to see the full learning path.