Docker networks creation conflicts with existing routes

[romaincabassot]

• This is a bug report
• This is a feature request
• I searched existing issues before opening this one

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:

ip route
172.17.0.0/16 via 10.3.33.1 dev ens192

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.

ip route
default via 10.3.33.1 dev ens192 
10.3.33.0/24 dev ens192 proto kernel scope link src 10.3.33.242 
172.17.0.0/16 via 10.3.33.1 dev ens192 # DHCP sent static route
172.17.0.0/16 dev docker_gwbridge proto kernel scope link src 172.17.0.1 # Swarm create a conflicting route
192.168.13.0/24 dev docker0 proto kernel scope link src 192.168.13.1 linkdown

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:

Docker version 20.10.17, build 100c701

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.2-docker)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 29
 Server Version: 20.10.17
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: active
  NodeID: soi7tiwt3z3b880ipyupk1o5f
  Is Manager: true
  ClusterID: sr631t5joeen0n8x2l4h5an6v
  Managers: 1
  Nodes: 1
  Default Address Pool: 10.0.0.0/8  
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 10.3.33.242
  Manager Addresses:
   10.3.33.242:2377
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc version: v1.1.2-0-ga916309
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 4.19.0-21-amd64
 Operating System: Debian GNU/Linux 10 (buster)
 OSType: linux
 Architecture: x86_64
 CPUs: 6
 Total Memory: 23.54GiB
 Name: testrct-0
 ID: 6DFK:LT5B:TIVG:N2P7:3ESU:2X6U:RZTN:UPNI:AUNA:K2FY:SMHK:KIHV
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  livesp-registry.liveaction.com:5000
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support

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.

[romaincabassot]

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).

[ggaugry]

We are having the same issue which has a pretty bad impact on our deployment pipelines !