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

Mark utilized not propagated to parent prefixes #5367

New Issue
Closed
opened 2025-12-29 19:27:11 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:27:11 +01:00
Owner
Copy Link

Originally created by @zombah on GitHub (Sep 14, 2021).

Originally assigned to: @zombah on GitHub.

NetBox version

v3.0.2

Python version

3.9

Steps to Reproduce

  1. Create prefix f.e. 192.168.1.0/24 in vrf Global status Active
  2. Create two child prefixes 192.168.1.0/25 and 192.168.1.128/25 in vrf Global status Active
  3. Tick "Mark utilized" for child prefix 192.168.1.128/25
  4. Check prefix 192.168.1.128/25 utilization and parent 192.168.1.0/24 utilization

Expected Behavior

Parent prefix 192.168.1.0/24 utilization 50%

Observed Behavior

Parent prefix 192.168.1.0/24 utilization 0%

Originally created by @zombah on GitHub (Sep 14, 2021). Originally assigned to: @zombah on GitHub. ### NetBox version v3.0.2 ### Python version 3.9 ### Steps to Reproduce 1. Create prefix f.e. 192.168.1.0/24 in vrf Global status Active 2. Create two child prefixes 192.168.1.0/25 and 192.168.1.128/25 in vrf Global status Active 3. Tick "Mark utilized" for child prefix 192.168.1.128/25 4. Check prefix 192.168.1.128/25 utilization and parent 192.168.1.0/24 utilization ### Expected Behavior Parent prefix 192.168.1.0/24 utilization 50% ### Observed Behavior Parent prefix 192.168.1.0/24 utilization 0%
adam added the type: bugstatus: under review labels 2025-12-29 19:27:11 +01:00
adam closed this issue 2025-12-29 19:27:11 +01:00
adam commented 2025-12-29 19:27:11 +01:00
Author
Owner
Copy Link

@zombah commented on GitHub (Sep 15, 2021):

@jeremystretch I volunteer to create fix if you dont mind

@zombah commented on GitHub (Sep 15, 2021): @jeremystretch I volunteer to create fix if you dont mind
adam commented 2025-12-29 19:27:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 16, 2021):

Upon closer inspection, I don't believe this is a bug. The parent prefix (192.168.1.0/24) should have its status set to "container," as it contains child prefixes. Doing so results in the utilization reported as expected.

@jeremystretch commented on GitHub (Sep 16, 2021): Upon closer inspection, I don't believe this is a bug. The parent prefix (192.168.1.0/24) should have its status set to "container," as it contains child prefixes. Doing so results in the utilization reported as expected.
adam commented 2025-12-29 19:27:12 +01:00
Author
Owner
Copy Link

@zombah commented on GitHub (Sep 16, 2021):

@jeremystretch Oh i see, but then it may lead to some frustration if used without container.
Maybe we can treat it as not fix, but as small addition to mark_utilized function?
I think it will make good company for container status and wil not break overall logic scheme
and i see no visible drawbacks.
I imagine it can be used for granular utilization documentation there prefix known to be fully used
but no need to add all ip's except gateway assigned to interface for example or some mixed
mode there you turn container to active to check it's utilization on child ip,range and prefix base.

@zombah commented on GitHub (Sep 16, 2021): @jeremystretch Oh i see, but then it may lead to some frustration if used without container. Maybe we can treat it as not fix, but as small addition to mark_utilized function? I think it will make good company for container status and wil not break overall logic scheme and i see no visible drawbacks. I imagine it can be used for granular utilization documentation there prefix known to be fully used but no need to add all ip's except gateway assigned to interface for example or some mixed mode there you turn container to active to check it's utilization on child ip,range and prefix base.
adam commented 2025-12-29 19:27:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 17, 2021):

Oh i see, but then it may lead to some frustration if used without container.

Why would you not simply set the status to container?

@jeremystretch commented on GitHub (Sep 17, 2021): > Oh i see, but then it may lead to some frustration if used without container. Why would you not simply set the status to container?
adam commented 2025-12-29 19:27:12 +01:00
Author
Owner
Copy Link

@zombah commented on GitHub (Sep 17, 2021):

Why would you not simply set the status to container?

Yes container is solid solution, but there is coner cases where it may be useful to use
active for prefix which have child prefixes.

For example one host from large prefix moved within small specific prefix to other device, so
original large prefix still have active status role, but in netbox topology it looks like contrainer now
because there is child prefix.

Main thing i like in this that it gives possibility to document more precise utilization
for container prefix, maybe having two utilization counters for container is another way to go, treat all
childs prefixes as utilized as it is now and second counter which counts child ip's,range's and mark_utilized prefixes as
active prefix will do?

@zombah commented on GitHub (Sep 17, 2021): > Why would you not simply set the status to container? Yes container is solid solution, but there is coner cases where it may be useful to use active for prefix which have child prefixes. For example one host from large prefix moved within small specific prefix to other device, so original large prefix still have active status role, but in netbox topology it looks like contrainer now because there is child prefix. Main thing i like in this that it gives possibility to document more precise utilization for container prefix, maybe having two utilization counters for container is another way to go, treat all childs prefixes as utilized as it is now and second counter which counts child ip's,range's and mark_utilized prefixes as active prefix will do?
adam commented 2025-12-29 19:27:13 +01:00
Author
Owner
Copy Link

@zombah commented on GitHub (Sep 21, 2021):

@jeremystretch I noticed there is issue #6606 which can theoretically
compensate extra lookup on active prefix with on demand utilization counting.
Is that a more proper solution?
I can try to create PR for #6606 with this feature merged inside.

@zombah commented on GitHub (Sep 21, 2021): @jeremystretch I noticed there is issue #6606 which can theoretically compensate extra lookup on active prefix with on demand utilization counting. Is that a more proper solution? I can try to create PR for #6606 with this feature merged inside.
adam commented 2025-12-29 19:27:13 +01:00
Author
Owner
Copy Link

@zombah commented on GitHub (Sep 22, 2021):

After more thinking and experementation i agree, this is not needed functionality, container is definitly enough.
So i close this issue and it's pr.

@zombah commented on GitHub (Sep 22, 2021): After more thinking and experementation i agree, this is not needed functionality, container is definitly enough. So i close this issue and it's pr.
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: under review 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#5367
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?