vlan group with large ID makes UI crash #10486

Closed
opened 2025-12-29 21:32:09 +01:00 by adam · 1 comment
Owner

Originally created by @jonkerj on GitHub (Nov 18, 2024).

Originally assigned to: @DanSheps on GitHub.

Deployment Type

Self-hosted

Triage priority

N/A

NetBox Version

v4.1.6

Python Version

3.12

Steps to Reproduce

  1. deploy netbox (fresh install)
  2. create vlan group with [2, 409411115) as bounds, save
  3. visit /ipam/vlan-groups/

Notes:

  • we deploy Netbox on Kubernetes (using official Helm chart)

Expected Behavior

Get an overview with that vlangroup

Observed Behavior

  • at first, we observed netbox getting killed by kernel cgroup OOM killer (limited by Kubelet to 1.5GiB)
  • when increased to 2GiB, the process just died quietly, without any logging
  • although it's possible to remove the offending VLAN group using the API, it does not remove symptom (crash when visit VLAN group in UI)
  • the problem is finally solved by deleting the offending record form ipam_vlangroup in PostgreSQL
Originally created by @jonkerj on GitHub (Nov 18, 2024). Originally assigned to: @DanSheps on GitHub. ### Deployment Type Self-hosted ### Triage priority N/A ### NetBox Version v4.1.6 ### Python Version 3.12 ### Steps to Reproduce 1. deploy netbox (fresh install) 2. create vlan group with [2, 409411115) as bounds, save 3. visit `/ipam/vlan-groups/` Notes: - we deploy Netbox on Kubernetes (using official Helm chart) ### Expected Behavior Get an overview with that vlangroup ### Observed Behavior - at first, we observed netbox getting killed by kernel cgroup OOM killer (limited by Kubelet to 1.5GiB) - when increased to 2GiB, the process just died quietly, without any logging - although it's possible to remove the offending VLAN group using the API, it does not remove symptom (crash when visit VLAN group in UI) - the problem is finally solved by deleting the offending record form `ipam_vlangroup` in PostgreSQL
adam added the type: bugstatus: acceptedseverity: high labels 2025-12-29 21:32:09 +01:00
adam closed this issue 2025-12-29 21:32:10 +01:00
Author
Owner

@jonkerj commented on GitHub (Nov 18, 2024):

My (uneducated) guess is the UI request causes something to enumerate all possible VLANs in memory, in an attempt to check if they exist at all.

Shortest workaround would be to implement a validator that does not allow >=4096 VIDs. This would rule out the usage of VLAN groups for more general (ie, VNI) usage. We will implement a custom validator in the meanwhile to prevent our users from entering these.

@jonkerj commented on GitHub (Nov 18, 2024): My (uneducated) guess is the UI request causes something to enumerate all possible VLANs in memory, in an attempt to check if they exist at all. Shortest workaround would be to implement a validator that does not allow >=4096 VIDs. This would rule out the usage of VLAN groups for more general (ie, VNI) usage. We will implement a custom validator in the meanwhile to prevent our users from entering these.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10486