I\'m facing a pretty strange issue:
Here is my config:
I work from two differents places with differ
In my case I would not apply Clement solution because I have the network conflict only with my dev pc while the container is delivered to many server which are not affected. This problem in my opinion should be resolved as suggested here. I tried this workaround:
I stopped the container with "docker-compose down" which destroys the bridge
Started the container while I'm on the "bad" network, so the container use another network
Since then, if I restart the container on any network it doesn't try to use the "bad" one, normally get the last used one.
You have to tell Docker to use a different subnet. Edit /etc/docker/daemon.json
and use something like this:
{
"bip": "198.18.251.1/24",
"default-address-pools": [
{
"base": "198.18.252.0/22",
"size": 26
}
]
}
Information is a bit hard to come by, but it looks like the bip
option controls the IP and subnet assigned to the docker0
interface, while default-address-pools
controls the addresses used for the br-*
interfaces. You can omit bip
in which case it will grab an allocation from the pool, and bip
doesn't have to reside in the pool, as shown above.
The size
is how big of a subnet to allocate to each Docker network. For example if your base
is a /24
and you also set size
to 24
, then you'll be able to create exactly one Docker network, and probably you'll only be able to run one Docker container. If you try to start another you'll get the message could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network
, which means you've run out of IP addresses in the pool.
In the above example I have allocated a /22
(1024 addresses) with each network/container taking a /26
(64 addresses) from that pool. 1024 ÷ 64 = 16, so you can run up to 16 Docker networks with this config (so max 16 containers running at the same time, or more if some of them share the same network). Since I rarely have more than two or three running containers at any one time this is fine for me.
In my example I'm using part of the 198.18.0.0/15
subnet as listed in RFC 3330 (but fully documented in RFC 2544) which is reserved for performance testing. It is unlikely that these addresses will appear on the real Internet, and no professional network provider will use these subnets in their private network either, so in my opinion they are a good choice for use with Docker as conflicts are very unlikely. But technically this is a misuse of this IP range so just be aware of potential future conflicts if you also choose to use these subnets.
The defaults listed in the documentation are:
{
"bip": "",
"default-address-pools": [
{"base": "172.80.0.0/16", "size": 24},
{"base": "172.90.0.0/16", "size": 24}
]
}
As mentioned above, the default empty bip
means it will just grab an allocation from the pool, like any other network/container will.
I manage to solve this issue after reading this:
https://success.docker.com/Architecture/Docker_Reference_Architecture%3A_Designing_Scalable%2C_Portable_Docker_Container_Networks
The second docker bridge br-1a0208f108d9 was created by docker because i was using a docker-compose file which involve the creation of an other custom network.
This network was using a fixed ip range:
networks:
my_network:
driver: bridge
ipam:
config:
- subnet: 172.16.0.0/16
gateway: 172.16.0.1
Which collide with the custom docker network.
The solution was simply to change the IP of the custom docker network.