How to Resolve Docker IP Address Conflicts and Restore Docker Daemon

1 Prerequisite Knowledge

Because switch capacity is limited and cables cannot be infinitely long, we cannot connect all hosts to a single switch in the same Layer‑2 network. Even if we could, ARP broadcasts would cripple the network. Therefore hosts must be divided into smaller subnets and routed at Layer 3.

An IP address consists of a network part and a host part, e.g., 10.0.0.1/8 where 10 is the network address and 0.0.1 is the host address. The subnet mask ( /8) tells us which bits belong to the network.

IP is a 32‑bit binary value usually written in decimal as x.x.x.x. A simple rule: /8 means the first octet is the network, /16 means the first two octets are the network, etc.

Examples: 10.0.0.1/16 and 10.0.0.2/16 belong to the same subnet. 10.0.0.1/16 and 10.1.0.1/16 belong to different subnets.

2 Problem Manifestation

Docker daemon fails to start.

Container ports are inaccessible; packet capture shows inbound traffic but no outbound.

3 Troubleshooting

This section focuses on dockerd failing to start.

First, check the logs:

$ systemctl status docker
$ journalctl -u docker
$ dmesg | grep docker

Typical log output may contain:

docker0: link is not ready
docker_gwbridge: link is not ready

Alternatively, try to start dockerd manually and observe the output: $ /usr/bin/dockerd --debug Example error:

failed to start daemon: Error initializing network controller: list bridge addresses failed: PredefinedLocalScopeDefaultNetworks List: [10.252.0.0/24 10.252.1.0/24 10.252.2.0/24]: no available network

Run ip addr to see if docker0 and docker_gwbridge interfaces exist. If docker0 is missing, the daemon cannot create it, causing the failure.

4 Solution

Find the Conflicting Subnet

The default docker0 subnet is 172.17.0.0/16 and docker_gwbridge uses 172.18.0.0/24. Verify they are not already in use by pinging them or checking the routing table with route -n.

Example conflict: a host route 10.0.0.0 172.21.0.1 255.0.0.0 UG ... eth0 occupies the 10/8 range, which clashes with a custom docker0 subnet 10.252.0.0/24. Removing the conflicting route resolves the issue.

Modify Docker’s Subnet Allocation

Stop Docker first: $ systemctl stop docker Edit or create /etc/docker/daemon.json with at least two entries in default-address-pools for docker0 and docker_gwbridge:

{
  "bip": "",
  "default-address-pools": [
    {"base": "10.252.0.0/24", "size": 24},
    {"base": "10.252.1.0/24", "size": 24},
    {"base": "10.252.2.0/24", "size": 24}
  ]
}

Docker also creates four networks when using the swarm mode: docker0, docker_gwbridge, ucp (rare), and ingress. The first three can be configured via daemon.json; the ingress network must be recreated manually.

Recreate the Ingress Network

After initializing the swarm and before deploying services, run:

$ yes 'y' | docker network rm ingress
$ yes 'y' | docker network rm my-ingress || true
$ docker network create \
  --driver overlay \
  --ingress \
  --subnet=10.252.3.0/24 \
  --gateway=10.252.3.2 \
  --opt com.docker.network.driver.mtu=1200 \
  my-ingress

Delete Docker’s cached networks before restarting:

$ ip link del dev docker0
$ ip link del dev docker_gwbridge
$ rm -rf /var/lib/docker/network

Quick and Rough Fix

Manually create a docker0 bridge:

ip link add name docker0 type bridge
ip addr add dev docker0 10.252.0.1/24

This restores daemon startup but the bridge disappears after a reboot and may not fully resolve subnet conflicts.