The Container Network Model

Container networking is not a packet engine Docker invented. It is the same Linux kernel primitives from Chapter 1 — namespaces and cgroups — applied to the network stack, plus two pieces of plumbing the daemon wires up for you: a virtual ethernet cable and a software switch. Each container gets its own network namespace, so inside it the only interface is the one Docker created and localhost means the container, not the host.

Docker joins that isolated namespace to the outside world with a veth pair plugged into a Linux bridge, and rewrites the source address on outbound packets with NAT. Once you can draw that picture — a process in its own net namespace, a veth into a bridge, iptables for egress — every later behavior in this chapter is a consequence, not a new rule to memorize.

The Network Namespace

Every container gets its own network namespace — the net namespace from topic 03 — which means its own loopback device, its own interfaces, its own routing table, and its own iptables rules. This is why two containers can both bind port 8000 without colliding: each binds inside its own namespace, and the two namespaces never see each other's sockets. It is also why 127.0.0.1 inside a container is not the host. A process listening on 127.0.0.1 inside web has its own private loopback; proxy, with a separate loopback, cannot reach it at all.

The consequence is sharp and trips up nearly everyone once: binding a service to loopback inside a container makes it reachable only from that same container. To be reachable by a sibling container or by a published port, a server must bind 0.0.0.0 — every interface — which is why most server defaults already do.

The veth Pair

A container's namespace would be sealed off with nothing but loopback unless something connected it to the host. That something is a virtual ethernet pair: a kernel cable with two ends. One end becomes eth0 inside the container's namespace; the other end lands on the host. Anything pushed in one end comes out the other, so the veth is the bridge between the isolated namespace and the host's network. Create a container and a fresh veth pair appears; remove it and the pair is torn down.

The Linux Bridge

The host end of every container's veth plugs into a software switch — a Linux bridge. For the default network that bridge is docker0; a user-defined network gets its own. The bridge forwards frames between everything attached to it, exactly as a physical switch forwards between ports, which is what lets two containers on the same bridge reach each other directly by IP. Containers on different bridges share no switch, so they cannot reach each other at all — the isolation that topic 44 turns into a deliberate tool.

NAT and iptables for Egress

A container's address comes from the bridge's private subnet — something like 172.17.0.2 — and that address is not routable anywhere off the host. So when the container talks to the internet, the daemon's iptables masquerade rules rewrite the source address to the host's own IP on the way out, and rewrite the replies back on the way in. Outbound traffic works because the kernel is doing source NAT, not because the container has a real address on the network. When egress breaks, the answer is in the host's iptables NAT table and routing — iptables -t nat -L — not in any Docker-specific magic.

Why This View Matters

Hold the picture — a process in its own net namespace, joined by a veth to a bridge, with NAT for egress — and the rest of the chapter stops being a list of features. Publishing a port (topic 42) is a DNAT rule the daemon adds to forward a host port into the namespace. The default-versus-user-defined-bridge difference (topic 40) is simply which switch you are plugged into and whether a DNS resolver came along. The host mode (topic 43) is skipping the namespace entirely so there is nothing to NAT across. Every one of those is a variation on the same diagram.

It also tells you how to debug. Because it is all standard Linux, the standard Linux tools apply: ip to inspect interfaces and routes, iptables -t nat -L to read the NAT rules, nsenter to step inside a container's namespace, and docker network inspect to see who shares a bridge and on what subnet. You are not guessing at a black box; you are reading kernel state.