Closed pytz closed 3 years ago
Here a minimal working example.
First create both networks:
docker network create -d bridge --subnet=192.168.101.0/24 a_net
docker network create -d bridge --subnet=192.168.102.0/24 b_net
Start the following using docker-compose up -d
:
networks:
a_net:
external: true
name: a_net
b_net:
external: true
name: b_net
services:
my_service:
image: alpine:3.7
container_name: my_service
networks:
a_net:
ipv4_address: 192.168.101.2
priority: 100
b_net:
ipv4_address: 192.168.102.2
priority: 200
command: sleep 3600
ports:
- 127.0.0.1:1194:1194/udp
- 127.0.0.1:1195:1194/udp
version: '2.4'
Check the output of docker exec -it my_service ip route
:
default via 192.168.101.1 dev eth0
192.168.101.0/24 dev eth0 scope link src 192.168.101.2
192.168.102.0/24 dev eth1 scope link src 192.168.102.2
Hello @pytz thank you for filling this issue
Hello I would like to work on this issue I'm new so I would new info how can I be assigned
Is it really a bug as it does state regarding routing metric but the priority of connecting
I'm not sure if it is a bug. You are right as the docker-compose reference (https://docs.docker.com/compose/compose-file/compose-file-v2/#priority) just says it indicates the order in which networks should be connected. But I still don't understand which interface becomes the "default" route. My guess would be the first interface (= eth0). So changing the order in which the interfaces get connected to the docker container should influence the eth0, eth1, ... assignment.
But going back to the minimal working example above the priority doesn't seem to matter (note the different priority):
networks:
a_net:
external: true
name: a_net
b_net:
external: true
name: b_net
services:
my_service:
image: alpine:3.7
container_name: my_service
networks:
a_net:
ipv4_address: 192.168.101.2
priority: 100
b_net:
ipv4_address: 192.168.102.2
priority: 200
command: sleep 3600
ports:
- 127.0.0.1:1194:1194/udp
- 127.0.0.1:1195:1194/udp
version: '2.4'
# docker exec -it my_service ip route
default via 192.168.101.1 dev eth0
192.168.101.0/24 dev eth0 scope link src 192.168.101.2
192.168.102.0/24 dev eth1 scope link src 192.168.102.2
Changing the priority has no result:
networks:
a_net:
external: true
name: a_net
b_net:
external: true
name: b_net
services:
my_service:
image: alpine:3.7
container_name: my_service
networks:
a_net:
ipv4_address: 192.168.101.2
priority: 200
b_net:
ipv4_address: 192.168.102.2
priority: 100
command: sleep 3600
ports:
- 127.0.0.1:1194:1194/udp
- 127.0.0.1:1195:1194/udp
version: '2.4'
# docker exec -it my_service ip route
default via 192.168.101.1 dev eth0
192.168.101.0/24 dev eth0 scope link src 192.168.101.2
192.168.102.0/24 dev eth1 scope link src 192.168.102.2
Has this bug been acknowledged? I repeatedly get the wrong interface (network) assigned to the default route in my containers.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is still not addressed (or even acknowledged) @shin- any input?
This issue has been automatically marked as not stale anymore due to the recent activity.
It seems to be the case for interal networks as well, see https://gist.github.com/jfellus/cfee9efc1e8e1baf9d15314f16a46eca to reproduce. Lexical order of network names seems to always superseed any priorities you set. To be precise, this has an impact on the order in which your container gets connected to networks, but it is then ignored by docker that keep on allocating ethX based on lexical order of network names
@jfellus Thanks for the lexical order workaround!
lexicon ,, tabs ,,, typical of python people ... ;)
@jfellus if you use IPv6 (enable ipv6: true), in this case the lexical order stops working - a network that uses IPv6 becomes more priority
tested at v3.9: 2 networks, one of them uses IPv6
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it had not recent activity during the stale period.
Still having this issue, quite annoying how it's just being ignored
Same problem here. Using lexic order workaround didn't work.
Lexic order applies to the real name of the network, not the "alias".
As an example:
networks:
a_net:
external: true
name: zz_net
b_net:
external: true
name: aa_net
services:
my_service:
image: alpine:3.7
container_name: my_service
networks:
a_net:
ipv4_address: 192.168.101.2
priority: 200
b_net:
ipv4_address: 192.168.102.2
priority: 100
command: sleep 3600
ports:
- 127.0.0.1:1194:1194/udp
- 127.0.0.1:1195:1194/udp
This would result in 192.168.101.2
being applied to eth1
as real network name is zz_net
and is lexically greater than real name of b_net
, aa_net
.
Seems to be similar / duplicate of https://github.com/docker/compose/issues/8561 ?
Not sure if this is intended behaviour or a bug.
I have a docker-compose file for an OpenVPN container which uses two external networks:
The started container uses astnet for the default route:
and also in the matching iptables rule:
Now I would like to configure docker to use the ovpnet as default network. According to https://docs.docker.com/compose/compose-file/compose-file-v2/#priority and Issue #4645 it should be possible by setting a priority like this:
But this doesn't change anything. astnet is still eth0 and has the default route. I also tried switching the priorities and changing the order of the networks but no success.
Version informations
docker version:
docker-compose version: