When using Docker, its default network configuration can lead to issues in environments where certain subnets are already in use. This is particularly problematic when Docker’s default bridge network, which uses the 172.17.x.x range, overlaps with the subnets used in your organization. This article explores the steps to identify and resolve such network conflicts by modifying Docker’s default configuration, ensuring smooth operations across multiple bases.

Docker's Default Subnet Configuration and Its Impact on Network Access

Background

In a corporate environment, we have multiple bases (labeled as A, B, C, etc.), each utilizing different subnets within the 172.x.x.x range. While this setup works fine under normal circumstances, Docker's default bridge network configuration can cause conflicts as it also uses the 172.17.x.x subnet. Without modifying Docker's settings, certain bases will inevitably face network accessibility issues as the number of Docker containers grows. Here's a quick look at the subnets used by various bases:

As containers increase, subnet conflicts arise, potentially affecting communication between the bases.

Checking Docker's Network Configuration

1. Check Docker's Subnet Configuration

   Use the ifconfig docker command to check Docker's current network configuration:

   docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255

   If you see the 172.x.x.x subnet here, it indicates a potential network conflict.

2. Inspect Docker Container's Assigned Subnet

   Use the following command to inspect Docker networks and check if the 172.x.x.x subnet is already in use:

   docker network inspect $(docker network ls -q) | grep Subnet

   If any of the results show 172.x.x.x, it confirms that a network conflict is present.

Modifying Docker’s Default Subnet Configuration

Scenario 1: For New Docker Installations (No Active Containers)

1. Open Docker's configuration file for editing:

   vi /etc/docker/daemon.json

2. Add the following line to change the default bridge IP:

   "bip": "192.22.0.1/24"

3. Reload the Docker daemon and restart the Docker service:

   sudo systemctl daemon-reload && systemctl restart docker

4. Verify the changes by running the ifconfig docker command again:

   docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.22.0.1  netmask 255.255.255.0  broadcast 192.22.0.255

Scenario 2: Modifying Existing Docker Installations (With Running Containers)

In cases where containers are already running, simply changing the subnet configuration will not work, as the containers are already associated with the default network. Follow these steps to resolve the issue:

1. Stop the running containers.

2. Modify the default subnet as described in Scenario 1.

3. Delete the existing container networks.

4. Manually associate the containers with the updated network settings.

5. Restart the containers.

For Docker-Compose users, an additional step is required as detailed below.

Handling Docker-Compose Network Conflicts

Docker-Compose has a different networking model, which defaults to the 172.x.x.x range, even if you modify Docker’s default subnet. To resolve this, you can specify a custom network in your docker-compose.yml file:

version: "3.3"
services:
  # other service definitions here
  network:
   - default-network

networks:
  default-network:
    driver: bridge
    ipam:
      config:
        - subnet: 192.22.1.0/24

Additional Information: Docker's Default Subnet Creation Rules

Docker creates a unique subnet for each container when using the default bridge network mode. By default, it selects subnets from the 172.17.0.0/16 range. As more containers are created, Docker assigns subsequent subnets sequentially, such as:

• Subnet 1: 172.17.0.1 – 172.17.255.254

• Subnet 2: 172.18.0.1 – 172.18.255.254

• Subnet 3: 172.19.0.1 – 172.19.255.254

This process continues until all the available subnets in the range are exhausted. By modifying Docker’s default subnet, you can prevent conflicts with your organization's existing network configurations.

Conclusion

When running Docker in environments with existing 172.x.x.x subnets, conflicts can occur, causing connectivity issues. By adjusting Docker's default network settings and configuring custom networks for Docker-Compose, you can ensure seamless operation without risking subnet overlaps. Following these steps ensures a robust network setup that works efficiently across all your organizational bases.