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

Gateway network selection ignores "--internal" and "--ipv6" #1141

Closed
robbertkl opened this Issue Apr 28, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@robbertkl

robbertkl commented Apr 28, 2016

I've noticed that when connected to multiple (user-defined) networks, NAT and gateway are always configured for the network with the (alphabetically) first network name. This seems a bit random, but I guess it works.

However, in this selection process, internal networks (created with --internal) are not excluded from this list. This means if you're connecting a container to an internal network, internet connectivity for that container will be lost, if the internal network happens to come before other (non-internal) networks it's connected to.

Here's an example showing the issue:

docker run --rm --name=test alpine ping google.com
# ping keeps going (container is connected to network "bridge")
docker network create --internal aaa
docker network create --internal zzz
docker network connect zzz test
# after this, the ping still keeps on going ("zzz" comes after "bridge")
docker network disconnect zzz test
docker network connect aaa test
# the ping now stops! ("aaa" comes before "bridge")
docker network disconnect aaa test
# ping works again

Seems to me this behaviour should not depend on what happens to be the name of the internal network in relation to the names of the other connected networks.

A possible solution would be to only consider non-internal networks for becoming "primary", i.e. select the alphabetically first non-internal network and use it for NAT/gateway. For a container only connected to an internal network, this means no gateway will be configured at all, but this makes sense because why configure a gateway if it won't work.

Similarly, IPv6 should have a separate selection, where it selects the first non-internal network that has IPv6 enabled. Currently, this breaks as well:

docker network create --ipv6 --subnet=fd00:aaa::/48 aaa
docker network create bbb
docker network create --ipv6 --subnet=fd00:ccc::/48 ccc

# a container connected to "aaa" and "bbb" has an IPv6 default gateway
# a container connected to "bbb" and "ccc" does not, even though "aaa" and "ccc" are the same
@aboch

This comment has been minimized.

Contributor

aboch commented Apr 28, 2016

Thanks for reporting this. It's a bug.
Regarding the default gateway pick up logic it is now in the documentation

When a container is connected to multiple
networks, its external connectivity is provided via the first non-internal
network, in lexical order.
@robbertkl

This comment has been minimized.

robbertkl commented Apr 28, 2016

Ah, so that's already the intended case (selecting only non-internal), perfect! Wasn't aware of this in the documentation, sorry.

What about the IPv6 case, a bug as well? Or is it currently impossible to have 2 different networks selected for external connectivity, 1 for IPv4, 1 for IPv6?

@aboch

This comment has been minimized.

Contributor

aboch commented Apr 28, 2016

The mixed v4/v6 gw network is currently a limitation. The needed code to support that is not there.

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