Open romaincabassot opened 2 years ago
In fact it is not linked to Swarm only but the way Docker checks for available network range on the local machine before create a new network (docker bridge network for example).
We are having the same issue which has a pretty bad impact on our deployment pipelines !
Expected behavior
When initializing swarm it will create different interfaces (
docker0
,docker_gwbridge
) starting with a default 172.17.0.0/16 network. We already have a 172.17.0.0/16 network defined and our VMs have a static route to reach it:Usually Swarm was "seeing" this route and initialized its interfaces with another network (for example 172.18.0.0/16) Since some recent docker update (something after 20.10.13 and before or equal to 20.10.17) the behavior has changed and Swarm creates a conflicting configuration.
Actual behavior
Actually Swarm initialize its interfaces with 172.17.0.0/16 wheter or not a static route is already defined on the server.
Steps to reproduce the behavior
With a fresh VM that already has a static route configured like this:
172.17.0.0/16 via 10.3.33.1 dev ens192
Install docker, it will create an interface that conflicts with the static route.
Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.)
If it can change something, it has to be said that the route is given by the DHCP server.