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 option for allowing overlapping AS numbers in different RIRs #10075

New Issue
Open
opened 2025-12-29 21:26:33 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:26:33 +01:00
Owner
Copy Link

Originally created by @indy-independence on GitHub (Aug 12, 2024).

NetBox version

v4.0.8

Feature type

Data model extension

Proposed functionality

Add a new flag on the RIR objects that allows disabling of the enforcement that AS numbers has to be globally unique

As requested in #15172 etc

Use case

Private AS numbers are not globally unique and for example two different tenants might use the same private AS number for two different BGP islands, so I want Netbox to be able to have these two separate instances in different records in the database. In my use-case I basically need overlapping ASNs between different tenants, but allowing overlapping between different RIRs and creating one (or more) private RIRs per tenant is probably more flexible

Database changes

New field on RIR class "enforce_unique_asns" which defaults to true and has same behavior as today, but unchecking should allow different RIRs to have overlapping ASNs

Add new field to ASN model called something like "rir_scope", could just be an integer field defaulting to 0 for the default behavior, or the integer could be refering to the id of the RIR if the enforcement of globally unique ASNs has been disabled?
ASNField should not be unique on it's own, but combination of ASN + "rir_scope" should be unique

A problem with this is that you configure the uniqueness flag on the RIR, but then it's actually the ASN records that needs to be updated. So if you change the flag on an existing RIR, for consistency it would need to look up all existing ASNs in that RIR and change the "rir_scope" field etc. Are there better ways to solve this? (Instead of adding a new field to ASN, just remove the unique flag for ASN and then manually check uniqueness in code based on RIR setting before inserting/updating DB maybe?)

External dependencies

None

Originally created by @indy-independence on GitHub (Aug 12, 2024). ### NetBox version v4.0.8 ### Feature type Data model extension ### Proposed functionality Add a new flag on the RIR objects that allows disabling of the enforcement that AS numbers has to be globally unique As requested in #15172 etc ### Use case Private AS numbers are not globally unique and for example two different tenants might use the same private AS number for two different BGP islands, so I want Netbox to be able to have these two separate instances in different records in the database. In my use-case I basically need overlapping ASNs between different tenants, but allowing overlapping between different RIRs and creating one (or more) private RIRs per tenant is probably more flexible ### Database changes New field on RIR class "enforce_unique_asns" which defaults to true and has same behavior as today, but unchecking should allow different RIRs to have overlapping ASNs Add new field to ASN model called something like "rir_scope", could just be an integer field defaulting to 0 for the default behavior, or the integer could be refering to the id of the RIR if the enforcement of globally unique ASNs has been disabled? ASNField should not be unique on it's own, but combination of ASN + "rir_scope" should be unique A problem with this is that you configure the uniqueness flag on the RIR, but then it's actually the ASN records that needs to be updated. So if you change the flag on an existing RIR, for consistency it would need to look up all existing ASNs in that RIR and change the "rir_scope" field etc. Are there better ways to solve this? (Instead of adding a new field to ASN, just remove the unique flag for ASN and then manually check uniqueness in code based on RIR setting before inserting/updating DB maybe?) ### External dependencies None
adam added the type: featurenetboxneeds milestonestatus: backlogcomplexity: low labels 2025-12-29 21:26:33 +01:00
adam commented 2025-12-29 21:26:34 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Aug 13, 2024):

I think there would probably need to be discussion around this, what the actual implementation should be.

@arthanson commented on GitHub (Aug 13, 2024): I think there would probably need to be discussion around this, what the actual implementation should be.
adam commented 2025-12-29 21:26:34 +01:00
Author
Owner
Copy Link

@indy-independence commented on GitHub (Aug 13, 2024):

Yes it's good if we can agree how the implementation should work before starting to code, I kind of suggested two different ways of doing the unique check:

  1. new "rir_scope" field on ASN model, and code for updating ASN records when RIR uniqueness flag is modified (vote with 🎉 )
  2. code for doing uniqueness-check att all places adding/modifying AS-numbers ( vote with 🚀 )
  3. other? (vote with 👀 )
@indy-independence commented on GitHub (Aug 13, 2024): Yes it's good if we can agree how the implementation should work before starting to code, I kind of suggested two different ways of doing the unique check: 1. new "rir_scope" field on ASN model, and code for updating ASN records when RIR uniqueness flag is modified (vote with :tada: ) 2. code for doing uniqueness-check att all places adding/modifying AS-numbers ( vote with :rocket: ) 3. other? (vote with :eyes: )
adam commented 2025-12-29 21:26:34 +01:00
Author
Owner
Copy Link

@indy-independence commented on GitHub (Aug 13, 2024):

It seems like ASN ranges also counts number of ASes, so we need to investigate if that check only considers things in it's own RIR or if it needs to be modified somehow to work with this overlapping AS feature

@indy-independence commented on GitHub (Aug 13, 2024): It seems like ASN ranges also counts number of ASes, so we need to investigate if that check only considers things in it's own RIR or if it needs to be modified somehow to work with this overlapping AS feature
adam commented 2025-12-29 21:26:34 +01:00
Author
Owner
Copy Link

@indy-independence commented on GitHub (Aug 13, 2024):

It seems like ASN ranges also counts number of ASes, so we need to investigate if that check only considers things in it's own RIR or if it needs to be modified somehow to work with this overlapping AS feature

Yes seems like we probably want to modify ASN ranges to only count ASes belonging to it's parent RIR if you have the "global unique" flag off?

@indy-independence commented on GitHub (Aug 13, 2024): > It seems like ASN ranges also counts number of ASes, so we need to investigate if that check only considers things in it's own RIR or if it needs to be modified somehow to work with this overlapping AS feature Yes seems like we probably want to modify ASN ranges to only count ASes belonging to it's parent RIR if you have the "global unique" flag off?
adam commented 2025-12-29 21:26:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 13, 2024):

This change needs to be tied to a new minor version as it would alter a uniqueness constraint in the database.

@jeremystretch commented on GitHub (Aug 13, 2024): This change needs to be tied to a new minor version as it would alter a uniqueness constraint in the database.
adam commented 2025-12-29 21:26:35 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Aug 24, 2024):

If I may suggest, I believe ASN uniqueness should be tied to ASN Ranges and not RIRs as it is a more natural way of enforcing ASN uniqueness, similar to how its done for vlans and vlan groups, and RIRs already can have multiple ranges associated with it.

Implementation details:

  • link ASN model with ASN Range using models.ForeignKey field
  • update ASN uniqueness constraint to take ASN Range into account using unique_together = ('asn_range', 'asn') constraint
  • enhance RIR view "related objects" to have "ASN Ranges" reference
  • enhance ASN View to list reference to ASN Range

This approach seems to me as simpler to implement and provides greater flexibility as will allow to have duplicate ASN values recorded even within same RIR, for example if RIR is mapped to a company, and company manages customer networks that use private ASN, we can create two independent ranges for each customer and map them to single RIR.

Another use case, Company has multiple loosely coupled networks (corp networks, DataCentre networks, backbone network) managed by different departments with non overlapping routing domains, each of those network uses private ASN ranges, in that case to document such a scenario we can define multiple ranges for each network and link that with Company as a RIR.

Another use case, overtime multiple companies merged and their networks come together, it happens that private ASN ranges been used across both infrastructures, to capture that in Netbox we can again, define multiple ranges each pertaining to different private ASN usage and link the to single or multiple RIRs.

In addition, the flexibility of this approach would allow to document overlapping ASN for Tenants as well, for example we can have single RIR called PRIVATE_ASN linked with overlapping ranges and each range can be linked with different tenants. Where approach of using RIR to ease ASN uniqueness constraint would not allow to do that, since RIR model not linked with Tenants.

Moreover, using ASN Range as a uniqueness constraint for ASN opens the road for further enhancing solution by defining scope attribute for ASN range to use it in a similar way as how vlan groups use it.

@indy-independence @jeremystretch @arthanson what do you think?

@dmulyalin commented on GitHub (Aug 24, 2024): If I may suggest, I believe ASN uniqueness should be tied to ASN Ranges and not RIRs as it is a more natural way of enforcing ASN uniqueness, similar to [how its done for vlans and vlan groups](https://github.com/netbox-community/netbox/blob/dab27695b9832dc64a26589d1787f34302a3f600/netbox/ipam/models/vlans.py#L205), and RIRs already can have multiple ranges associated with it. Implementation details: - link [ASN model](https://github.com/netbox-community/netbox/blob/dab27695b9832dc64a26589d1787f34302a3f600/netbox/ipam/models/asns.py#L94) with ASN Range using ``models.ForeignKey`` field - update [ASN uniqueness constraint](https://github.com/netbox-community/netbox/blob/dab27695b9832dc64a26589d1787f34302a3f600/netbox/ipam/models/asns.py#L107) to take ASN Range into account using ``unique_together = ('asn_range', 'asn')`` constraint - enhance RIR view "related objects" to have "ASN Ranges" reference - enhance ASN View to list reference to ASN Range This approach seems to me as simpler to implement and provides greater flexibility as will allow to have duplicate ASN values recorded even within same RIR, for example if RIR is mapped to a company, and company manages customer networks that use private ASN, we can create two independent ranges for each customer and map them to single RIR. Another use case, Company has multiple loosely coupled networks (corp networks, DataCentre networks, backbone network) managed by different departments with non overlapping routing domains, each of those network uses private ASN ranges, in that case to document such a scenario we can define multiple ranges for each network and link that with Company as a RIR. Another use case, overtime multiple companies merged and their networks come together, it happens that private ASN ranges been used across both infrastructures, to capture that in Netbox we can again, define multiple ranges each pertaining to different private ASN usage and link the to single or multiple RIRs. In addition, the flexibility of this approach would allow to document overlapping ASN for Tenants as well, for example we can have single RIR called ``PRIVATE_ASN`` linked with overlapping ranges and each range can be linked with different tenants. Where approach of using RIR to ease ASN uniqueness constraint would not allow to do that, since RIR model not linked with Tenants. Moreover, using ASN Range as a uniqueness constraint for ASN opens the road for further enhancing solution by defining scope attribute for ASN range to use it in a similar way as how vlan groups use it. @indy-independence @jeremystretch @arthanson what do you think?
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 complexity: low needs milestone netbox status: backlog 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#10075
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?