Description
Running docker in swarm mode via a previously created overlay network creates a network interface with two IP addresses.
Steps to reproduce the issue:
- Start docker with swarm mode, add two workers
- Create an overlay network named 'elasticnet'
- Deploy a basic Ubuntu container on all workers and observe the
eth0 network interface
Describe the results you received:
When looking at the interfaces available inside the docker containers that were deployed on workers/manager I can see this:
366: eth0@if367: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
link/ether 02:42:0a:00:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.3/24 scope global eth0
valid_lft forever preferred_lft forever
inet 10.0.0.2/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::42:aff:fe00:3/64 scope link
valid_lft forever preferred_lft forever
And on a different container (on a different machine):
396: eth0@if397: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
link/ether 02:42:0a:00:00:05 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.5/24 scope global eth0
valid_lft forever preferred_lft forever
inet 10.0.0.2/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::42:aff:fe00:5/64 scope link
valid_lft forever preferred_lft forever
As you can see, both containers have the same 10.0.0.2 IP that is available on the network interface, and each of them have another IP which is unique, in this case one has 10.0.0.2 and the other has 10.0.0.5.
Describe the results you expected:
I was under the impression that the network interface will only allocate one unique IP to each interface on each container
Additional information you deem important (e.g. issue happens only occasionally):
This behavior creates issues when trying to bind an interface over swarm (or trying to bind 0.0.0.0) since it is able to bind 10.0.0.2 and other containers cannot bind as well.
This is how I created the overlay network:
docker network create -d overlay elasticnet
And this is how I create the service:
docker service create --replicas 3 --network elasticnet --label elasticsearch --endpoint-mode vip --name elastic -e ES_HOSTS="tasks.elastic" --publish 9200:9200 --mount type=bind,source=/tmp/es,destination=/usr/share/elasticsearch/config --update-delay 10s elasticsearch:2.4.2
Output of docker version:
Client:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built:
OS/Arch: linux/amd64
Server:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built:
OS/Arch: linux/amd64
Output of docker info:
Containers: 3
Running: 1
Paused: 0
Stopped: 2
Images: 13
Server Version: 1.12.3
Storage Driver: devicemapper
Pool Name: docker-253:0-67411333-pool
Pool Blocksize: 65.54 kB
Base Device Size: 10.74 GB
Backing Filesystem: xfs
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 1.685 GB
Data Space Total: 107.4 GB
Data Space Available: 47.77 GB
Metadata Space Used: 3.391 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.144 GB
Thin Pool Minimum Free Space: 10.74 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: overlay bridge host null
Swarm: active
NodeID: 6dokuoq0zubyx1anig7w2ciha
Is Manager: true
ClusterID: 5bu4e1xjzxrm8c0zudk80w12g
Managers: 1
Nodes: 3
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Heartbeat Tick: 1
Election Tick: 3
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Node Address: 10.8.120.187
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.36.3.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.797 GiB
Name: node01
ID: 2OKY:RXQZ:YKGI:ORNX:242T:DUOP:B2JP:DWKP:Y5KA:ZW2Q:GRAE:MHZO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
127.0.0.0/8
Description
Running docker in swarm mode via a previously created overlay network creates a network interface with two IP addresses.
Steps to reproduce the issue:
eth0network interfaceDescribe the results you received:
When looking at the interfaces available inside the docker containers that were deployed on workers/manager I can see this:
And on a different container (on a different machine):
As you can see, both containers have the same
10.0.0.2IP that is available on the network interface, and each of them have another IP which is unique, in this case one has10.0.0.2and the other has10.0.0.5.Describe the results you expected:
I was under the impression that the network interface will only allocate one unique IP to each interface on each container
Additional information you deem important (e.g. issue happens only occasionally):
This behavior creates issues when trying to bind an interface over swarm (or trying to bind
0.0.0.0) since it is able to bind10.0.0.2and other containers cannot bind as well.This is how I created the overlay network:
And this is how I create the service:
Output of
docker version:Output of
docker info: