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

remove uniqueness of vlan name within a group #6394

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

Originally created by @jcralbino on GitHub (Apr 23, 2022).

NetBox version

v3.1

Feature type

Change to existing functionality

Proposed functionality

Currently within a vlan group the vlan Id and vlan name needs to be unique

This is not something that is modelling the real word. In several scenarios the vlan name can be shared across several devices with different vlans ids

Use case

Our use case uses the vlan name to assign the corresponding vlan id. Vlan name is provided after 802.1x authentication of a device to define the configuration of a port

In this case a role is associated with the vlan name . In different switches this could be a different vlan id matching also to different layer 3 networks.

Database changes

Minimal as primary keys will not change

External dependencies

In order to minimize Impact of this change, the uniqueness of tupple (vlan name, vlan id ) could be enforced using custom validators that were recently enhanced in netbox 3.x

users that do not require this uniqueness can disable the validation

Originally created by @jcralbino on GitHub (Apr 23, 2022). ### NetBox version v3.1 ### Feature type Change to existing functionality ### Proposed functionality Currently within a vlan group the vlan Id and vlan name needs to be unique This is not something that is modelling the real word. In several scenarios the vlan name can be shared across several devices with different vlans ids ### Use case Our use case uses the vlan name to assign the corresponding vlan id. Vlan name is provided after 802.1x authentication of a device to define the configuration of a port In this case a role is associated with the vlan name . In different switches this could be a different vlan id matching also to different layer 3 networks. ### Database changes Minimal as primary keys will not change ### External dependencies In order to minimize Impact of this change, the uniqueness of tupple (vlan name, vlan id ) could be enforced using [custom validators ](https://netbox.readthedocs.io/en/stable/customization/custom-validation/) that were recently enhanced in netbox 3.x users that do not require this uniqueness can disable the validation
adam added the type: feature label 2025-12-29 19:40:12 +01:00
adam closed this issue 2025-12-29 19:40:12 +01:00
adam commented 2025-12-29 19:40:12 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 23, 2022):

I don't think we should remove the uniqueness of a new within a VLAN group. If we do that, there is no way to enforce uniqueness within a group of related devices for the VLAN name.

That said, i think the approach you are taking to VLAN groups may be your issue here. A VLAN group could be scoped to a single device, a site, etc. It is a organizational container, not a structure that is replicated in real life.

However, I think a more apt description for a VLAN group might be "VLAN domain". Then allow specific VLANs to be attached to VLAN domains in a many to many relationship. This would require a massive rework but would be more in-line with real world VLAN boundaries (for example, using Cisco. A device with vtp off or transparent, the VLAN domain would be to that device only, but a device with vtp not disabled, the VLAN domain would be the same as the VTP domain.

You can also capture better things like VXLAN as the VLAN would be the same across domains potentially (ignoring the fact that the vni can map to different VLANs on each end of a VXLAN)

@DanSheps commented on GitHub (Apr 23, 2022): I don't think we should remove the uniqueness of a new within a VLAN group. If we do that, there is no way to enforce uniqueness within a group of related devices for the VLAN name. That said, i think the approach you are taking to VLAN groups may be your issue here. A VLAN group could be scoped to a single device, a site, etc. It is a organizational container, not a structure that is replicated in real life. However, I think a more apt description for a VLAN group might be "VLAN domain". Then allow specific VLANs to be attached to VLAN domains in a many to many relationship. This would require a massive rework but would be more in-line with real world VLAN boundaries (for example, using Cisco. A device with vtp off or transparent, the VLAN domain would be to that device only, but a device with vtp not disabled, the VLAN domain would be the same as the VTP domain. You can also capture better things like VXLAN as the VLAN would be the same across domains potentially (ignoring the fact that the vni can map to different VLANs on each end of a VXLAN)
adam commented 2025-12-29 19:40:12 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Apr 23, 2022):

I don't think the issue I have can be solved by rescoping what a vlan group is .
Let's consider then the following:

  • a vlan group is a group of access devices in a site, vlan-group-buildingA.
  • in buildingA we have several layer 3 networks for vlans to be assigned to users.
    Vlan 100 - users in floor 0
    Vlan 101 - users in floor 1
    Vlan 102 - users in floor 2
  • each vlan as a separate layer 3 network
    100- 10.0.100.0/24
    101 - 10.0.101.0/24
    ..
  • 802.1x authentication will assign the correct vlan using vlan name "users vlan"
    This works as long as different vlans ids can share the same vlan name

