Add support to enforce IP and Prefix uniqueness based on Tenancy

[dmulyalin]

NetBox version

v3.7.5

Feature type

New functionality

Proposed functionality

Add support for an option to enforce IP Uniqueness based on Tenant using parameters combination.

1. Enforce uniqueness IP constraint for global table and Tenancy
   ENFORCE_GLOBAL_UNIQUE=True
   ENFORCE_TENANT_UNIQUE=True
   NetBox will prevent the creation of duplicate prefixes and IP addresses in the global table (that is, those which are not assigned to any VRF) - even within same Tenant, but allow creation of overlapping IPs that belong to different Tenants.

2. Enforce uniqueness IP constraint based on Tenancy only
   ENFORCE_GLOBAL_UNIQUE=False
   ENFORCE_TENANT_UNIQUE=True
   NetBox will allow the creation of duplicate prefixes and IP addresses in the global table (that is, those which are not assigned to any VRF) for different Tenants but will not allow to create duplicate IP for the same tenant in global table.

3. Ease uniqueness IP constraint
   ENFORCE_GLOBAL_UNIQUE=False
   ENFORCE_TENANT_UNIQUE=False
   NetBox will allow the creation of duplicate prefixes and IP addresses in the global table (that is, those which are not assigned to any VRF) even for the same Tenant.

4. Resembles existing behavior
   ENFORCE_GLOBAL_UNIQUE=True
   ENFORCE_TENANT_UNIQUE=False
   NetBox will prevent the creation of duplicate prefixes and IP addresses in the global table (that is, those which are not assigned to any VRF) - even for different Tenants.

Use case

As per docs:
Typically, the tenant model is used to represent a customer or internal organization, however it can be used for whatever purpose meets your needs.

Allowing IP overlaps recording within global table that belong to different Tenants (a.k.a. customers or organizations or departments) is the requirement dictated by the reality of modern networks, Infoblox for example supports that using Network Views.

Using workaround like fake VRFs to bypass existing limitation does not seems to be the best approach as it pollutes Source of Truth with information that does not have representation in real network and violates VRF use case.

Database changes

I would believe no DB changes needed but the logic that enforces IP/Prefix uniqueness constrain check need to be improved to take Tenancy into account.

External dependencies

Nill.

[jeffgdotorg]

Thanks for the feature request, and in particular for the thorough proposal and use case. I'm moving this issue along to needs owner; if you would like to work it through to a PR, let us know and a maintainer will assign it to you. Otherwise any other developer can do the same.

[jeremystretch]

I'm sorry but this does not seem tenable, nor does the use case strike me as legitimate.

Using workaround like fake VRFs to bypass existing limitation does not seems to be the best approach as it pollutes Source of Truth with information that does not have representation in real network and violates VRF use case.

There is nothing "fake" about VRFs, where by contrast attempting to leverage tenant associations in place of real routing tables is very much an arbitrary and contrived approach.

[dmulyalin]

@jeremystretch please let me elaborate.

Example - 1.

Two companies merge together, both having IT department that uses 192.168.0.0/16 space to IP corporate networks, both use global routing table to route the traffic. Each company has enforced uniqueness of IP addresses within their corp network. Each company modeled as a tenant in Netbox with "ENFORCE_GLOBAL_UNIQUE" set to False to accomodate overlapping IP addresses, but we now have a problem - how do we enforce IP uniqueness in Netbox for each of the networks individually? Possible answers are:

1. we don't, we simply hope people will do their due diligence and will not allocate duplicate IP addresses for each network
2. we create "fake" VRFs - org1-default and org2-default and use those VRF to document IP addresses and enforce uniqueness

either of above approaches is suboptimal, for the 1st one - hope is not a good strategy, for the 2nd we have to create ephemeral entities in Netbox to workaround its limitations.

Example - 2

Service Provider offers managed CPE service to customers, each customer has its own IP allocation schema, naturally, many customers have overlapping IP subnets and addresses, which is fine, since each customers routed in dedicated L3 VPN within SP Network. But we have a problem, how do we record CPE addressing information in Netbox if we use default table on CPE for customer routing. We model each customer in Netbox as a Tenant. We also want to document SP default routing table IP space in Netbox. Several options to address this:

1. run dedicated instance of Netbox for each customer and another instance of Netbox for SP's own network
2. create "fake" VRF for each customer default routing table in addition to actual VRF used to route customer traffic e.g. customer1-default, customer2-default to document customers' IP addresses, in addition, use global Netbox IP space to document SP default routing table network.

either of above approaches is suboptimal, for the 1st one - management overhead is too high, for the 2nd we have to create ephemeral VRFs in Netbox to workaround its limitations.

Example - 3

Company has to manage multiple LAB environments - dev, stage and pre-prod. Since all LAB environments is a downscaled version of production network, all LAB networks use same IP schema and have overlapping subnets and addresses. Moreover, production environment uses global routing table to route the traffic. To document this, each environment modeled in Netbox as a Tenant. But we have a problem now, since we want to enforce IP uniqueness within each of the LABs but allow IP overlaps between them, possible solutions are:

1. Set "ENFORCE_GLOBAL_UNIQUE" to False and hope people will pay enough due diligence while documenting LAB and Prod environments
2. create "fake" vrf for each of the lab environments e.g. dev-default, preprod-default, stage-default and use them to record IP space while using Netbox default IP space to document production Network

either of above approaches is suboptimal, for the 1st one we risking to introduce overlaps for production network which renders IPAM useless as a tool that helps to avoid IP duplicates, moreover, configuration provisioning system will have to take Netbox limitation into account and make sure IP allocation happens on a per-environment basis. For the 2nd we have to create ephemeral entities in Netbox to workaround its limitations.

---

To generalize - any use case where we have requirements to document overlapping IP space across multiple tenants but need to enforce per-tenant IP uniqueness proved to be problematic with current Netbox implementation.

Having capability to enforce IP uniqueness on a per tenant basis while allowing to record duplicate IP addresses in global table is the possible way to address these use cases natively in Netbox.

[dmulyalin]

To handle above problems over IPAM solutions developed these capabilities:

• device42 uses "VRF Groups" and there is no "default/global" IP space at all
• Infoblox uses "Network Views" to isolate IP address spaces
• PHPIPAM uses "Sections" to enforce IP uniqueness

IMHO, Netbox' tenant concept is the best way to model real life network entities, since it is generic enough to accommodate broad set of use cases. Agree, attributing tenant to IP Space boundaries seems arbitrary but the reality is as such that tenants used to represent organizations, customers, departments, networks, environments - entities that have isolated administrative domains resulting in IP allocation evolved independently containing overlaps.

If there is better way exists to address demonstrated use cases, I am all ears.

[jeremystretch]

I'm afraid the proposed functionality is not tenable for the core product. However, as NetBox is open source you are free to fork the code and modify it to fit your specific use case.