starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 22:03:32 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

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

New Issue
Closed
opened 2025-12-29 21:30:34 +01:00 by adam · 9 comments
adam commented 2025-12-29 21:30:34 +01:00
Owner
Copy Link

Originally created by @Azmodeszer on GitHub (Oct 16, 2024).

Originally assigned to: @thordreier on GitHub.

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

Originally created by @Azmodeszer on GitHub (Oct 16, 2024). Originally assigned to: @thordreier on GitHub. ### 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](https://github.com/user-attachments/assets/efb8a950-0a56-46b3-92e5-5b7bbe0f18ae)
adam added the type: bugstatus: acceptednetboxseverity: low labels 2025-12-29 21:30:34 +01:00
adam closed this issue 2025-12-29 21:30:34 +01:00
adam commented 2025-12-29 21:30:34 +01:00
Author
Owner
Copy Link

@cs-1 commented on GitHub (Oct 17, 2024):

I can confirm that we see the same behaviour.

@cs-1 commented on GitHub (Oct 17, 2024): I can confirm that we see the same behaviour.
adam commented 2025-12-29 21:30:35 +01:00
Author
Owner
Copy Link

@thordreier commented on GitHub (Oct 30, 2024):

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: ee1de42607

@thordreier commented on GitHub (Oct 30, 2024): 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: https://github.com/thordreier/netbox/commit/ee1de426074a28672fbc082f99348891a5df302d
adam commented 2025-12-29 21:30:35 +01:00
Author
Owner
Copy Link

@salfers commented on GitHub (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.

@salfers commented on GitHub (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.
adam commented 2025-12-29 21:30:35 +01:00
Author
Owner
Copy Link

@thordreier commented on GitHub (Nov 5, 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.

That was also the first implentation in https://github.com/netbox-community/netbox/pull/17662 - but it was decided to change it.

@thordreier commented on GitHub (Nov 5, 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. That was also the first implentation in https://github.com/netbox-community/netbox/pull/17662 - but it was decided to change it.
adam commented 2025-12-29 21:30:35 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Nov 13, 2024):

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?

@jsenecal commented on GitHub (Nov 13, 2024): > See this commit: [thordreier@ee1de42](https://github.com/thordreier/netbox/commit/ee1de426074a28672fbc082f99348891a5df302d) @thordreier would you be open to have this issue assigned to you and open a PR since you seem to already have the fix?
adam commented 2025-12-29 21:30:35 +01:00
Author
Owner
Copy Link

@thordreier commented on GitHub (Nov 13, 2024):

@jsenecal yeah, that's fine

@thordreier commented on GitHub (Nov 13, 2024): @jsenecal yeah, that's fine
adam commented 2025-12-29 21:30:35 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Dec 3, 2024):

@thordreier assigned it to you. Thank you.

@arthanson commented on GitHub (Dec 3, 2024): @thordreier assigned it to you. Thank you.
adam commented 2025-12-29 21:30:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 26, 2024):

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

@jeremystretch commented on GitHub (Dec 26, 2024): @thordreier do you still intend to work on this issue?
adam commented 2025-12-29 21:30:36 +01:00
Author
Owner
Copy Link

@thordreier commented on GitHub (Dec 27, 2024):

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

@thordreier commented on GitHub (Dec 27, 2024): Sorry. I forgot about this issue. I've created the pull request now.
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 netbox severity: low status: accepted 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#10370
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?