To model this in the current setup I used custom fields to have the correct name of the vlan stored . Using the vlan name as a placeholder for some unique value that is not used in our environment.

But indeed I feel that the current way of modelling layer 2 networks is too limited and removing the uniqueness of vlan name could improve the way it can be used and more adapted to different requirements

@jcralbino commented on GitHub (Apr 23, 2022): I don't think the issue I have can be solved by rescoping what a vlan group is . Let's consider then the following: - a vlan group is a group of access devices in a site, vlan-group-buildingA. - in buildingA we have several layer 3 networks for vlans to be assigned to users. Vlan 100 - users in floor 0 Vlan 101 - users in floor 1 Vlan 102 - users in floor 2 - each vlan as a separate layer 3 network 100- 10.0.100.0/24 101 - 10.0.101.0/24 .. - 802.1x authentication will assign the correct vlan using vlan name "users vlan" This works as long as different vlans ids can share the same vlan name To model this in the current setup I used custom fields to have the correct name of the vlan stored . Using the vlan name as a placeholder for some unique value that is not used in our environment. But indeed I feel that the current way of modelling layer 2 networks is too limited and removing the uniqueness of vlan name could improve the way it can be used and more adapted to different requirements
adam commented 2025-12-29 19:40:12 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 23, 2022):

a vlan group is a group of access devices in a site, vlan-group-buildingA.

Whoever told you this is wrong, a VLAN group doesn't need to be confined to a site. You just need to have your site's and locations setup properly:

Site:Building A
  * Location: Floor: 1
    * Location: Room: 1A13
  * Location: Floor: 2
    * Location: Room: 2A43
  * Location: Floor: 3
    * Location: Room: 3A71

VLAN Group: Building A - Floor 1
 * Scope: Location (Floor: 1)
 * Scope: Location (Floor: 2)

In this case, you should have a different VLAN group for your building A, floor 1 and building a, floor 2; as these are discreet groupings of switches

@DanSheps commented on GitHub (Apr 23, 2022): > a vlan group is a group of access devices in a site, vlan-group-buildingA. Whoever told you this is wrong, a VLAN group doesn't need to be confined to a site. You just need to have your site's and locations setup properly: ``` Site:Building A * Location: Floor: 1 * Location: Room: 1A13 * Location: Floor: 2 * Location: Room: 2A43 * Location: Floor: 3 * Location: Room: 3A71 VLAN Group: Building A - Floor 1 * Scope: Location (Floor: 1) * Scope: Location (Floor: 2) ``` In this case, you should have a different VLAN group for your building A, floor 1 and building a, floor 2; as these are discreet groupings of switches
adam commented 2025-12-29 19:40:12 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Apr 24, 2022):

In the core we're the layer 3 is deployed we are terminating layer 2. So that is where I terminate my vlan group.
The different access switches are connected to the core directly. In the core we are not enforced by the vendor to have uniqueness on the vlan name.

@jcralbino commented on GitHub (Apr 24, 2022): In the core we're the layer 3 is deployed we are terminating layer 2. So that is where I terminate my vlan group. The different access switches are connected to the core directly. In the core we are not enforced by the vendor to have uniqueness on the vlan name.
adam commented 2025-12-29 19:40:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 25, 2022):

Removing the uniqueness constraint from VLAN groups would undermine their primary purpose and break several established features (such as the automatic provisioning of next-available VLANs), so I have to reject this proposal. If you have multiple VLANs with the same name and/or ID, they simply must be managed in different groups (or consolidated into a single VLAN object). Please consider opening a discussion for help modeling VLANs.

@jeremystretch commented on GitHub (Apr 25, 2022): Removing the uniqueness constraint from VLAN groups would undermine their primary purpose and break several established features (such as the automatic provisioning of next-available VLANs), so I have to reject this proposal. If you have multiple VLANs with the same name and/or ID, they simply must be managed in different groups (or consolidated into a single VLAN object). Please consider opening a [discussion](https://github.com/netbox-community/netbox/discussions/new) for help modeling VLANs.
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#6394
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?