Understanding the Error: subnet 192.168.10.0/24 overlaps with another one in this address space in macvlan network creation with nerdctl

[eric-ela-b3006c]

When creating a macvlan network with nerdctl, I encounter the error subnet 192.168.10.0/24 overlaps ….

My goal is to create a flat network (i.e., a single segment network) that includes physical hosts, an ESXi server (with VMs), and containers within a containerd host.

The containerd host details are as follows:

• Host address: 192.168.10.125
• LAN subnet: 192.168.10.0/24
• Range of addresses dedicated to containers: 192.168.10.128/25

A macvlan network is required for UDP multicast/broadcast. The --network=host option is not feasible in my context. Therefore, I am using rootful containerd.

The command for network creation is:

$ sudo nerdctl network create -d macvlan --subnet=192.168.10.0/24 --gateway=192.168.10.1 -o parent=ens160 -o macvlan_mode=bridge macvlan_network

(Option --ip-range= omitted for brevity).

This command fails with the following error:

FATA[0000] subnet 192.168.10.0/24 overlaps with another one in this address space

I am using containerd 1.7.25 as the containerization engine and nerdctl (v2.0.0) as the CLI on Rocky Linux 9.4, and I am very grateful for this software.

I understand that the subnet intersection check is implemented in netutil/netutil.go .

However, I am puzzled as to why this check is necessary for a macvlan network, as the same command succeeds in Docker (see below).

I am aware of a related discussion on GitHub: #3430, What is the purpose for subnet intersection checking in netutil.go?

The same command succeeds with Docker:

$ sudo docker network create -d macvlan --subnet=192.168.10.0/24 --gateway=192.168.10.1 -o parent=ens160 macvlan_network

-> SUCCESS 😀

$ sudo docker run --ip=192.168.10.250 --network=macvlan_network [...]

-> SUCCESS 😀

The check behind the error subnet 192.168.10.0/24 overlaps … seems (at least to me) to be overly restrictive. It also deviates from Docker’s behaviour.

Moreover, there is a workaround:

• disconnect the network interface
• create the macvlan network
• reactivate the network afterward.

$ sudo nmcli dev disconnect ens160
$ sudo nerdctl network create -d macvlan --subnet=192.168.10.0/24 --gateway=192.168.10.1 -o parent=ens160 macvlan_network
$ sudo nmcli con up ens160

After that, containers in macvlan network run properly.

While this workaround is a bit cumbersome, it is done only once for the network creation.

Essentially, this workaround bypasses the network intersection test, which relies on function GetLiveNetworkSubnets in netutil/subnet/subnet.go:

func GetLiveNetworkSubnets() ([]*net.IPNet, error)

So my question is:
Is the error subnet xxx.yyy.zzz.0/24 overlaps ... really justified for the creation of a macvlan network in a flat network configuration?

Thanks, I appreciate your time and attention to this matter.