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

Enable many-to-many site assignment for VLAN groups #4225

New Issue
Closed
opened 2025-12-29 18:33:59 +01:00 by adam · 6 comments
adam commented 2025-12-29 18:33:59 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Oct 29, 2020).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.6.9
  • NetBox version: 2.9.7

Proposed Functionality

Convert the current ForeignKey field assigning a VLANGroup to a site to a ManyToManyField, to allow the assignment of a VLANGroup to multiple sites.

Use Case

This change will allow the tracking of discrete L2 domain which extend beyond a single site. Today, this can be modeled only with the coarseness of a "global" VLANGroup (one which is not assigned to any site).

IMO this approach is preferable to allowing many-to-many assignment directly between VLANs and sites, because it provides a layer of abstraction for the domain. A user can add many VLANs to a multi-site VLANGroup without needing to ensure the correct multi-site assignment of each VLAN.

Database Changes

Change VLANGroup.site from a ForeignKey to a ManyToManyField, which results in the introduction of an intermediate table. The actual database migration would probably involve creating a new sites field, replicating all existing relations, and finally deleting the current site field.

External Dependencies

None

Originally created by @jeremystretch on GitHub (Oct 29, 2020). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.6.9 * NetBox version: 2.9.7 ### Proposed Functionality Convert the current ForeignKey field assigning a VLANGroup to a site to a ManyToManyField, to allow the assignment of a VLANGroup to multiple sites. ### Use Case This change will allow the tracking of discrete L2 domain which extend beyond a single site. Today, this can be modeled only with the coarseness of a "global" VLANGroup (one which is not assigned to _any_ site). IMO this approach is preferable to allowing many-to-many assignment directly between VLANs and sites, because it provides a layer of abstraction for the domain. A user can add many VLANs to a multi-site VLANGroup without needing to ensure the correct multi-site assignment of each VLAN. ### Database Changes Change `VLANGroup.site` from a ForeignKey to a ManyToManyField, which results in the introduction of an intermediate table. The actual database migration would probably involve creating a new `sites` field, replicating all existing relations, and finally deleting the current `site` field. ### External Dependencies None
adam added the status: acceptedtype: feature labels 2025-12-29 18:33:59 +01:00
adam closed this issue 2025-12-29 18:33:59 +01:00
adam commented 2025-12-29 18:34:00 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Nov 7, 2020):

This is perfect, and should honestly be extend to vlans and prefixes

@anubisg1 commented on GitHub (Nov 7, 2020): This is perfect, and should honestly be extend to vlans and prefixes
adam commented 2025-12-29 18:34:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 9, 2020):

@anubisg1 that wouldn't make any sense. a prefix can be assigned to only one L2 and/or L3 domain.

@jeremystretch commented on GitHub (Nov 9, 2020): @anubisg1 that wouldn't make any sense. a prefix can be assigned to only one L2 and/or L3 domain.
adam commented 2025-12-29 18:34:00 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Nov 9, 2020):

@jeremystretch prefix can only be assigned to a L2 (vlan) or a L3 (vrf) domain.
But such domains are not bound to sites.

A vlan, especially in DC environments, can exist across multiple physical sites.
I can have a DC in Milan and another in Rome, such vlans is extended between DCs via OTV or VXLAN.

This means that the same vlan (and the same IP subnet) actually exists on 2 (ore more) sites at the same time.

netbox fits perfectly for DCIM (Data Center Inventory Management) part, as a physical box can exist either here or there, but we really struggle to model DC networks and overlays.

maybe the simplest way would be to have the possibility to have an "overlay" object.
a vlan/subnet could be assigned to an overlay, then 1 or more sites could belong to the overlay.

i don't know exactly, but the problem remains, once a vlan moves outside of a physical site, the whole model breaks down

@anubisg1 commented on GitHub (Nov 9, 2020): @jeremystretch prefix can only be assigned to a L2 (vlan) or a L3 (vrf) domain. But such domains are not bound to sites. A vlan, especially in DC environments, can exist across multiple physical sites. I can have a DC in Milan and another in Rome, such vlans is extended between DCs via OTV or VXLAN. This means that the same vlan (and the same IP subnet) actually exists on 2 (ore more) sites at the same time. netbox fits perfectly for DCIM (Data Center Inventory Management) part, as a physical box can exist either here or there, but we really struggle to model DC networks and overlays. maybe the simplest way would be to have the possibility to have an "overlay" object. a vlan/subnet could be assigned to an overlay, then 1 or more sites could belong to the overlay. i don't know exactly, but the problem remains, once a vlan moves outside of a physical site, the whole model breaks down
adam commented 2025-12-29 18:34:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 9, 2020):

Implementing this feature would obviate the need for mapping VLANs to multiple sites. It would also be unnecessary to map prefixes to multiple sites because we can infer that from their association to the multi-site L2 domain.

@jeremystretch commented on GitHub (Nov 9, 2020): Implementing this feature would obviate the need for mapping VLANs to multiple sites. It would also be unnecessary to map prefixes to multiple sites because we can infer that from their association to the multi-site L2 domain.
adam commented 2025-12-29 18:34:00 +01:00
Author
Owner
Copy Link

@xkilian commented on GitHub (Nov 9, 2020):

If the overlay/underlay is an object, we associate its scope to devices and interfaces. (Terminology: underlay = ex. Shortest Path Bridging, Overlay= ex. Vxlan). The site an overlay/underlay is present in, should automatically be known(via the meta-data of the device attached to the overlay) and should not be manually associated with an overlay, IMO.

@xkilian commented on GitHub (Nov 9, 2020): If the overlay/underlay is an object, we associate its scope to devices and interfaces. (Terminology: underlay = ex. Shortest Path Bridging, Overlay= ex. Vxlan). The site an overlay/underlay is present in, should automatically be known(via the meta-data of the device attached to the overlay) and should not be manually associated with an overlay, IMO.
adam commented 2025-12-29 18:34:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 26, 2021):

After giving this some more thought, I wonder if it might be better to change the site foreign key to a scope generic foreign key, capable of assigning a VLANGroup to either a region, site, rack group, or rack. It might also be worthwhile to introduce a new SiteGroup model (edit: see #5892) to serve as a second dimension along which sites can be grouped (in addition to geographic region).

This approach would allow us to provide more flexibility around the establishment of a L2 domain while avoiding the headaches that come with many-to-many relationships.

@jeremystretch commented on GitHub (Feb 26, 2021): After giving this some more thought, I wonder if it might be better to change the `site` foreign key to a `scope` generic foreign key, capable of assigning a VLANGroup to either a region, site, rack group, or rack. It might also be worthwhile to introduce a new SiteGroup model (edit: see #5892) to serve as a second dimension along which sites can be grouped (in addition to geographic region). This approach would allow us to provide more flexibility around the establishment of a L2 domain while avoiding the headaches that come with many-to-many relationships.
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#4225
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?