Part 11 — Networking on Linux

Everything until now happened on one machine. This part is how that machine talks to others — the networking stack from a single Linux box's point of view. It complements rather than repeats this Wiki's dedicated TCP/IP guide; the focus here is what you configure and inspect on the host itself.

Chapter 37 — How a Linux box sees the network

In one sentence

A Linux machine's view of "the network" is built from a handful of concrete kernel concepts — network interfaces, IP addresses, routes, and DNS resolution — and every one of them can be inspected directly, which is exactly how you'll debug connectivity problems for the rest of your career.

Why this matters

"I can't reach the server" has a specific, findable cause every time — DNS, routing, a closed port, a firewall rule — and knowing this layer means you check the right thing first instead of guessing.

How it actually works

   ip addr show                # every network INTERFACE and its
                               # assigned IP address(es)
   ip route show                 # the ROUTING TABLE -- where does
                               # traffic to a given destination
                               # actually go?
   cat /etc/resolv.conf           # which DNS server(s) this box asks

   THE CONCEPTS, briefly:
     INTERFACE     a network endpoint the kernel manages -- a physical
                  NIC (`eth0`, `enp0s3`), or a VIRTUAL one (the loopback
                  `lo`, a VPN tunnel, a virtual bridge -- Phase 3's
                  container networking is built entirely on virtual
                  interfaces).
     IP ADDRESS     a numeric address assigned to an interface -- how
                  packets know where to go.
     ROUTE           a rule: "to reach THIS range of addresses, send
                  traffic out THROUGH this interface, via this
                  gateway." Every machine has a DEFAULT route -- where
                  everything NOT otherwise covered goes (usually your
                  router).
     DNS RESOLUTION  translating a hostname ("example.com") into an IP
                  address, by asking a configured DNS server (or
                  checking `/etc/hosts` first, for manual overrides).

   THE LOOPBACK INTERFACE (`lo`, almost always IP address 127.0.0.1,
   "localhost") is worth understanding precisely: it's a VIRTUAL
   interface that loops traffic straight back to the SAME machine,
   entirely within the kernel, never touching real network hardware at
   all. This matters a great deal once you reach containers (Phase 3):
   EACH container typically gets its OWN, separate loopback interface
   and its own "localhost," entirely distinct from the host's -- which
   is exactly why a service listening on `localhost` INSIDE a container
   is invisible from OUTSIDE it, a genuinely common, real point of
   confusion for engineers new to Docker.

Real-world example

   NETWORK NAMESPACES (a Linux kernel feature covered properly in Phase
   3, but worth previewing here) give EACH container its own, separate
   copy of everything this chapter just described: its own loopback
   interface, its own IP address(es), its own routing table -- fully
   isolated from the host's, by default. This is the DIRECT, concrete
   mechanism behind an extremely common real question every engineer
   asks the first time they use Docker: "I started a web server on
   `localhost:8080` inside my container, why can't I reach it from my
   browser on the host?"
   The answer is exactly this chapter's model, applied literally: the
   container's `localhost` is its OWN loopback interface, entirely
   separate from the host machine's `localhost` -- a service bound to
   it is reachable ONLY from processes inside that SAME network
   namespace (i.e., other processes in the same container), not from
   the host or any other container, until you EXPLICITLY publish/map
   a port (`docker run -p 8080:8080 ...`, covered in Chapter 50) to
   bridge the two separate network views together. Understanding
   Chapter 37's plain concepts -- interfaces, addresses, routes -- as
   REAL, INSPECTABLE kernel objects (not abstract networking theory) is
   precisely what makes this "obvious" instead of mysterious once you
   reach Phase 3.

Try it yourself

# Inspect your own machine's network view
ip addr show
ip route show
cat /etc/resolv.conf

# See the loopback interface specifically
ip addr show lo
ping -c 3 127.0.0.1     # loops entirely within the kernel, no real
                        # network hardware involved at all

# Resolve a hostname manually, and see /etc/hosts take priority
getent hosts example.com    # uses the SAME resolution order your
                            # system actually uses (checks /etc/hosts
                            # first, then DNS)
cat /etc/hosts               # your manual overrides, if any

Common mistakes

Assuming 127.0.0.1 is the SAME thing on every machine/container. It's a loopback address, local to WHATEVER network namespace you're currently in — a container's 127.0.0.1 and the host's are different, isolated interfaces (Phase 3).
Troubleshooting "can't connect" by guessing instead of checking the layers in order. DNS resolving correctly? Route existing to the destination? Port actually open there (Chapter 38)? Firewall blocking it? Check in that order, not randomly.
Editing /etc/resolv.conf by hand on a modern system and expecting it to stick. Many modern distros manage this file automatically (via NetworkManager or systemd-resolved) and will overwrite manual edits — check your distro's actual DNS-management approach first.

Check yourself

What does a routing table entry actually describe?
Why is the loopback interface's behaviour different inside a container than on the host?
What's the standard order of things to check when troubleshooting "I can't reach this service"?