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

Utilization Bar #4803

New Issue
Closed
opened 2025-12-29 19:20:47 +01:00 by adam · 3 comments
adam commented 2025-12-29 19:20:47 +01:00
Owner
Copy Link

Originally created by @milalima on GitHub (Apr 22, 2021).

NetBox version

v2.8.7

Python version

3.6

Steps to Reproduce

  1. Click IPAM
  2. Prefixes

image

  1. Click range 240.0.0.0/4

image

It is possible to see that we are not using the 62% is showing on the first page.

62% of the /4 is a /5 (50%) + /7 (12%) - so looks like just allocating them is what makes it show as utilized?

Expected Behavior

It was expected that the percentage should be calculated by the children, however by those ones that are being used at the moment. Though the final number should be based on the child inside the container.

This will make the number drop from 62% to something between 10% and 15%.

Observed Behavior

Wrong utilization number in the bar for the ranges available

Originally created by @milalima on GitHub (Apr 22, 2021). ### NetBox version v2.8.7 ### Python version 3.6 ### Steps to Reproduce 1. Click IPAM 2. Prefixes ![image](https://user-images.githubusercontent.com/48295637/115632437-8f7fc980-a2bc-11eb-8469-3df131f45d7e.png) 3. Click range 240.0.0.0/4 ![image](https://user-images.githubusercontent.com/48295637/115632499-b63e0000-a2bc-11eb-9874-f27e4baa29d5.png) It is possible to see that we are not using the 62% is showing on the first page. 62% of the /4 is a /5 (50%) + /7 (12%) - so looks like just allocating them is what makes it show as utilized? ### Expected Behavior It was expected that the percentage should be calculated by the children, however by those ones that are being used at the moment. Though the final number should be based on the child inside the container. This will make the number drop from 62% to something between 10% and 15%. ### Observed Behavior Wrong utilization number in the bar for the ranges available
adam added the type: bugstatus: revisions needed labels 2025-12-29 19:20:47 +01:00
adam closed this issue 2025-12-29 19:20:47 +01:00
adam commented 2025-12-29 19:20:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 22, 2021):

Two problems:

  1. v2.8.7 is pretty old. We require bug reports to be reproducible on a recent stable release (e.g. NetBox v2.11, or at least v2.10).
  2. You didn't provide steps that someone else can follow to reproduce the reported behavior. Please indicate exactly what prefixes you are creating.
@jeremystretch commented on GitHub (Apr 22, 2021): Two problems: 1. v2.8.7 is pretty old. We require bug reports to be reproducible on a recent stable release (e.g. NetBox v2.11, or at least v2.10). 2. You didn't provide steps that someone else can follow to reproduce the reported behavior. Please indicate exactly what prefixes you are creating.
adam commented 2025-12-29 19:20:48 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Apr 22, 2021):

This is expected (and correct) behaviour.

A "container" prefix contains child prefixes (which themselves may be containers or active). The utilisation of a container prefix reflects the amount of address space allocated to child prefixes.

For example: if you have 192.168.0.0/16 as a container, and underneath that are prefixes 192.168.0.0/24, 192.168.1.0/24 and 192.168.2.0/24, then the container utilisation is 3/256. That's true even if no IP addresses have been allocated within those prefixes. It's telling you how much space is no longer available for allocating child prefixes within the container.

An "active" prefix contains individual IP addresses. The utilisation of such a prefix is the number of individual IP addresses, divided by the size of that prefix (which is reduced by 2 unless the "pool" flag is set)

As you observed: 62% of the space under 240.0.0.0/4 has been allocated to 240.0.0.0/5 and 250.0.0.0/7

Since those prefixes are themselves containers, then the amount of utilisation within 240.0.0.0/5 depends on its child prefixes. But from the point of view of 240.0.0.0/4, the entire range 240.0.0.0/5 has been carved out.

@candlerb commented on GitHub (Apr 22, 2021): This is expected (and correct) behaviour. A "container" prefix contains child prefixes (which themselves may be containers or active). The utilisation of a container prefix reflects the amount of address space allocated to child prefixes. For example: if you have 192.168.0.0/16 as a container, and underneath that are prefixes 192.168.0.0/24, 192.168.1.0/24 and 192.168.2.0/24, then the container utilisation is 3/256. That's true even if no IP addresses have been allocated within those prefixes. It's telling you how much space is no longer available for allocating child prefixes within the container. An "active" prefix contains individual IP addresses. The utilisation of such a prefix is the number of individual IP addresses, divided by the size of that prefix (which is reduced by 2 unless the "pool" flag is set) As you observed: 62% of the space under 240.0.0.0/4 has been allocated to 240.0.0.0/5 and 250.0.0.0/7 Since those prefixes are themselves containers, then the amount of utilisation within 240.0.0.0/5 depends on its child prefixes. But from the point of view of 240.0.0.0/4, the entire range 240.0.0.0/5 has been carved out.
adam commented 2025-12-29 19:20:48 +01:00
Author
Owner
Copy Link

@milalima commented on GitHub (Apr 23, 2021):

Hi @candlerb thanks for the explanation. I will share with the team internally. :)

@milalima commented on GitHub (Apr 23, 2021): Hi @candlerb thanks for the explanation. I will share with the team internally. :)
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 status: revisions needed 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#4803
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?