Libnetwork: Allow to use overlapping subnets for macvlan networks

[AStotal]

According to pull request #2148 there is a pool overlapping check added.
But check is not necessary when we use a macvlan driver for networks.

Now I've got an error

18.03.1-ce-0-ubuntu:

λ: docker network create -d macvlan \
>     --subnet=10.0.10.0/24 \
>     -o parent=eth1.10 \
>     macvlan10
eda930768dff1c77e6fcf7935fce2a6e066a5ea22d63452c764042b67fbc99ed
~
λ: 
~
λ: docker network create -d macvlan \
>     --subnet=10.0.10.0/24 \
>     -o parent=eth2.10 \
>     macvlan20
81f73d1ef978b030d541bf46d4f91320cf5e77e81d6bdd9449bf54d2607605e5
~
λ: 

18.09.1-ce-0-ubuntu:

~
λ: docker network create -d macvlan \
>     --subnet=10.0.10.0/24 \
>     -o parent=eth1.10 \
>     macvlan10
a89201f74726423b95b38c76a7aeb131101f8e2ff3937f78592da06350710cc0
~
λ: 
~
λ: docker network create -d macvlan \
>     --subnet=10.0.10.0/24 \
>     -o parent=eth2.10 \
>     macvlan20
Error response from daemon: Pool overlaps with other one on this address space
~
λ: 

[AStotal]

up!

[teadur]

It would make sense indeed, one subnet /24 and assign /29 or /30 ip-range per swarm node.

[ashneilson]

We're experiencing the same issue running Docker version 19.03.4, build 9013bf583a on Debian 9.

Our servers run two Network Interfaces on the same subnet for redundancy eno1.100 and eno2.100.

Could the over-lapping check be ignored for the macvlan driver given this behavior is potentially expected?

[rgriebl]

Just got hit by this too after moving containers to a new host. This check makes using multiple containers using macvlans on the same ethX.Y VLAN device completely unusable via docker-compose.

[ashneilson]

For those who might be using multiple interfaces for redundancy / fail-over (@AStotal looking at your config you might be) - instead of running two networks (one per Interface / VLAN) we've opted to use bonding on Linux to provide the same redundancy but a single interface for containers to use.

While this doesn't resolve the issue at hand here, this might help those who are using two interfaces for the same VLAN / Subnet.

eno1.100 and eno2.100 became bond0.100 for us and we now create just one Docker Network for this bonded interface.

[bpascard]

This issue prevents me from integrating Docker containers with an existing environment where many VLANs are addressed with identical subnets. One solution would be to run separate Docker hosts for each VLAN which is very impractical as it defeats the purpose of having a macvlan driver in the first place.

[amarcum]

This is also causing an issue for the setup we have at work. We need the VLANs to be different with the subnets being the same for a network simulation. Our Dell switch requires the subnets to be the same to enable and disable routing between different containers.

[semaja2]

+1 on this, we require each docker to be in its own VLAN with the same IP range for a multi tenant configuration, they are isolated with namespaces veth bridges

[eriktews]

I also don't see an issue with macvlan devices that share the same subnet and device but use a none overlapping ip-range.

[MilosQL]

Allowing overlapping subnets in different external VLANs makes perfect sense.

Is there any way to bypass this restriction?

[FilipQL]

We have a scenario in which several physical interfaces on our host are attached to different segments and the segments in question have the same IP subnets (configured externally, by design and on purpose). Connecting VMs to these "overlapping" networks is perfectly OK and does not cause any problems at all. But when we tried to migrate from VMs to Docker containers (which should be one of the stronger use cases for the "macvlan" driver), this restriction got in our way (and for no good reason, as far as I can tell).

[eriktews]

I would even say that overlapping subnets in the same vlan is perfectly fine as well as long as you don't allocate the same IP in both subnets. For example I would love to have some docker containers that just communicate with devices in my local network and some are supposed to do the same AND have a default gateway.