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

VLAN Uniqueness checking in a Site #11285

New Issue
Closed
opened 2025-12-29 21:42:56 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:42:56 +01:00
Owner
Copy Link

Originally created by @sepetuks on GitHub (Jun 16, 2025).

NetBox version

v4.2.9

Feature type

Change to existing functionality

Proposed functionality

Check VLAN Uniqueness in Site same as it is being checked in VLAN group

Use case

Did I remember it wrong that earlier VLANs assigned to site had to be unique?
Based on VLAN management documentation "Each VLAN can be assigned to a VLAN group or site to convey the domain in which the VLAN exists"
Now I see uniqueness is checked only against VLAN group but not Site.
For me it is a big overhead to create separate VLAN group for each site just in order to enforce unique ID checking.
We use VLAN Group for VLANS that are stretched between sites only.

Database changes

No response

External dependencies

No response

Originally created by @sepetuks on GitHub (Jun 16, 2025). ### NetBox version v4.2.9 ### Feature type Change to existing functionality ### Proposed functionality Check VLAN Uniqueness in Site same as it is being checked in VLAN group ### Use case Did I remember it wrong that earlier VLANs assigned to site had to be unique? Based on [VLAN management documentation](https://github.com/netbox-community/netbox/blob/main/docs/features/vlan-management.md) "Each VLAN can be assigned to a VLAN group **or** site to convey the domain in which the VLAN exists" Now I see uniqueness is checked only against VLAN group but not Site. For me it is a big overhead to create separate VLAN group for each site just in order to enforce unique ID checking. We use VLAN Group for VLANS that are stretched between sites only. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: under reviewcomplexity: low labels 2025-12-29 21:42:57 +01:00
adam closed this issue 2025-12-29 21:42:57 +01:00
adam commented 2025-12-29 21:42:58 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jun 16, 2025):

Requiring VLAN IDs to be unique for a site would be disastrous for us. We try to avoid it, but sometimes even end up with multiple VLANs with the same VID on the same device in different bridges. As far as I can tell, there has never been a uniqueness constraint for VLANs with respect to Site.

@sleepinggenius2 commented on GitHub (Jun 16, 2025): Requiring VLAN IDs to be unique for a site would be disastrous for us. We try to avoid it, but sometimes even end up with multiple VLANs with the same VID on the same device in different bridges. As far as I can tell, there has never been a uniqueness constraint for VLANs with respect to Site.
adam commented 2025-12-29 21:42:58 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jun 16, 2025):

I am 99% sure that VID's have been unique in site as long as site is set in the VLAN. You would get around this with VLAN Groups.

The uniqueness check I believe was:

(VID, Site, VG if VG is not Null)

The following data sets would create a uniqueness exceptions:

VID,Site,Group
100,Akron,
100,Akron,

VID,Site,Group
100,Akron,DM Group
100,Akron,DM Group
# Weird corner case you could get with old data I believe

VID,Site,Group
100,,Akron Group
100,,Akron Group

This would not:

VID,Site,Group
100,Akron,
100,Akron,DM Group
100,,Akron Group
@DanSheps commented on GitHub (Jun 16, 2025): I am 99% sure that VID's have been unique in site as long as site is set in the VLAN. You would get around this with VLAN Groups. The uniqueness check I believe was: `(VID, Site, VG if VG is not Null)` The following data sets would create a uniqueness exceptions: ``` VID,Site,Group 100,Akron, 100,Akron, ``` ``` VID,Site,Group 100,Akron,DM Group 100,Akron,DM Group # Weird corner case you could get with old data I believe ``` ``` VID,Site,Group 100,,Akron Group 100,,Akron Group ``` This would not: ``` VID,Site,Group 100,Akron, 100,Akron,DM Group 100,,Akron Group ```
adam commented 2025-12-29 21:42:58 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jun 16, 2025):

For me it is a big overhead to create separate VLAN group for each site just in order to enforce unique ID checking.
We use VLAN Group for VLANS that are stretched between sites only.

I think this is the crux of the issue, and I think a better proposal would be to have a simplified workflow:

  • Remove site from VLAN
  • Add a new "Primary for Site" attribute on VLAN Group which ties a VLAN Group scoped to a site to the site as the "primary" VLAN Group
  • Change the VLAN edit form site field be sort of a pseudo field that would:
    • Automatically create a VLAN Group if there is not already a primary VLAN Group
    • Automatically delete a VLAN Group if a VLAN is moved/deleted out of the Group and it is the last VLAN in the group (optional)
    • Link the VLAN to the VLAN Group behind the scenes

This kind of thing would allow the workflow desired by sepetuks while preserving the functionality by sleepinggenius2

@DanSheps commented on GitHub (Jun 16, 2025): > For me it is a big overhead to create separate VLAN group for each site just in order to enforce unique ID checking. > We use VLAN Group for VLANS that are stretched between sites only. I think this is the crux of the issue, and I think a better proposal would be to have a simplified workflow: * Remove site from VLAN * Add a new "Primary for Site" attribute on VLAN Group which ties a VLAN Group scoped to a site to the site as the "primary" VLAN Group * Change the VLAN edit form `site` field be sort of a pseudo field that would: * Automatically create a VLAN Group if there is not already a primary VLAN Group * Automatically delete a VLAN Group if a VLAN is moved/deleted out of the Group and it is the last VLAN in the group (optional) * Link the VLAN to the VLAN Group behind the scenes This kind of thing would allow the workflow desired by sepetuks while preserving the functionality by sleepinggenius2
adam commented 2025-12-29 21:42:59 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jun 16, 2025):

Looking back through the code, the uniqueness constraint was set to (group, vid) and (group, name) when VLANGroup was added back in v1.3.0 and was only changed to add (qinq_svlan, vid) and (qinq_svlan, name) when Q-in-Q support was added in v4.2.0, but I cannot find where there has ever been a uniqueness constraint defined on the site, like the one you reference. I just confirmed in both a v4.1.11 instance (which has had that VLAN data since v2.5.7) and the v4.3.2 demo site that multiple VLANs with different names and the same VID in the same Site (no VLAN Group) definitely works just fine.

@DanSheps I'm fine with your proposal, I just see challenges with the migration when there are multiple VLANs with the same VID and Site in the existing dataset. Do you propose automatically creating separate VLAN groups for each one? If so, what VLAN group would the unique VLANs go in? One other challenge I see is that when you navigate to a site in the UI, it currently only lists related VLANs that are directly associated with that site, not a VLAN group that is scoped to that site. Likewise, the VLAN filter form only allows searching for VLANs that are directly associated with a site. If you remove the site field from the VLAN object, I would request that the functionality that used it, like the two previous examples, be extended to support VLAN Groups that are scoped to a Site as well. I would love to see that functionality be extended to the other scope types, but I can understand where that would probably be a different feature request.

@sleepinggenius2 commented on GitHub (Jun 16, 2025): Looking back through the code, the uniqueness constraint was set to `(group, vid)` and `(group, name)` when `VLANGroup` was added back in v1.3.0 and was only changed to add `(qinq_svlan, vid)` and `(qinq_svlan, name)` when Q-in-Q support was added in v4.2.0, but I cannot find where there has ever been a uniqueness constraint defined on the site, like the one you reference. I just confirmed in both a v4.1.11 instance (which has had that VLAN data since v2.5.7) and the v4.3.2 demo site that multiple VLANs with different names and the same VID in the same Site (no VLAN Group) definitely works just fine. @DanSheps I'm fine with your proposal, I just see challenges with the migration when there are multiple VLANs with the same VID and Site in the existing dataset. Do you propose automatically creating separate VLAN groups for each one? If so, what VLAN group would the unique VLANs go in? One other challenge I see is that when you navigate to a site in the UI, it currently only lists related VLANs that are directly associated with that site, not a VLAN group that is scoped to that site. Likewise, the VLAN filter form only allows searching for VLANs that are directly associated with a site. If you remove the site field from the VLAN object, I would request that the functionality that used it, like the two previous examples, be extended to support VLAN Groups that are scoped to a Site as well. I would love to see that functionality be extended to the other scope types, but I can understand where that would probably be a different feature request.
adam commented 2025-12-29 21:42:59 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Jun 20, 2025):

This will be deprecated with #19738.

@arthanson commented on GitHub (Jun 20, 2025): This will be deprecated with #19738.
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 status: under review 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#11285
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?