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

Utilization Improvements #24

New Issue
Closed
opened 2025-12-29 15:29:54 +01:00 by adam · 5 comments
adam commented 2025-12-29 15:29:54 +01:00
Owner
Copy Link

Originally created by @Gelob on GitHub (Jun 27, 2016).

I'd like to see some improvements to the utilization measurements.

  1. The utilization bar should be shown not only under aggregate but under each Prefix and Child Prefix.
    This helps with the fact that currently the aggregate view will show 100% if you have completely subnetted out that aggregate prefix. This is nice but its not a real accurate representation of that utilization.
  2. I'd like to see an option where you could change the above to either show the utilization based off of the aggregate utilization of the prefixes rather than if you have subnetted the aggregate.

This can be annoying if you make an aggregate prefix called 192.168.0.0/21. Carve up two prefixes 192.168.0.0/22 and 192.168.4.0/22 because one will be for SITE1 and the other for SITE2. Mark those both containers. Now, my /21 shows 100% utilization because I've made containers to contain my child prefixes of 192.168.0.0/24 and 192.168.4.0/24, etc.

Originally created by @Gelob on GitHub (Jun 27, 2016). I'd like to see some improvements to the utilization measurements. 1. The utilization bar should be shown not only under aggregate but under each Prefix and Child Prefix. This helps with the fact that currently the aggregate view will show 100% if you have completely subnetted out that aggregate prefix. This is nice but its not a real accurate representation of that utilization. 2. I'd like to see an option where you could change the above to either show the utilization based off of the aggregate utilization of the prefixes rather than if you have subnetted the aggregate. This can be annoying if you make an aggregate prefix called 192.168.0.0/21. Carve up two prefixes 192.168.0.0/22 and 192.168.4.0/22 because one will be for SITE1 and the other for SITE2. Mark those both containers. Now, my /21 shows 100% utilization because I've made containers to contain my child prefixes of 192.168.0.0/24 and 192.168.4.0/24, etc.
adam closed this issue 2025-12-29 15:29:54 +01:00
adam commented 2025-12-29 15:29:56 +01:00
Author
Owner
Copy Link

@65156 commented on GitHub (Jul 8, 2016):

Yep nicely said!

@65156 commented on GitHub (Jul 8, 2016): Yep nicely said!
adam commented 2025-12-29 15:29:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 13, 2016):

This can be annoying if you make an aggregate prefix called 192.168.0.0/21. Carve up two prefixes 192.168.0.0/22 and 192.168.4.0/22 because one will be for SITE1 and the other for SITE2. Mark those both containers. Now, my /21 shows 100% utilization because I've made containers to contain my child prefixes of 192.168.0.0/24 and 192.168.4.0/24, etc.

I strongly prefer this behavior. It shows that the parent /21 has been fully allocated and there there is no unallocated portion of it remaining. The alternative would be to display a parent with only empty children as 0% allocated. This would be very confusing from a high-level view.

For example, suppose I define a /24 and within it 64 individual /30 prefixes representing point-to-point links. The /24 is for all purposes fully allocated, even though none of its children have IP addresses or child prefixes.

I think we're dealing with two slightly different concepts of utilization, one being the allocation of address space and the other being its provisioning. The key might lie in counting only active prefixes for the later.

@jeremystretch commented on GitHub (Jul 13, 2016): > This can be annoying if you make an aggregate prefix called 192.168.0.0/21. Carve up two prefixes 192.168.0.0/22 and 192.168.4.0/22 because one will be for SITE1 and the other for SITE2. Mark those both containers. Now, my /21 shows 100% utilization because I've made containers to contain my child prefixes of 192.168.0.0/24 and 192.168.4.0/24, etc. I strongly prefer this behavior. It shows that the parent /21 has been fully allocated and there there is no unallocated portion of it remaining. The alternative would be to display a parent with only empty children as 0% allocated. This would be very confusing from a high-level view. For example, suppose I define a /24 and within it 64 individual /30 prefixes representing point-to-point links. The /24 is for all purposes fully allocated, even though none of its children have IP addresses or child prefixes. I think we're dealing with two slightly different concepts of utilization, one being the _allocation_ of address space and the other being its _provisioning_. The key might lie in counting only active prefixes for the later.
adam commented 2025-12-29 15:29:57 +01:00
Author
Owner
Copy Link

@65156 commented on GitHub (Jul 14, 2016):

I suggest the following:

Aggregates - In addition to an Allocated Prefix Utilization function, another Utilization Field Summarizing Utilized IP addresses within the Aggregate (Summary of Utilization across all Prefixes within that Aggregate)

Prefixes - Add an Utilization Field to see available IP's within a defined Prefix

This will be more comprehensive and provide better reporting for people using this to monitor network devices or 10000's of customers, not just silo this as a high level network documentation tool.

@65156 commented on GitHub (Jul 14, 2016): I suggest the following: Aggregates - In addition to an Allocated Prefix Utilization function, another Utilization Field Summarizing Utilized IP addresses within the Aggregate (Summary of Utilization across all Prefixes within that Aggregate) Prefixes - Add an Utilization Field to see available IP's within a defined Prefix This will be more comprehensive and provide better reporting for people using this to monitor network devices or 10000's of customers, not just silo this as a high level network documentation tool.
adam commented 2025-12-29 15:29:57 +01:00
Author
Owner
Copy Link

@hellbringer commented on GitHub (Jul 27, 2016):

Yes! Summary of Utilization per prefix would be very helpful! I think for that to work there needs to be a flag per IP 'active' yes/no (or like with prefix: active / reserved / free / depricated)

@hellbringer commented on GitHub (Jul 27, 2016): Yes! Summary of Utilization per prefix would be very helpful! I think for that to work there needs to be a flag per IP 'active' yes/no (or like with prefix: active / reserved / free / depricated)
adam commented 2025-12-29 15:29:57 +01:00
Author
Owner
Copy Link

@zachmoody commented on GitHub (Aug 30, 2016):

@jeremystretch Made a quick patch that adds a configuration item where you can list the child prefix statuses you might want to exclude from the aggregate's utilization percentage. I'll make a PR if that's something you're interested in merging.

@zachmoody commented on GitHub (Aug 30, 2016): @jeremystretch Made a quick patch that adds a configuration item where you can list the child prefix statuses you might want to exclude from the aggregate's utilization percentage. I'll make a PR if that's something you're interested in merging.
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
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#24
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?