IPAM & Subnet Exhaustion

### The two things being allocated Docker's IPAM (IP address management) works at two levels, and interviews usually want both. The first level is the **subnet given to a network**: a whole CIDR block reserved for one Docker network. The second is the **individual address given to a container** when it attaches to that network. The built-in `default` IPAM driver in the daemon does both, entirely on the local host, with no coordination with anything else on the LAN. ### The default bridge When dockerd starts for the first time on Linux it creates a Linux bridge interface called `docker0` and assigns it **172.17.0.0/16**, taking **172.17.0.1** for the host end. You can see it with `ip addr show docker0`. Every container started without a `--network` flag lands on that bridge and is handed an address inside that /16 — 172.17.0.2, then .3, and so on. The container's default route points at 172.17.0.1, which is how its outbound traffic leaves the host. That range is not special or reserved by any standard beyond being inside RFC 1918 private space. Docker simply picked it, and picked it a long time ago, which is exactly why it collides with corporate networks that also picked something in 172.16.0.0/12. ### The pool list for created networks `docker network create checkout-net` with no `--subnet` has to come up with a block from somewhere. The daemon keeps an ordered list of **predefined address pools** and allocates the first candidate that does not overlap: - 172.17.0.0/16, 172.18.0.0/16, … 172.31.0.0/16 — fifteen /16 blocks - 192.168.0.0/20, 192.168.16.0/20, … 192.168.240.0/20 — sixteen /20 blocks Because 172.17.0.0/16 is already taken by `docker0`, the first network you create typically lands on 172.18.0.0/16, the next on 172.19.0.0/16, and so on. Add up what is left and you get about **31 concurrent networks** on a default host — a number worth remembering, because it is small enough to hit on a busy CI machine. "Does not overlap" is checked against more than Docker's own networks. The daemon also looks at the host's routing table, so a range your VPN or a physical interface already routes is normally skipped. That check is best-effort and happens at allocation time, which is why a VPN that connects *after* the network was created can still collide. ### Per-container addresses Within a network's subnet the IPAM driver hands out the next free host address. The first usable address is normally taken by the gateway (the bridge interface on the host), so containers start one above it. The allocation is **not sticky**: stop a container and its address goes back to the pool; start it again and it may get a different one, especially if something else started in between. Never hardcode a container IP anywhere — that is what names and network aliases exist for. If you genuinely need a fixed address, create the network with an explicit `--subnet` and start the container with `docker run --ip`; a fixed address is only accepted on a user-defined network whose subnet you chose yourself. ### Inspecting what you actually got `docker network inspect <name>` shows the allocation under `IPAM.Config` — the subnet and the gateway — and each attached container's address under `Containers`. A compact form: ``` docker network inspect bridge -f '{{range .IPAM.Config}}{{.Subnet}} gw {{.Gateway}}{{end}}' ``` Run that against `bridge` (the network name of `docker0`) and against a network you created, and the two-level scheme becomes obvious immediately. ### Why this matters Three production problems fall straight out of these defaults. First, **collision**: a host whose containers sit on 172.18.0.0/16 cannot reach a corporate service on 172.18.0.0/16, because the local, more specific route wins. Second, **exhaustion**: a machine that accumulates networks faster than it removes them eventually cannot create any, and the failure message is about address pools, not about disk or memory. Third, **surprise addressing**: because the pools are chosen in order, the same compose project can land on a different subnet on a different machine, which breaks anything that assumed the address rather than the name. All three are configuration problems, not bugs. The daemon exposes `bip` for `docker0`'s own subnet and `default-address-pools` for the list above, both in `/etc/docker/daemon.json`, and `docker network create --subnet` for pinning one network by hand.