Docker Network Subnet Calculator

Two things run out with Docker networking: the number of networks, and the address space itself. Give a count, or the ranges Docker must stay out of, or both.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Calculate. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

More networks than the defaults allow

The error that follows reads like a bug rather than a capacity limit

40 networks

A range the host also routes

One internal service becomes unreachable and nothing in the application changed

5 networks
172.17.0.0/16

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Assuming the address pool is effectively unlimited

    It is 31 networks, and compose projects consume them one each. The failure appears as an error that reads like a bug rather than a limit.

    Instead:Set default-address-pools with a larger base and a smaller size before you need it.

  2. Editing default-address-pools and restarting, then finding nothing changed

    The setting applies to networks created afterwards. Existing networks keep their subnets.

    Instead:Recreate the affected networks. For docker0 specifically, use bip instead.

  3. Stopping containers instead of bringing the project down

    The network stays allocated and keeps counting against the pool, invisibly.

    Instead:Use docker compose down, and docker network prune periodically.

The defaults give exactly 31 networks

172.17.0.0/16 through 172.31.0.0/16 is fifteen, and 192.168.0.0/16 carved into /20s is sixteen more. Past that, every network creation fails.

The error does not sound like a capacity limit

"could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network". It reads like a bug. Every compose project creates a network and only docker compose down removes it, so a build machine reaches the limit far sooner than the number of applications suggests.

172.17.0.0/16 collides with a great many corporate networks

When a Docker network takes a range the host also routes elsewhere, the route to the container network wins. The symptom is one internal service or one VPN subnet becoming unreachable from that machine while everything else works, with nothing having changed in the application.

The fix is default-address-pools in daemon.json

A base of 10.100.0.0/16 with size 24 gives 256 networks in a range almost nothing else claims. Restart the daemon after changing it.

Changing the setting does not move existing networks

It is consulted when a network is created. Existing networks keep their subnets across a restart, so editing the file and restarting appears to do nothing at all, which is where the time on this usually goes.

The default bridge is a special case

docker0 is not created from the pools, so default-address-pools does not move it. That one needs bip in daemon.json, which is the setting people miss after fixing everything else.

Networks leak from projects that were not brought down

Deleting a project directory, or stopping containers by hand, leaves the network allocated and counting against the pool. docker network ls on a busy machine is usually a long list of networks nothing is using.