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

Allow Prefixes and VLAN to be assigned to more than one site #11150

New Issue
Closed
opened 2025-12-29 21:40:59 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:40:59 +01:00
Owner
Copy Link

Originally created by @AnythingOverIP on GitHub (May 8, 2025).

NetBox version

v4.3.0

Feature type

Change to existing functionality

Proposed functionality

  • Add the ability to assign a Prefix to more than one site
  • Add the ability to assign a VLAN to more than one site (or allow more than one VLAN to be assigned to a prefix)

Use case

We manage networks where we have hundreds of /30 and /31 prefixes for point to point connections between sites.

When looking at prefixes or VLANs, you cannot know to which sites this item really belongs to unless you go and analyze the assigned components at each end. Looking at a site page, you cannot see all prefixes at that site if you have not assigned it to, meaning that there will always be at least one for the two sites where you wont have the information for a given P2P link. As a partial workaround, we can create the same VLAN at both sites, but then we can't assign both to a prefix...

FR https://github.com/netbox-community/netbox/issues/6414 expanded the mapping of prefixes to Site Groups, but since you cannot have a site part of two separate Site groups, this does not address our needs...

Database changes

TBD

External dependencies

None AFAIK

Originally created by @AnythingOverIP on GitHub (May 8, 2025). ### NetBox version v4.3.0 ### Feature type Change to existing functionality ### Proposed functionality - Add the ability to assign a Prefix to more than one site - Add the ability to assign a VLAN to more than one site (or allow more than one VLAN to be assigned to a prefix) ### Use case We manage networks where we have hundreds of /30 and /31 prefixes for point to point connections between sites. When looking at prefixes or VLANs, you cannot know to which sites this item really belongs to unless you go and analyze the assigned components at each end. Looking at a site page, you cannot see all prefixes at that site if you have not assigned it to, meaning that there will always be at least one for the two sites where you wont have the information for a given P2P link. As a partial workaround, we can create the same VLAN at both sites, but then we can't assign both to a prefix... FR https://github.com/netbox-community/netbox/issues/6414 expanded the mapping of prefixes to Site Groups, but since you cannot have a site part of two separate Site groups, this does not address our needs... ### Database changes TBD ### External dependencies None AFAIK
adam added the type: feature label 2025-12-29 21:40:59 +01:00
adam closed this issue 2025-12-29 21:40:59 +01:00
adam commented 2025-12-29 21:40:59 +01:00
Author
Owner
Copy Link

@xkilian commented on GitHub (May 9, 2025):

We currently use the following approach to resolve this.
Create a custom device object for prefixes. Assign the L3 devices that participate in routing to the object.
This is even more meaningful than assigning two sites.
This way in the prefix view you can see the real scope from an L3 point of view, as there could be one, two or even three L3 devices in the same prefix.
Cheers!

@xkilian commented on GitHub (May 9, 2025): We currently use the following approach to resolve this. Create a custom device object for prefixes. Assign the L3 devices that participate in routing to the object. This is even more meaningful than assigning two sites. This way in the prefix view you can see the real scope from an L3 point of view, as there could be one, two or even three L3 devices in the same prefix. Cheers!
adam commented 2025-12-29 21:41:00 +01:00
Author
Owner
Copy Link

@cronicded commented on GitHub (May 10, 2025):

This is useful in a network architecture utilizing device0 insite0 terminatingdevice5 in site5 via an 802.1q trunk. This extends to N of sites with respective N of device.

A vlan exists between site0 and site5, but the vlanGroup can only be assigned to one site or siteGroup. device0 can only be assigned to one siteGroup and all sites should not be assigned to one siteGroup.

It is also the case this architecture is replicated laterally where sites1-5 terminate to device0, and sites7-11 terminate to device6. device0 and device6 are in the same site, but the group should be N of 2 siteGroup.

Alternatively, nested siteGroups, but I think the case a vlanGroup should be assignable to more than one site both respective and irrespective of the siteGroup issue.

@cronicded commented on GitHub (May 10, 2025): This is useful in a network architecture utilizing `device0` in`site0` terminating`device5` in `site5` via an 802.1q trunk. This extends to N of `sites` with respective N of `device`. A `vlan` exists between `site0` and `site5`, but the `vlanGroup` can only be assigned to one `site` or `siteGroup`. `device0` can only be assigned to one siteGroup and all sites should not be assigned to one `siteGroup`. It is also the case this architecture is replicated laterally where `sites1-5` terminate to `device0`, and `sites7-11` terminate to `device6`. `device0` and `device6` are in the same site, but the group should be N of 2 `siteGroup`. Alternatively, nested `siteGroups`, but I think the case a `vlanGroup` should be assignable to more than one site both respective *and* irrespective of the `siteGroup` issue.
adam commented 2025-12-29 21:41:00 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (May 15, 2025):

This isn't something we will be able to support. The proper long-term answer to this is likely some other kind of abstraction rather than overloading the use of VLANs for multiple sites, to say nothing of applying the same logic to VLANs and Prefixes.

@bctiemann commented on GitHub (May 15, 2025): This isn't something we will be able to support. The proper long-term answer to this is likely some other kind of abstraction rather than overloading the use of VLANs for multiple sites, to say nothing of applying the same logic to VLANs and Prefixes.
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#11150
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?