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

Strange behaviour with generated >3 VLANs table for interfaces #17771

Closed
Azmodeszer opened this issue Oct 16, 2024 · 9 comments · Fixed by #18274
Closed

Strange behaviour with generated >3 VLANs table for interfaces #17771

Azmodeszer opened this issue Oct 16, 2024 · 9 comments · Fixed by #18274
Assignees
Labels
netbox severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@Azmodeszer
Copy link
Contributor

Azmodeszer commented Oct 16, 2024

Deployment Type

Self-hosted

Triage priority

N/A

NetBox Version

v4.1.4

Python Version

3.11

Steps to Reproduce

I'm seeing some weird behaviour with the new feature as implemented per #17655. I can't give exact guaranteed reproduction steps, because it might be something specific to my database that I haven't figured out yet, but basically:

  1. Find an interface with more than 3 tagged VLANs and 1 untagged VLAN. (created before the update(?), see Observed Behavior)
  2. Click on the created link for the tagged VLANs (of the form /ipam/vlans/?interface_id=<ID>).

Expected Behavior

Tagged VLANs for that interface are shown correctly.

Observed Behavior

What I am seeing is some of the tagged VLANs being listed multiple times (and the untagged VLAN showing up as well, which I guess is to be expected). I've tried to reproduce it with new VLANs created after the update to 4.1.4 and it seems to work as expected with those (some "older" VLANs are also only showing up once, however, so it might not be related to that at all), but when I attach a certain existing VLAN as tagged to the interface it results in multiple redundant rows again.

image

@Azmodeszer Azmodeszer added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Oct 16, 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 Oct 16, 2024
@cs-1
Copy link

cs-1 commented Oct 17, 2024

I can confirm that we see the same behaviour.

@thordreier
Copy link
Contributor

If only Q(interfaces_as_tagged=value) or Q(interfaces_as_untagged=value) is used, it looks fine. But both combined messes up the joins. The query ends being:

SELECT
"ipam_vlan"."id", "ipam_vlan"."created", "ipam_vlan"."last_updated", "ipam_vlan"."custom_field_data",
"ipam_vlan"."description", "ipam_vlan"."comments", "ipam_vlan"."site_id", "ipam_vlan"."group_id",
"ipam_vlan"."vid", "ipam_vlan"."name", "ipam_vlan"."tenant_id", "ipam_vlan"."status", "ipam_vlan"."role_id"
FROM "ipam_vlan"
LEFT OUTER JOIN "dcim_interface_tagged_vlans" ON ("ipam_vlan"."id" = "dcim_interface_tagged_vlans"."vlan_id")
LEFT OUTER JOIN "dcim_interface" T4 ON ("ipam_vlan"."id" = T4."untagged_vlan_id")
WHERE ("dcim_interface_tagged_vlans"."interface_id" = 385 OR T4."id" = 385)
ORDER BY "ipam_vlan"."vid" ASC;

If and "dcim_interface_tagged_vlans"."interface_id" = 385 is added to the first JOIN the result looks fine - but I don't know how to do that in Django.

But a solution seems is to add distinct (in netbox/ipam/filtersets.py):

        return queryset.filter(
            Q(interfaces_as_tagged=value) |
            Q(interfaces_as_untagged=value)
        ).distinct()

See this commit: thordreier@ee1de42

@jeremystretch jeremystretch added the netbox label Nov 1, 2024 — with Linear
@salfers
Copy link

salfers commented Nov 4, 2024

Couldn't the link just go to the interface page and focus the VLAN table? I don't see why it has to go to the VLAN list + filter there.

@thordreier
Copy link
Contributor

Couldn't the link just go to the interface page and focus the VLAN table? I don't see why it has to go to the VLAN list + filter there.

That was also the first implentation in #17662 - but it was decided to change it.

@jsenecal
Copy link
Contributor

See this commit: thordreier@ee1de42

@thordreier would you be open to have this issue assigned to you and open a PR since you seem to already have the fix?

@thordreier
Copy link
Contributor

@jsenecal yeah, that's fine

@arthanson arthanson added status: accepted This issue has been accepted for implementation and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation labels Dec 3, 2024
@arthanson
Copy link
Collaborator

@thordreier assigned it to you. Thank you.

@jeremystretch
Copy link
Member

@thordreier do you still intend to work on this issue?

@thordreier
Copy link
Contributor

Sorry. I forgot about this issue. I've created the pull request now.

This was referenced Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
netbox severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants