Is it impossible to create multiple fabrics which have duplicated subnets from other fabrics

[Dongwon Cho]

Is it impossible to create multiple fabrics which have duplicated subnets from other fabrics? For my working environment, I sometimes have a subnet with a untagged(native) vlan which is a subnet with a tagged vlan at a different switch port. So for me, a subnet can reside at both untagged and tagged vlan depending on purpose. But for MAAS, it seems impossible to create multiple fabrics which have duplicated subnets from other fabrics. When I try it, it says "CIDR: Subnet with this CIDR already exists."

dpkg -l '*maas*' | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============================-====================================-============-=================================================
ii maas 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cli 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all MAAS client and command-line interface
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all MAAS server common files
ii maas-dhcp 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all MAAS DHCP server
ii maas-dns 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all MAAS DNS server
ii maas-proxy 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all MAAS Caching Proxy
ii maas-rack-controller 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all Rack Controller for MAAS
ii maas-region-api 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all Region controller API service for MAAS
ii maas-region-controller 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all Region Controller for MAAS
un maas-region-controller-min <none> <none> (no description available)
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-maas-provisioningserver <none> <none> (no description available)
ii python3-django-maas 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.0.0~beta5+bzr5026-0ubuntu1~xenial1 all MAAS server provisioning libraries (Python 3)

maas 1st subnets create name=storage_native description=storage_native fabric=1 vlan=untagged vid=0 space=storage_native cidr=192.168.102.0/24 rdns_mode=2 allow_proxy=true
{"cidr": ["Subnet with this Cidr already exists."]}

[Mike Pontillo (mpontillo)]

Thanks for the bug report.

The language we use here may be a bit confusing. When we say "untagged", that is the VLAN we first observed attached to the rack controller which did not have a tag. It's fine if this is actually tagged elsewhere in the network. (You should be able to update the tag to be correct in the VLAN details page.) That said, MAAS tends to work better when VLANs and tags are consistent across all switch ports

Solving this problem by modeling the subnet in a second fabric won't work. As you saw, MAAS considers subnets to be unique. (We are considering removing this restriction in the future, but currently you must have multiple MAAS regions in order to have subnets with duplicate address ranges in multiple fabrics.) It would be better to model the VLANs and subnets in MAAS to reflect reality as close as possible.

For MAAS 2.1, we are planning to do more around network and fabric discovery so that we can properly allow merging what we currently model as multiple fabrics into a single fabric.

[Andres Rodriguez (andreserl)]

Hi!

**This is an automated message**

We believe this is may no longer be an issue in the latest MAAS release. Due to the report date of this, we are currently marking it as Invalid. If you believe this bug report still valid against the latest release of MAAS, or if you are still interested in this, please re-open this bug report.

Thanks

[Igor Gnip (igorgnip)]

Hello.
This is not invalid.
Maas as of 2.9.2 still has the same issue and still it is not possible to model networks using different fabrics and spaces in order to reuse same let's say common 192.168.0.0/24 subnet.

[Jerzy Husakowski (jhusakowski)]

This is a limitation of the current data model of MAAS - it assumes that subnets are globally unique. The fix is not straightforward and requires changing the data model, corresponding logic and may affect the API and UI.

[John Puskar (jpuskar-amtrust)]

This is still a huge limitation that makes it nearly impossible to get MaaS working on our network. We aren't doing anything that special. Want want a KVM host with multiple VLANs tagged, and standalone k8s hosts that are untagged. This is a common configuration to limit the blast radius of issues like broadcast traffic storms that take out one particular VLAN, etc.

We want to use canal for easy config, so we need the tagged KVM hosts to have the same network as the untagged k8s workers.

[Jerzy Husakowski (jhusakowski)]

When MAAS commissions a machine, it aims to automatically configure its network topology: subnet, vlan and fabric. MAAS uses a heuristic to "discover" the right vlan and fabric. The heuristic assumes that the subnets are unique, and that machines that appear on the same subnet can communicate (i.e. they are also on the same vlan and fabric). This is a convenience mechanism, that prevents manual network configuration after commissioning, which allows immediate deployment after a machine has been commissioned.

We recognise that this heuristic, while convenient for basic setups, is wrong as it requires that subnets are globally unique (which MAAS data model consequently enforces). We do not want to regress in the convenience of the deployment after commissioning, and need to find another model of initial discovery of network topology that doesn't solely depend on the IP address of a NIC.

The choice of the network model has been made a long time ago and its consequences are affecting many functions of MAAS. Simply lifting the uniqueness constraint will lead to a different behaviour during commissioning, which would then require manual correction of vlan and fabric in cases where a non-unique subnet is present, as MAAS currently lacks more sophisticated methods of discovering network topology. Would such a change be an acceptable step forward?