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

Failure to Select Tagged VLANs on Interfaces When Associated with Groups Scoped to Cluster #9537

New Issue
Closed
opened 2025-12-29 20:51:08 +01:00 by adam · 4 comments
adam commented 2025-12-29 20:51:08 +01:00
Owner
Copy Link

Originally created by @matheuskshn on GitHub (Apr 25, 2024).

Deployment Type

Self-hosted

NetBox Version

v3.7.6

Python Version

3.10

Steps to Reproduce

  1. Creating the VLAN:

    • Go to the VLAN management section in Netbox.
    • Create a new VLAN.

  2. Associating the VLAN to a VLAN Group:

    • Add the newly created VLAN to an existing VLAN group or create a new group for it.

  3. Setting the Scope:

    • Configure the scope of the VLAN group to 'Cluster' or 'Cluster Group'.

  4. Adding a New Interface:

    • Navigate to 'Device Components' and select the relevant device.
    • Add a new interface to this device.
    • Specify the appropriate Interface Type.

  5. Configuring VLAN on the Interface:

    • In the '802.1Q Mode' field, select 'Tagged'.
    • Attempt to add the VLAN configured in the previous steps to the 'Tagged VLANs' field.

  6. Checking VLAN Availability:

    • Observe that the VLAN associated with the group scoped to 'Cluster' or 'Cluster Group' does not appear available for selection in the 'Tagged VLANs' field.

Expected Behavior

When configuring an interface in Netbox in 'Tagged' mode, it is expected that all VLANs should be selectable in the 'Tagged VLANs' field, regardless of the scope of the group to which they belong. VLANs should appear in the selection list provided that the device associated with the interface is included in the same Cluster or Cluster Group as the VLAN group configured. This ensures uniform and consistent behavior across all group scopes, including 'Cluster' and 'Cluster Group'.

Observed Behavior

Currently, when configuring an interface in 'Tagged' mode in Netbox, VLANs belonging to a group scoped to Cluster or Cluster Group do not appear as selectable options in the 'Tagged VLANs' field. This issue persists even when the device associated with the interface belongs to the same Cluster or Cluster Group as the VLAN group. This results in inconsistency in VLAN management, limiting system functionality in setting up interfaces in specific network environments.

Originally created by @matheuskshn on GitHub (Apr 25, 2024). ### Deployment Type Self-hosted ### NetBox Version v3.7.6 ### Python Version 3.10 ### Steps to Reproduce 1. **Creating the VLAN:** - Go to the VLAN management section in Netbox. - Create a new VLAN. 2. **Associating the VLAN to a VLAN Group:** - Add the newly created VLAN to an existing VLAN group or create a new group for it. 3. **Setting the Scope:** - Configure the scope of the VLAN group to 'Cluster' or 'Cluster Group'. 4. **Adding a New Interface:** - Navigate to 'Device Components' and select the relevant device. - Add a new interface to this device. - Specify the appropriate Interface Type. 5. **Configuring VLAN on the Interface:** - In the '802.1Q Mode' field, select 'Tagged'. - Attempt to add the VLAN configured in the previous steps to the 'Tagged VLANs' field. 6. **Checking VLAN Availability:** - Observe that the VLAN associated with the group scoped to 'Cluster' or 'Cluster Group' does not appear available for selection in the 'Tagged VLANs' field. ### Expected Behavior When configuring an interface in Netbox in 'Tagged' mode, it is expected that all VLANs should be selectable in the 'Tagged VLANs' field, regardless of the scope of the group to which they belong. VLANs should appear in the selection list provided that the device associated with the interface is included in the same Cluster or Cluster Group as the VLAN group configured. This ensures uniform and consistent behavior across all group scopes, including 'Cluster' and 'Cluster Group'. ### Observed Behavior Currently, when configuring an interface in 'Tagged' mode in Netbox, VLANs belonging to a group scoped to Cluster or Cluster Group do not appear as selectable options in the 'Tagged VLANs' field. This issue persists even when the device associated with the interface belongs to the same Cluster or Cluster Group as the VLAN group. This results in inconsistency in VLAN management, limiting system functionality in setting up interfaces in specific network environments.
adam added the type: bugseverity: low labels 2025-12-29 20:51:08 +01:00
adam closed this issue 2025-12-29 20:51:08 +01:00
adam commented 2025-12-29 20:51:09 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Apr 26, 2024):

I believe this is by design, tagged vlans are matched on the following:
scope_type=ContentType.objects.get_by_natural_key('dcim', 'region'),
scope_type=ContentType.objects.get_by_natural_key('dcim', 'sitegroup'),
scope_type=ContentType.objects.get_by_natural_key('dcim', 'site'),
scope_type=ContentType.objects.get_by_natural_key('dcim', 'location'),
scope_type=ContentType.objects.get_by_natural_key('dcim', 'rack'),
They are not matched on Cluster or ClusterGroup

@arthanson commented on GitHub (Apr 26, 2024): I believe this is by design, tagged vlans are matched on the following: scope_type=ContentType.objects.get_by_natural_key('dcim', 'region'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'sitegroup'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'site'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'location'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'rack'), They are not matched on Cluster or ClusterGroup
adam commented 2025-12-29 20:51:09 +01:00
Author
Owner
Copy Link

@matheuskshn commented on GitHub (May 5, 2024):

Acredito que isso seja por design, os vlans marcados são combinados no seguinte: scope_type=ContentType.objects.get_by_natural_key('dcim', 'region'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'sitegroup'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'site'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'location'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'rack'), Eles não são correspondidos no Cluster ou no ClusterGroup

I appreciate the information regarding the current behavior of Netbox concerning the selection of tagged VLANs associated with groups scoped to Cluster or Cluster Group. However, I would like to draw attention to a related issue that may be impacting this functionality, as described in issue #15119.

Currently, although it is possible to define the scope of VLAN groups for Cluster or Cluster Group, the Netbox interface does not support filtering VLAN groups by these scopes. This limitation may be directly related to the problem we are facing here, where VLANs in groups with these scopes do not appear as selectable options when configuring interfaces in Tagged mode.

@matheuskshn commented on GitHub (May 5, 2024): > Acredito que isso seja por design, os vlans marcados são combinados no seguinte: scope_type=ContentType.objects.get_by_natural_key('dcim', 'region'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'sitegroup'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'site'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'location'), scope_type=ContentType.objects.get_by_natural_key('dcim', 'rack'), Eles não são correspondidos no Cluster ou no ClusterGroup I appreciate the information regarding the current behavior of Netbox concerning the selection of tagged VLANs associated with groups scoped to Cluster or Cluster Group. However, I would like to draw attention to a related issue that may be impacting this functionality, as described in issue #15119. Currently, although it is possible to define the scope of VLAN groups for Cluster or Cluster Group, the Netbox interface does not support filtering VLAN groups by these scopes. This limitation may be directly related to the problem we are facing here, where VLANs in groups with these scopes do not appear as selectable options when configuring interfaces in Tagged mode.
adam commented 2025-12-29 20:51:10 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Jun 18, 2024):

@matheuskshn #15119 has been fixed. Does this address your issue?

@arthanson commented on GitHub (Jun 18, 2024): @matheuskshn #15119 has been fixed. Does this address your issue?
adam commented 2025-12-29 20:51:10 +01:00
Author
Owner
Copy Link

@matheuskshn commented on GitHub (Jun 19, 2024):

Yes, that solved it, thanks!

@matheuskshn commented on GitHub (Jun 19, 2024): Yes, that solved it, thanks!
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 severity: low 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#9537
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?