New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Control interface name in docker multiple networking #25181

satyajitbm opened this Issue Jul 28, 2016 · 11 comments


None yet

satyajitbm commented Jul 28, 2016

With the workaround suggested in #17796 for multiple network mode for docker containers, it is not possible to control the interface name with the docker network connect command. The order of the ethx interfaces after docker start is not consistent with the sequence of docker connect commands. Only the network added in the docker create command comes up as eth0 and is consistent.

My post boot script relies on the name of the interfaces and won't work if the order is changed and I require the interfaces to be up on boot. So, I can't use pipework script with the -iflag as well.

Output of docker version:

 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:23:11 2016
 OS/Arch:      linux/amd64

 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:23:11 2016
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 6
 Running: 6
 Paused: 0
 Stopped: 0
Images: 24
Server Version: 1.11.2
Storage Driver: devicemapper
 Pool Name: docker-253:0-877344-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: ext4
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 4.141 GB
 Data Space Total: 107.4 GB
 Data Space Available: 103.2 GB
 Metadata Space Used: 4.489 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.143 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. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
 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
 Volume: local
 Network: bridge host null
Kernel Version: 3.10.0-229.20.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.24 GiB
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Additional environment details: Running on a centos 7.1 bare metal.
uname -a
Linux "REDACTED" 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Steps to reproduce the issue:

  1. docker network create --driver bridge --subnet net1
  2. docker network create --driver bridge --subnet net2
  3. docker network create --driver bridge --subnet net3
  4. docker network create --driver bridge --subnet net4
  5. docker create -it --net=net1 --ip= --name=test centos:7
  6. docker network connect --ip net2 test
  7. docker network connect --ip net3 test
  8. docker network connect --ip net4 test
  9. docker start test
  10. docker exec -it test yum install -y net-tools
  11. docker exec -it test ifconfig

Results received: eth2 was assigned and eth3 was assigned

Results expected: eth2 must be assigned and eth3 must be assigned or there needs to be a way to specify the interface name in docker network connect command.

The issue happens occasionally and the probability of it occurring increases with the increase in the number of networks the container is connected to.


This comment has been minimized.


cirocosta commented Dec 12, 2016

So, essentially, in your case you can work around it through subnet filtering, right? e.g., you know that a given subnet has been assigned to a given network, thus you can filter your iface list and find the one which is the one assigned to your desired network. Did you go through this path? Or did something different?


This comment has been minimized.


thaJeztah commented Jul 10, 2017

With the "csv" style syntax for networks being worked on (see #31964, and PR's docker/cli#62 (for services), and docker/cli#156 for docker run), perhaps it would be possible to add an additional configuration option to specify the interface name for each network that the container is attached to.

ping @abhinandanpb @fcrisciani WDYT?


This comment has been minimized.


abhi commented Jul 10, 2017

@thaJeztah I believe one of the goals of the network-opt initially was to ensure symmetry between the service create and docker run. But this interface option would only apply to container create / network connect right ?


This comment has been minimized.


thaJeztah commented Jul 21, 2017

@abhinandanpb would it be different for services and "regular" containers? i.e.;

docker run \
  --network name=my-network,iface=my-eth \
  --network name=my-other-network,iface=my-other-eth \
docker service create \
  --network name=my-network,iface=my-eth \
  --network name=my-other-network,iface=my-other-eth \

For docker service create, docker would create an my-eth and my-other-eth in each task (container) backing the service.


This comment has been minimized.

chrisjonez commented Oct 9, 2017

@thaJeztah I'm interested in being able to specify an explicit interface, so:

docker run \
  --network name=my-network,iface=my-eth \
  --network name=my-other-network,iface=my-other-eth \

would be great...or something similar in docker network connect..., where the interface can be specified.

I also use docker-compose, so would also need to be able to specify the interface in the services block of a container.

Is there any likelihood that this will be implemented soon?


This comment has been minimized.

purplesrl commented Oct 12, 2017


This is pretty serious, meaning that if you have more networks, the interfaces will get mixed up.

Almost all network applications base themselves on the fact that the interface names are the same.

Why would they be randomly assigned it is beyond my understanding, when it would have been much easier to assigned them in order at least based on the network name or the order the networks were connected to the container.


This comment has been minimized.


mikesir87 commented Dec 14, 2017

I am interested in this as well. As a use case...

Have a service that is in two networks... one for reverse proxying (frontend) and one for its own backend (backend). In order to receive traffic, the app (a Java app) needs to listen to the interface for the frontend. Since we aren't using static subnets, it's difficult to discover/know which interface we should use.

The proposed solution above would work for us.


This comment has been minimized.

sandersaares commented Apr 20, 2018

I would definitely be interested in having Docker network interfaces have predictable names. Most software dealing with networking assumes you have static interface names, so I cannot use any of that with Docker networks, which is a pain.


This comment has been minimized.

ptman commented Jul 31, 2018

docker network create -o br-extra

This comment has been minimized.

multun commented Sep 20, 2018

@ptman that's not the point. it's about the interface name inside the container


This comment was marked as spam.

Jabbo16 commented Dec 4, 2018


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment