Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
matheuskshn opened this issue Apr 25, 2024 · 4 comments
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available type: bug A confirmed report of unexpected behavior in the application

Comments

@matheuskshn
Copy link

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.

@matheuskshn matheuskshn added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Apr 25, 2024
@arthanson arthanson added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation severity: low Does not significantly disrupt application functionality, or a workaround is available and removed status: needs triage This issue is awaiting triage by a maintainer labels Apr 26, 2024
@arthanson arthanson removed their assignment Apr 26, 2024
@arthanson arthanson added status: under review Further discussion is needed to determine this issue's scope and/or implementation and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation labels Apr 26, 2024
@arthanson
Copy link
Collaborator

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

@matheuskshn
Copy link
Author

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.

@jeremystretch jeremystretch added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels May 28, 2024
@arthanson
Copy link
Collaborator

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

@matheuskshn
Copy link
Author

Yes, that solved it, thanks!

@jeremystretch jeremystretch removed the status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation label Jun 19, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

3 participants