-
Notifications
You must be signed in to change notification settings - Fork 18.9k
Add daemon options for Docker network subnets #21776
Copy link
Copy link
Closed
Labels
area/networkingNetworkingNetworkingkind/enhancementEnhancements are not bugs or new features but can improve usability or performance.Enhancements are not bugs or new features but can improve usability or performance.kind/featureFunctionality or other elements that the project doesn't currently have. Features are new and shinyFunctionality or other elements that the project doesn't currently have. Features are new and shinystatus/acceptedversion/1.10
Metadata
Metadata
Assignees
Labels
area/networkingNetworkingNetworkingkind/enhancementEnhancements are not bugs or new features but can improve usability or performance.Enhancements are not bugs or new features but can improve usability or performance.kind/featureFunctionality or other elements that the project doesn't currently have. Features are new and shinyFunctionality or other elements that the project doesn't currently have. Features are new and shinystatus/acceptedversion/1.10
Output of
docker version:Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.):
Happens on physical hosts and AWS/GCP
Steps to reproduce the issue:
--bip=...when starting a Docker daemon (e.g. to avoid conflicts with other things on your company's LAN). I set mine to192.168.1.0/16.docker network create ...).docker network inspectagainst the new network and look at the subnet.Describe the results you received:
The subnet on my machine is, for example,
172.19.0.0/16Describe the results you expected:
Seeing as how I specified a default bridge IP for the daemon, I'd have expected that to be propagated to the bridge driver.
Additional information you deem important (e.g. issue happens only occasionally):
An obvious workaround is to use
--subnetwhen creating the bridge networks. The problem, though, is that this can lead to race conditions if networks are started in multiple threads. That is, I end up writing a lot of exception handling for cases of overlapping subnet ranges, but it seems more straightforward for Docker to handle this (as it already does on the default subnet it seems to hardcode).