starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-12 05:20:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

VLAN selection on device port is limited to the device 'Site' Vlan groups #5431

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

Originally created by @PieterL75 on GitHub (Sep 28, 2021).

NetBox version

v3.0.3

Python version

3.7

Steps to Reproduce

Create the following items
Site groups

  • MyCompany
    • Country1
    • Country2

Sites

  • Site1 (Group Country1)
  • Site2 (Group Country2)

My Vlan groups

  • L2domain1 (site group MyCompany)

My devices

  • device1 (site1)
  • device2 (site2)

create vlan 100 in the L2Domain1 Vlan group
create an interfaces on the device1 and device2

Configure the interface of device1 for 802.1Q
Mode: access
VlanGroup: L2domain1
Untagged vlan: vlan100

Expected Behavior

Per the documentation :

Variable Scope Support for VLAN Groups (#5284)
In previous releases, VLAN groups could be assigned only to a site. To afford more flexibility in conveying the true scope of an L2 domain, a VLAN group can now be assigned to a region, site group (new in v2.11), site, location, or rack. VLANs assigned to a group will be available only to devices and virtual machines which exist within its scope. For example, a VLAN within a group assigned to a location will be available only to devices assigned to that location (or one of its child locations), or to a rack within that location.

I should able to select the VLAN Group L2domain and a vlan out of that group and assign it to the interface.

Observed Behavior

The UI allows me to select the VLAN Group and the vlan, but when saving, I get the message
The untagged VLAN (VLAN100 (100)) must belong to the same site as the interface's parent device, or it must be global

To me, it seems that the GroupSite behaviour is not extended to the check of valid vlans on an interface.
This goes for both Tagged and Access vlans

I think these checks should be extended, so that if the vlan belongs to a vlangroup with a scope 'SiteGroup', it also allows all the devices that are in the sites within that group

df8b76127e/netbox/dcim/forms.py (L151)
38172b793b/netbox/dcim/models/device_components.py (L603)

Originally created by @PieterL75 on GitHub (Sep 28, 2021). ### NetBox version v3.0.3 ### Python version 3.7 ### Steps to Reproduce Create the following items Site groups - MyCompany - Country1 - Country2 Sites - Site1 (Group Country1) - Site2 (Group Country2) My Vlan groups - L2domain1 (site group MyCompany) My devices - device1 (site1) - device2 (site2) create vlan 100 in the L2Domain1 Vlan group create an interfaces on the device1 and device2 Configure the interface of device1 for 802.1Q Mode: access VlanGroup: L2domain1 Untagged vlan: vlan100 ### Expected Behavior Per the documentation : **Variable Scope Support for VLAN Groups (#5284)** `In previous releases, VLAN groups could be assigned only to a site. To afford more flexibility in conveying the true scope of an L2 domain, a VLAN group can now be assigned to a region, site group (new in v2.11), site, location, or rack. VLANs assigned to a group will be available only to devices and virtual machines which exist within its scope. For example, a VLAN within a group assigned to a location will be available only to devices assigned to that location (or one of its child locations), or to a rack within that location.` I should able to select the VLAN Group L2domain and a vlan out of that group and assign it to the interface. ### Observed Behavior The UI allows me to select the VLAN Group and the vlan, but when saving, I get the message `The untagged VLAN (VLAN100 (100)) must belong to the same site as the interface's parent device, or it must be global` To me, it seems that the GroupSite behaviour is not extended to the check of valid vlans on an interface. This goes for both Tagged and Access vlans I think these checks should be extended, so that if the vlan belongs to a vlangroup with a scope 'SiteGroup', it also allows all the devices that are in the sites within that group https://github.com/netbox-community/netbox/blob/df8b76127e20276b534af72d73f7b9951a7c68eb/netbox/dcim/forms.py#L151 https://github.com/netbox-community/netbox/blob/38172b793b3fa51025187901a8302d5503d64c33/netbox/dcim/models/device_components.py#L603
adam added the type: bugstatus: revisions needed labels 2025-12-29 19:27:53 +01:00
adam closed this issue 2025-12-29 19:27:53 +01:00
adam commented 2025-12-29 19:27:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 28, 2021):

I wasn't able to reproduce this on v3.0.3. The VLAN was assigned to the interface successfully as expected.

@jeremystretch commented on GitHub (Sep 28, 2021): I wasn't able to reproduce this on v3.0.3. The VLAN was assigned to the interface successfully as expected.
adam commented 2025-12-29 19:27:54 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 29, 2021):

I concur, please revise your steps so we can reproduce this.

@DanSheps commented on GitHub (Sep 29, 2021): I concur, please revise your steps so we can reproduce this.
adam commented 2025-12-29 19:27:54 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Sep 29, 2021):

Damn.. I really tested this through and through....
but with the data I had in my netbox, and (even tough you always say we have to) not in a clean install...

So I compared with the data in de demo.netbox.dev (someone created the objects there :-) )
In my netbox

  • the VLAN Group is has a scope of SiteGroup, and set to 'MyCompany'
  • But the VLANs in that group had an assignment to a 'Site' and a 'VlanGroup'

I suppose that is because the VLANGroup and VLANs were created before the 'Scope' feature was introduced.

After I changed the VLAN Group Scope to 'Site Group' and assigned it only to the VlanGroup, removing all 'site' references, I was able to add the VLAN to the interfaces...

I do think that the GUI on the VLAN 'Assignment' is a but unclear, but I'll post that in a discussion.

Thank you for taking time to investigate.
I'll do some python scripting to remove the 'site' values from the vlans that are in a group..

Pieter

@PieterL75 commented on GitHub (Sep 29, 2021): Damn.. I really tested this through and through.... but with the data I had in my netbox, and (even tough you always say we have to) not in a clean install... So I compared with the data in de demo.netbox.dev (someone created the objects there :-) ) In my netbox - the VLAN Group is has a scope of SiteGroup, and set to 'MyCompany' - But the VLANs in that group had an assignment to a 'Site' and a 'VlanGroup' I suppose that is because the VLANGroup and VLANs were created before the 'Scope' feature was introduced. After I changed the VLAN Group Scope to 'Site Group' and assigned it only to the VlanGroup, removing all 'site' references, I was able to add the VLAN to the interfaces... I do think that the GUI on the VLAN 'Assignment' is a but unclear, but I'll post that in a discussion. Thank you for taking time to investigate. I'll do some python scripting to remove the 'site' values from the vlans that are in a group.. Pieter
adam commented 2025-12-29 19:27:54 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 29, 2021):

Thanks for the update @PieterL75

@DanSheps commented on GitHub (Sep 29, 2021): Thanks for the update @PieterL75
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: revisions needed type: bug
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#5431
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?