Skip to content
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

Conflict-free reuse of subnets #2578

Open
bwoebi opened this issue Sep 10, 2020 · 3 comments
Open

Conflict-free reuse of subnets #2578

bwoebi opened this issue Sep 10, 2020 · 3 comments

Comments

@bwoebi
Copy link

bwoebi commented Sep 10, 2020

Let me start with my current working setup:

# Setup a veth pair into a network namespace
ip netns add $NS
ip netns exec $NS ip link set lo up
ip link add docker-$NS type veth peer name docker netns $NS
ip link set docker-$NS up
ip -n $NS link set docker up
# I'm also setting up a couple more interfaces within the network namespace here, but irrelevant to illustrate

# Couple the docker network with the veth pair end in the host netns - there seems to be no way to directly connect docker to an interface in a custom network namespace
docker network create docker-net-$NS -d macvlan --subnet=10.0.50.0/24 --gateway=10.0.50.1 -o parent=docker-$NS

docker run --network=docker-net-$NS --ip=10.0.50.2 someImage

This works perfectly fine ...

Unless I'm trying to run the same thing (with the same IPs) in a separate network namespace simultaneously:

docker[15441]: Error response from daemon: Pool overlaps with other one on this address space

This error for sure is correct, if docker is running in bridge mode; and mostly appropriate within common usages of a macvlan.
Though, in the specific case, where the interfaces are not present in the same network namespace (or even if they are, but there is no direct bridging/forwarding between them without nat), there is no effective conflict.

It should be possible to create macvlan networks independently. Perhaps with a warning, or maybe with the --i-know-what-i-am-doing flag (or more seriously: --ignore-overlapping-networks).

P.s.: Use case is being able to run multiple isolated networking tests in parallel on the same host server. And a lot of our setup has fixed IPs, thus the docker containers also need to all have the same IP.

@thaJeztah
Copy link
Member

If I recall correctly (but I may be mistaken), originally overlapping IP-ranges were allowed, but was changed to an "error" because

a) the built-in IPAM did not take separate networks into account (so two networks in the same range would get IP-addresses from the same pool, and thus would not be able to consume all available IP-addresses in the range)
b) overlapping networks was problematic if a container would be attached to two networks in the same range, which tripped-up many users

@arkodg perhaps you have ideas

@bwoebi
Copy link
Author

bwoebi commented Nov 23, 2020

a) Would not be a major issue unless there's a hard failure if you try to manually assign a same IP to different containers ... At least starvation of address pool through automatic assignment can be worked around by enlarging subnet or manual assignment then. (Though, for sure, preferable if it worked.)
b) Yeah … hence I'd suggest still having the restriction in place, just disable-able.

@bwoebi
Copy link
Author

bwoebi commented Apr 28, 2021

@arkodg Any chance you can give some feedback here please? :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants