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

Multiple ASNs per Site #5058

New Issue
Closed
opened 2025-12-29 19:23:38 +01:00 by adam · 10 comments
adam commented 2025-12-29 19:23:38 +01:00
Owner
Copy Link

Originally created by @florianschendel on GitHub (Jul 9, 2021).

Originally assigned to: @DanSheps on GitHub.

NetBox version

v2.11.9

Feature type

Change to existing functionality

Proposed functionality

  • We need the field ASN under Site as list that supports multiple ASNs
  • We want to pin multiple ASNs to locations

Use case

We use the sites (geographic sites) to document our ASNs that we use. If we have multiple ASNs per site we get a problem.

We want assign multiple ASNs per site
e.g. site --> subsidiary-vienna (ASNs: 55555, 66666) small site without DC, no locations.

We want to pin multiple ASNs to locations
e. g. site--> datacenter-Munich, location --> mu1 (ASNs: 11111, 22222), location --> mu2 (ASNs: 33333, 44444)

Database changes

No response

External dependencies

No response

Originally created by @florianschendel on GitHub (Jul 9, 2021). Originally assigned to: @DanSheps on GitHub. ### NetBox version v2.11.9 ### Feature type Change to existing functionality ### Proposed functionality - We need the field ASN under Site as list that supports multiple ASNs - We want to pin multiple ASNs to locations ### Use case We use the sites (geographic sites) to document our ASNs that we use. If we have multiple ASNs per site we get a problem. We want assign multiple ASNs per site e.g. site --> subsidiary-vienna (ASNs: 55555, 66666) small site without DC, no locations. We want to pin multiple ASNs to locations e. g. site--> datacenter-Munich, location --> mu1 (ASNs: 11111, 22222), location --> mu2 (ASNs: 33333, 44444) ### Database changes _No response_ ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:23:38 +01:00
adam closed this issue 2025-12-29 19:23:38 +01:00
adam commented 2025-12-29 19:23:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 9, 2021):

This was originally raised in #127 (a very old issue) but never really fleshed out. It's worth revisiting, however we should try to focus on what an ASN model would look like and the relationship(s) to it from other models, as well as a migration strategy to move away from the current approach.

@jeremystretch commented on GitHub (Jul 9, 2021): This was originally raised in #127 (a _very_ old issue) but never really fleshed out. It's worth revisiting, however we should try to focus on what an ASN model would look like and the relationship(s) to it from other models, as well as a migration strategy to move away from the current approach.
adam commented 2025-12-29 19:23:39 +01:00
Author
Owner
Copy Link

@eronlloyd commented on GitHub (Jul 18, 2021):

We have equipment in datacenters where we interface with other service providers in a PoP. I wonder if ASNs should instead be linked to the organization, not the sites, as it's currently very restrictive. This seems more natural, and you could even have nested tenants, since we have customers we peer with that have different divisions but all share the same ASNs.

@eronlloyd commented on GitHub (Jul 18, 2021): We have equipment in datacenters where we interface with other service providers in a PoP. I wonder if ASNs should instead be linked to the organization, not the sites, as it's currently very restrictive. This seems more natural, and you could even have nested tenants, since we have customers we peer with that have different divisions but all share the same ASNs.
adam commented 2025-12-29 19:23:39 +01:00
Author
Owner
Copy Link

@dteknet commented on GitHub (Jul 22, 2021):

I would love to have some kind of ASN inventory view where I could manage utilized/free AS numbers. It's useful for clos network topologies, where a lot of ASN are used.

@dteknet commented on GitHub (Jul 22, 2021): I would love to have some kind of ASN inventory view where I could manage utilized/free AS numbers. It's useful for clos network topologies, where a lot of ASN are used.
adam commented 2025-12-29 19:23:39 +01:00
Author
Owner
Copy Link

@ljb2of3 commented on GitHub (Jul 24, 2021):

@eronlloyd FWIW my campus design depends entirely on sites being assigned ASNs. I represent each building as a site. I run eBGP (with private ASNs) between our campus core and each building with EVPN/VXLAN on top. Assigning ASNs only to orgs would break everything I've spent the last year implementing.

There are a few limited cases where one ASN per site has been limiting though. Due to various technical reasons I may have two different ASNs in a single building, which broke my automation model. For the time being I have created dummy sites to represent the weird edge cases, but that's going to complicate things since I won't be able to correctly represent physical equipment in the racks assigned to the site for those edge cases.

I wonder if it would useful be possible to treat ASNs as something that could be inherited, just like Tenants. I'm imagining querying the API for the ASN of a particular device. If it's set on the device I get that back, if not, I get the ASN of the rack the device is in, if that's not assigned I get the ASN of the site. Or maybe I just need to query each level up as desired until I find an ASN. That would let me represent the unique ASN for the oddball device that's in the rack with everything, but every other device in the rack just inherits the site's ASN.

@dteknet I agree. I'm currently tracking all my private ASN usage in a spreadsheet. Not very netbox like! 😄

