Docker Community Forums

Share and learn in the Docker community.

DTR network overlaps corporate LAN


(Wwiii) #1

The base DTR installation installs on 172.19.0.0/16. One location in my company uses this address range and can’t connect to DTR. Is there a way to move my installation to another network? If not is there a way to simply re-install DTR on a different network?


(Sérgio Pelissari) #2

You don’t need to reinstall you can add at your /etc/docker/daemon.json the option

Example “bip”: “172.17.48.1/20”.

Another way is delete the current bridge via docker network ls and create another one with command:

docker network create --subnet=192.168.50.0/24 -o com.docker.network.bridge.enable_icc=false -o com.docker.network.bridge.name=docker_gwbridge docker_gwbridge

Just be careful running it on nodes with registry and controllers i just used it on nodes


(Andrefernandes) #3

The “–bip” daemon argument is what you need on the daemon of the host located on the troubled location. How to set this argument is somewhat specific to your Linux distro.

Docker installed from RHEL/CentOS yum repos, for example, look for these options in “/etc/sysconfig/docker”.

Good luck!


(Wwiii) #4

Thanks for the replies. The network in question is the dtr-br. It has has a number of services running on it already so I’m unclear how things will react if I blow away the network.

Here are some additional details:

[root@crmesomlnx01 ~]# docker network inspect dtr-br
[
{
“Name”: “dtr-br”,
“Id”: “4b0c6d60ef8fb5861584b0c8be84075e15311314d44426467398619cb0edaa57” ,
“Scope”: “local”,
“Driver”: “bridge”,
“EnableIPv6”: false,
“IPAM”: {
“Driver”: “default”,
“Options”: null,
“Config”: [
{
“Subnet”: “172.19.0.0/16”,
“Gateway”: “172.19.0.1/16”
}
]
},
“Internal”: false,
“Containers”: {
“295620f5087ee05b4a59c0c4ab0f4a5e14ed6779fc7547615f7fe9317180e803”: {
“Name”: “dtr-registry-32e0b188b67d”,
“EndpointID”: “2a26046003ac96eb216dc6a0ab10f1da8da2cd281aa83c4ad c0cbcf118676b4d”,
“MacAddress”: “02:42:ac:13:00:06”,
“IPv4Address”: “172.19.0.6/16”,
“IPv6Address”: “”
},
“b20552a841e86b22a56f978c7bad351b21e1ed0300f7e27502a7a2c1218d6f6a”: {
“Name”: “dtr-rethinkdb-32e0b188b67d”,
“EndpointID”: “fc859fa7ea2e122af3229a7a43f529e6abc7cb636a8122cf8 6f9c0ce7ea982f5”,
“MacAddress”: “02:42:ac:13:00:05”,
“IPv4Address”: “172.19.0.5/16”,
“IPv6Address”: “”
},
“b4f070a2b08f624f3e76d95118101d07156d33aff563a541a9d16965ff415e5e”: {
“Name”: “dtr-etcd-32e0b188b67d”,
“EndpointID”: “a362a1b6821ad45544784c5c8985a2a4fd54c13c4cbcf9e63 5c1d0c2fa5937b7”,
“MacAddress”: “02:42:ac:13:00:03”,
“IPv4Address”: “172.19.0.3/16”,
“IPv6Address”: “”
},
“e487b80d9b28c9165f69abb5124d251f53a32f6d8426a7527dbc622eb85b6d28”: {
“Name”: “dtr-nginx-32e0b188b67d”,
“EndpointID”: “b05006d3cc2c58fedc03cc24cb6ec1412d76257e3e680e8d7 02856be6ab6d629”,
“MacAddress”: “02:42:ac:13:00:04”,
“IPv4Address”: “172.19.0.4/16”,
“IPv6Address”: “”
},
“ef13ea737b4dd31547cc84e0d3303701fd54219f5fd5a94eb1e32f87fec5d95f”: {
“Name”: “dtr-api-32e0b188b67d”,
“EndpointID”: “e6f5ac399b4fff13c919d3551387b5c59df932f3e27ebb9c4 8031165c287e723”,
“MacAddress”: “02:42:ac:13:00:02”,
“IPv4Address”: “172.19.0.2/16”,
“IPv6Address”: “”
}
},
“Options”: {},
“Labels”: {}
}
]


(Andrevtg) #5

Oh, well, we were talking about the default IP range allocated by the Docker daemon to its containers (the “docker0” device).

You are talking about a custom network, something similar but somewhat more complicated. You should take a look at the docs (https://docs.docker.com/engine/reference/commandline/network_create/):

docker network create \
  -o "com.docker.network.bridge.host_binding_ipv4"="172.19.0.1" \
  dtr-br

Stop the containers, recreate the network with a different IP range and run the containers again.

You should be using compose (or at least ansible) in order to make deployment predictable. When you are afraid of recreating things this is a sign that you are doing old-school errors that Docker was supposed to avoid.

Cheers.


(Wwiii) #6

Appreciated. You’re spot on with your assessment. DTR was deployed using the DockerDC deployment docs and we’re still coming up to speed with what goes on behind the scenes. It’s a double edged sword when the installer package does the heavy lifting for you. The defaults are good for 99% of the population.

Will take a look another look at the docs, bite the bullet and see if I can get it to work. Will post back with what I find out.


(Andrevtg) #7

Damn installers… :slight_smile:


(Sérgio Pelissari) #8

andrevtg makes a good sugestion, i have 100% installed process on Ansible so if you do it you can simulate how the process to delete bridge and recreate another one with the correct ip. If you don’t try to start a standalone node with the services and simulate it, but how i said on first post you have to delete and recreate one with the correct ip.


(Wwiii) #9

Thanks for the hints. It put me on the right track and I was able to resolve this without too much issue.

Here’s what I did for posterity:

docker stop <all containers with IP addresses on the “bad” network>
docker network rm dtr-br
docker network create --subnet=“172.19.0.0/16” --gateway=“172.19.0.1” dtr-br
docker start

This made all the containers start up with new IPs on the new network and now everyone can connect without issue.

Thanks again for the pointers.

~w


(Funkydorian) #10

Here is a more practical solutions, tested and works:

http://www.deryasezen.com/2017/01/19/docker-overlay-and-bridge-networks-overlapping-with-the-corporate-networks/


(Patrick Devine) #11

This is actually going to change in the next version of DTR. We’re phasing out the bridge network entirely and all services will talk on the overlay instead. We’re going to include an option in the bootstrapper called --overlay-subnet which you can directly specify the IP Address/CIDR for the overlay.