starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add support to enforce IP and Prefix uniqueness based on Tenancy #9471

New Issue
Closed
opened 2025-12-29 20:50:20 +01:00 by adam · 5 comments
adam commented 2025-12-29 20:50:20 +01:00
Owner
Copy Link

Originally created by @dmulyalin on GitHub (Apr 11, 2024).

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.

Originally created by @dmulyalin on GitHub (Apr 11, 2024). ### 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.
adam added the type: feature label 2025-12-29 20:50:20 +01:00
adam closed this issue 2025-12-29 20:50:20 +01:00
adam commented 2025-12-29 20:50:21 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Apr 18, 2024):

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.

@jeffgdotorg commented on GitHub (Apr 18, 2024): 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.
adam commented 2025-12-29 20:50:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 19, 2024):

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.

@jeremystretch commented on GitHub (Apr 19, 2024): 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.
adam commented 2025-12-29 20:50:21 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Apr 20, 2024):

@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 commented on GitHub (Apr 20, 2024): @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.
adam commented 2025-12-29 20:50:21 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Apr 20, 2024):

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.

@dmulyalin commented on GitHub (Apr 20, 2024): 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.
adam commented 2025-12-29 20:50:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 28, 2024):

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.

@jeremystretch commented on GitHub (May 28, 2024): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#9471
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?