@ljb2of3 commented on GitHub (Jul 24, 2021): @eronlloyd FWIW my campus design depends entirely on sites being assigned ASNs. I represent each building as a site. I run eBGP (with private ASNs) between our campus core and each building with EVPN/VXLAN on top. Assigning ASNs only to orgs would break everything I've spent the last year implementing. There are a few limited cases where one ASN per site has been limiting though. Due to various technical reasons I may have two different ASNs in a single building, which broke my automation model. For the time being I have created dummy sites to represent the weird edge cases, but that's going to complicate things since I won't be able to correctly represent physical equipment in the racks assigned to the site for those edge cases. I wonder if it would useful be possible to treat ASNs as something that could be inherited, just like Tenants. I'm imagining querying the API for the ASN of a particular device. If it's set on the device I get that back, if not, I get the ASN of the rack the device is in, if that's not assigned I get the ASN of the site. Or maybe I just need to query each level up as desired until I find an ASN. That would let me represent the unique ASN for the oddball device that's in the rack with everything, but every other device in the rack just inherits the site's ASN. @dteknet I agree. I'm currently tracking all my private ASN usage in a spreadsheet. Not very netbox like! 😄
adam commented 2025-12-29 19:23:40 +01:00
Author
Owner
Copy Link

@eronlloyd commented on GitHub (Jul 24, 2021):

Thinking simply, why should ASNs be assigned to sites at all? Shouldn't they just be assigned to prefixes, which in real life is where they exist? Prefixes are then assigned to tenants, and tenants to everything else. When an IP is assigned to an interface, then you can see the ASN and traverse the object tree from there. Am I missing something fundamental?

@eronlloyd commented on GitHub (Jul 24, 2021): Thinking simply, why should ASNs be assigned to sites at all? Shouldn't they just be assigned to prefixes, which in real life is where they exist? Prefixes are then assigned to tenants, and tenants to everything else. When an IP is assigned to an interface, then you can see the ASN and traverse the object tree from there. Am I missing something fundamental?
adam commented 2025-12-29 19:23:40 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 30, 2021):

I think it would make more sense to pull ASNs out into their own model and allow attaching them to the organizational models (Region, Site, Site Group, Location, Rack, etc).

However, it also might make more sense to make this part of a BGP or other configuration plugin.

@DanSheps commented on GitHub (Jul 30, 2021): I think it would make more sense to pull ASNs out into their own model and allow attaching them to the organizational models (Region, Site, Site Group, Location, Rack, etc). However, it also might make more sense to make this part of a BGP or other configuration plugin.
adam commented 2025-12-29 19:23:40 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 29, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Sep 29, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:23:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 1, 2021):

Tagging this as needs milestone with the assumption that we'll be introducing a new ASN model.

@jeremystretch commented on GitHub (Oct 1, 2021): Tagging this as `needs milestone` with the assumption that we'll be introducing a new ASN model.
adam commented 2025-12-29 19:23:40 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 19, 2021):

Here is the proposed data model:

class ASN(PrimaryModel):
    asn = INTEGER
    site = ManyToMany(to='dcim.Site', related_name='asns')
    tenant = ForeignKey(to='tenancy.Tenant', related_name='asns', on_delete=PROTECT, blank=True, null=True)
    rir = ForeignKey(to='ipam.RIR', related_name='asns', on_delete=PROTECT, blank=False, null=False)

Please comment on the data model and feel free to make suggestions. Custom Fields could be added, however it may be best to limit the scope for now.

Unfortunately there are a number of other associations we could make (devices for example), however these are best handled within a BGP plugin and not as part of the core netbox functionality.

@DanSheps commented on GitHub (Oct 19, 2021): Here is the proposed data model: ``` class ASN(PrimaryModel): asn = INTEGER site = ManyToMany(to='dcim.Site', related_name='asns') tenant = ForeignKey(to='tenancy.Tenant', related_name='asns', on_delete=PROTECT, blank=True, null=True) rir = ForeignKey(to='ipam.RIR', related_name='asns', on_delete=PROTECT, blank=False, null=False) ``` Please comment on the data model and feel free to make suggestions. Custom Fields could be added, however it may be best to limit the scope for now. Unfortunately there are a number of other associations we could make (devices for example), however these are best handled within a BGP plugin and not as part of the core netbox functionality.
adam commented 2025-12-29 19:23:40 +01:00
Author
Owner
Copy Link

@jmanteau commented on GitHub (Dec 30, 2021):

Unfortunately there are a number of other associations we could make (devices for example), however these are best handled within a BGP plugin and not as part of the core netbox functionality.

I disagree with this statement as modelling EVPN with an ASN per device is quite common and this feature would have been interesting to add. However a custom field / plugin can also indeed be done.

@jmanteau commented on GitHub (Dec 30, 2021): > Unfortunately there are a number of other associations we could make (devices for example), however these are best handled within a BGP plugin and not as part of the core netbox functionality. I disagree with this statement as modelling EVPN with an ASN per device is quite common and this feature would have been interesting to add. However a custom field / plugin can also indeed be done.
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 status: accepted 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#5058
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?