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

vlan group with large ID makes UI crash #18037

Closed
jonkerj opened this issue Nov 18, 2024 · 1 comment · Fixed by #18041
Closed

vlan group with large ID makes UI crash #18037

jonkerj opened this issue Nov 18, 2024 · 1 comment · Fixed by #18041
Assignees
Labels
severity: high Completely breaks certain functions, or substantially degrades performance application-wide status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@jonkerj
Copy link
Contributor

jonkerj commented Nov 18, 2024

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
@jonkerj jonkerj added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Nov 18, 2024
@jonkerj
Copy link
Contributor Author

jonkerj commented 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.

@DanSheps DanSheps added status: accepted This issue has been accepted for implementation severity: high Completely breaks certain functions, or substantially degrades performance application-wide and removed status: needs triage This issue is awaiting triage by a maintainer labels Nov 18, 2024
@DanSheps DanSheps self-assigned this Nov 18, 2024
This was referenced Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: high Completely breaks certain functions, or substantially degrades performance application-wide 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.

2 participants