Allow prefixes to be assigned to a site group, region, site, or location

[lucasalvatore]

NetBox version

v2.11.3

Feature type

New functionality

Proposed functionality

Allow prefixes to be assigned to a site-group and not a specific site

Use case

Lets say we have a site-group called "Singapore" which contains multiple sites e.g SG1, SG2, SG3
We have servers in each site which get assigned /31s IPs from a /24
So we'd like the ability to assign the /24 prefix to the site-group only, since it does not "belong" to only one site.
From there we can assign smaller prefixes into the relevant site as needed

Database changes

unsure, don't think so

External dependencies

none

[jeremystretch]

I think it makes a lot of sense to bring prefix scoping inline with what we did for VLAN groups in v2.11 (#5284).

[jeremystretch]

Marking as blocked until we figure out whether there's a more optimal way to track multi-model parent assignments (see #6440).

[jeremystretch]

Extending this to also support the assignment of a prefix to a region as originally proposed under #5788.

[online-stuff]

What about changing Sites to be 'tags' so that multiple sites can be tagged for a prefix?

If doing this, one wouldn't be able to downgrade versions after the upgrade script converts the database.

[bsakdol]

Based on comments, it appears this issue has been marked as blocked, pending #6440. That ticket has since gone stale, so I am hoping this one does not have the same fate. I suspect being able to assign prefixes to regions and site groups would alleviate some of the pain of not being able to collapse prefixes anymore. We are currently able to filter by max length and max depth to have a similar experience to the old collapsed prefixes functionality, but those filters are not available for all prefix views (in my case, specifically when viewing large summary prefixes covering multiple sites).

[thomseddon]

As an ISP this is quite important to us (we have many sites, we arrange our management networks hierarchically and geographically e.g. Country > Metro/City > Town/Area > Site). We can manage our hierarchy by using nested regions but we therefore want to make it easy to determine from which container prefix a site prefix should be allocated. Without the ability to assign a prefix to a region, it's not so easy to determine.
The issue this was marked as being blocked by is now closed, it appears that dependancy was more of a "nice to have" as opposed to a technical blocker.
Without any objection to the principle so far, would you accept a PR on this?

[AnythingOverIP]

In our case, we have hundreds of sites that are linked together by either black fiber, microwave or MPLS. All of them, apart a few exceptions, have 2 or more P2P links. Each of those links have a /30 or /31 prefix assigned to it. Having to create a site group for every uplink would be hard to maintain. I wish we could assign sites to prefixes, without having to create a site group. In the end, I would like to see, when visiting a site page, all information regarding that site, including those site-shared prefixes.

[jefvantongerloo]

+1 for this implementation.
Need a solution for stretched datacenter.

[ryanmerolle]

This could be a good candidate for 3.6

[voolean]

+1
We need prefix assignments to a SITE-GROUP but also a REGION. Reasons are mentioned and explained above already.

I'd propose to uniform virtual object scoping mechanism in general. I will open a similar feature request for cluster and vlans assignments as well. Currently we have two types of assignments:

1. objects with SITE assignment only like vlans, cluster, prefix
2. objects with SCOPE assigment: vlan-group,bgp, BGP-pool
   Proposed solution: apply "vlan-group scoping" to vlans, prefix and clusters as well.

[ChrisHills463]

+1

Logically, our customer prefixes are associated with a region, which contains multiple sites (active/active). These are advertised to our neighbours with a bgp community for the region.

[PeterG3]

Will create a PR, first draft seems to work but needs more effort

[DanSheps]

Will create a PR, first draft seems to work but needs more effort

I would suggest holding off. This is on our backlog and we need to review it for more implementation details and to determine a release.

As an example, I see you have your base set to the current 4.0.5. Since there will be breaking changes to the way scoping is done, coupled with API changes, this would likely need to be based against the feature branch.

[PeterG3]

Thanks for the information and yes I will pause. I just wanted to advance and happy to see some progress here since our organization is kind of blocked right now.

[lucasalvatore]

hey all... i opened this back in 2021 and at least once a month i wish this was a thing. Seems there is many others who would benefit from it.... curious if the maintainers have discussed this and have some idea of when / if it could be implemented.

[jeremystretch]

Unfortunately this community has far more people wishing for features than it does building them. If anyone is interested in helping with the later, there are currently 73 issues in need of an owner.

[alehaa]

Since there are several open feature requests regarding the need for a location or region field (see #9604, #7699, #6746), I suggest adding something like a LocalizeableMixin and using it in all models that have something that can be mapped to a Location or Region. That way it would be standardized across all those models.

If accepted, I could work on a combined PR for all four feature requests.