Conflict-free reuse of subnets
bwoebi opened this issue · comments
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.
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
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.
@arkodg Any chance you can give some feedback here please? :-)