How to Fix Docker Network IP Address Conflicts

Prerequisite Knowledge

IP addresses consist 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, /16, etc.) determines how many leading octets belong to the network portion.

For example, 10.0.0.1/16 and 10.0.0.2/16 are in the same subnet, while 10.0.0.1/16 and 10.1.0.1/16 belong to different subnets.

Problem Symptoms

Docker daemon fails to start.

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

Investigation

First examine Docker logs:

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

Typical error messages include:

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

Manually start the daemon to see detailed output: $ /usr/bin/dockerd --debug Example failure output:

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

Check whether the expected Docker interfaces exist: $ ip addr If docker0 is missing, the bridge creation itself failed.

Resolution

Identify the Conflicting Subnet

The default Docker bridge uses 172.17.0.0/16 and docker_gwbridge uses 172.18.0.0/24. Verify that these ranges are not already in use by pinging them or inspecting the host routing table: $ route -n If a route such as 10.0.0.0 172.21.0.1 255.0.0.0 UG appears, the 10/8 block is already occupied, causing a conflict with a custom Docker subnet like 10.252.0/24.

Change Docker’s Subnet Allocation

Stop Docker first: $ systemctl stop docker Configure custom address pools in /etc/docker/daemon.json (create the file if it does not exist):

{
  "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}
  ]
}

The default-address-pools array must contain at least two entries, typically for docker0, docker_gwbridge, and optionally ucp. Using three pools avoids future conflicts.

Recreate the Ingress Network (if using Swarm)

When Docker Swarm is enabled, the ingress network also needs a non‑conflicting subnet. After initializing the swarm but before creating services, run:

$ yes 'y' | docker network rm ingress
$ yes 'y' | docker network rm my-ingress 2>&1 || 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

Creating the network with a different name avoids a race condition where the old ingress network is removed asynchronously.

Clean Up Stale Docker Network State

Before restarting Docker, clear any leftover network interfaces and cached data:

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

Alternative Quick Fix

If you need a fast, temporary solution, manually create a docker0 bridge with a non‑conflicting address:

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

Note that this bridge disappears after a system reboot and does not address the underlying subnet conflict; it only allows Docker to start.

Summary

Docker network IP address conflicts arise when the default bridge subnets overlap with existing routes on the host. Diagnose the problem by inspecting Docker logs, checking for missing docker0 / docker_gwbridge interfaces, and reviewing the host routing table. Resolve the conflict by assigning custom, non‑overlapping subnets in /etc/docker/daemon.json, recreating the ingress network if using Swarm, and cleaning stale network state before restarting the daemon.