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 non-unique VLAN names within a VLAN group #7556

New Issue
Closed
opened 2025-12-29 20:25:13 +01:00 by adam · 6 comments
adam commented 2025-12-29 20:25:13 +01:00
Owner
Copy Link

Originally created by @kochargs on GitHub (Jan 25, 2023).

NetBox version

v3.4.2

Feature type

Change to existing functionality

Proposed functionality

Vlans with same names should be allowed under same vlangroup.
I could get around this by not assigning vlans to a vlangroup
or
by using tags instead

but any other workaround makes me lose the amazing view I get with vlangroups that shows

  1. vlan ranges for the specific group
  2. utilization report of vlans that belong to each group.

I understand certain vendors do not allow same vlan name but understand that we could be

  1. multi vendor
  2. vlans with different vlan IDs but same name might exist on different switches within the same site.
  3. People have been used of documenting information in excel sheets and I want to be able to make it super easy for them to transition to netbox without asking them to go and make the vlan names unique in their excel sheets and then in the network ( which is almost impossible to accomplish in a short span and hence makes selling netbox equally difficult )

Use case

The intention is to get my NOC team to stop using offline excel vlan databases and promote the usage of netbox which allows me to interface better with tools like ansible tower etc. Bring all the network information into netbox making it the source of truth for my network as a code goal.

Database changes

models.uniqueconstraints

remove the constraint over name to be unique.

External dependencies

None

Originally created by @kochargs on GitHub (Jan 25, 2023). ### NetBox version v3.4.2 ### Feature type Change to existing functionality ### Proposed functionality Vlans with same names should be allowed under same vlangroup. I could get around this by not assigning vlans to a vlangroup or by using tags instead but any other workaround makes me lose the amazing view I get with vlangroups that shows 1. vlan ranges for the specific group 2. utilization report of vlans that belong to each group. I understand certain vendors do not allow same vlan name but understand that we could be 1. multi vendor 2. vlans with different vlan IDs but same name might exist on different switches within the same site. 3. People have been used of documenting information in excel sheets and I want to be able to make it super easy for them to transition to netbox without asking them to go and make the vlan names unique in their excel sheets and then in the network ( which is almost impossible to accomplish in a short span and hence makes selling netbox equally difficult ) ### Use case The intention is to get my NOC team to stop using offline excel vlan databases and promote the usage of netbox which allows me to interface better with tools like ansible tower etc. Bring all the network information into netbox making it the source of truth for my network as a code goal. ### Database changes models.uniqueconstraints remove the constraint over name to be unique. ### External dependencies None
adam added the type: featurepending closurestatus: under review labels 2025-12-29 20:25:13 +01:00
adam closed this issue 2025-12-29 20:25:13 +01:00
adam commented 2025-12-29 20:25:14 +01:00
Author
Owner
Copy Link

@kochargs commented on GitHub (Jan 25, 2023):

#9968

@kochargs commented on GitHub (Jan 25, 2023): #9968
adam commented 2025-12-29 20:25:14 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Jan 27, 2023):

This is a good ask because I too have to do this in our infra. I'm currently forced to append the VLAN name in the DB with a number which in reality does not get applied to the network devices. Just to make NetBox happy, we have to add the ugly hack which sort of breaks the reason we use NetBox. This was done because we already had the network in place and other automation tools before NetBox in into the picture. To change this is a significant effort at the moment and hence the ugly change.

If this can be accepted, I can submit the PR to remove the constraint from the code.

@abhi1693 commented on GitHub (Jan 27, 2023): This is a good ask because I too have to do this in our infra. I'm currently forced to append the VLAN name in the DB with a number which in reality does not get applied to the network devices. Just to make NetBox happy, we have to add the ugly hack which sort of breaks the reason we use NetBox. This was done because we already had the network in place and other automation tools before NetBox in into the picture. To change this is a significant effort at the moment and hence the ugly change. If this can be accepted, I can submit the PR to remove the constraint from the code.
adam commented 2025-12-29 20:25:14 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Feb 3, 2023):

For me that is totally not a go. My layer2 domain has to have unique names (Juniper vlans are based on names, with the ID as a parameter).
Either you have to define separate vlan groups per site, so that you can use the same vlan name again.
If that is not possible, and this is a requirement for you, then it has to be a non-default checkbox that has to be set on the vlan-group. (similar to the IP uniqueness on the vrf)

@PieterL75 commented on GitHub (Feb 3, 2023): For me that is totally not a go. My layer2 domain has to have unique names (Juniper vlans are based on names, with the ID as a parameter). Either you have to define separate vlan groups per site, so that you can use the same vlan name again. If that is not possible, and this is a requirement for you, then it has to be a non-default checkbox that has to be set on the vlan-group. (similar to the IP uniqueness on the vrf)
adam commented 2025-12-29 20:25:15 +01:00
Author
Owner
Copy Link

@patrickpreuss commented on GitHub (Feb 12, 2023):

Also do not see the requirement.
Most NOCs i am aware construct unique set of VLAN IDs and NAMES per Site/Domain/VRFs/Tennant.
Maybe you can give some example/reasoning why this useful?

@patrickpreuss commented on GitHub (Feb 12, 2023): Also do not see the requirement. Most NOCs i am aware construct unique set of VLAN IDs and NAMES per Site/Domain/VRFs/Tennant. Maybe you can give some example/reasoning why this useful?
adam commented 2025-12-29 20:25:15 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 15, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 15, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:25:20 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 15, 2023):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jul 15, 2023): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure 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#7556
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?