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

Container prefixes showing Network/Broadcast available of child prefix #3771

New Issue
Closed
opened 2025-12-29 18:31:08 +01:00 by adam · 3 comments
adam commented 2025-12-29 18:31:08 +01:00
Owner
Copy Link

Originally created by @enribla on GitHub (Jun 10, 2020).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.6.8
  • NetBox version: 2.8.5

Steps to Reproduce

  1. Create a prefix container. For example 10.181.90.0/24

  2. Create a child prefix. For example 10.181.90.40/29
    image

  3. Go to the parent prefix 10.181.90.0/24 and go to the tab ip addresses. The ips for the network and broadcast remain available and someone can use them
    image

Expected Behavior

I expect that these ips appears Active with the information of the child prefix or if it-s a conainer it would be perfect if we cannot go direct to the ip addresses

Observed Behavior

he ips for the network and broadcast of the child prefix remain available and someone can use them

This issue was also opened (https://github.com/netbox-community/netbox/issues/2436) but not fixed

Originally created by @enribla on GitHub (Jun 10, 2020). Originally assigned to: @jeremystretch on GitHub. <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for reproducible bugs. If you need assistance with NetBox installation, or if you have a general question, DO NOT open an issue. Instead, post to our mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report, and that any plugins have been disabled. --> ### Environment * Python version: 3.6.8 * NetBox version: 2.8.5 <!-- Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox. Begin with the creation of any necessary database objects and call out every operation being performed explicitly. If reporting a bug in the REST API, be sure to reconstruct the raw HTTP request(s) being made: Don't rely on a client library such as pynetbox. --> ### Steps to Reproduce 1. Create a prefix container. For example 10.181.90.0/24 2. Create a child prefix. For example 10.181.90.40/29 ![image](https://user-images.githubusercontent.com/53942090/84310805-897c7080-ab62-11ea-9a1a-7ce1b39e31ba.png) 3. Go to the parent prefix 10.181.90.0/24 and go to the tab ip addresses. The ips for the network and broadcast remain available and someone can use them ![image](https://user-images.githubusercontent.com/53942090/84310834-9600c900-ab62-11ea-988f-a204cbf6ae74.png) <!-- What did you expect to happen? --> ### Expected Behavior I expect that these ips appears Active with the information of the child prefix or if it-s a conainer it would be perfect if we cannot go direct to the ip addresses <!-- What happened instead? --> ### Observed Behavior he ips for the network and broadcast of the child prefix remain available and someone can use them This issue was also opened (https://github.com/netbox-community/netbox/issues/2436) but not fixed
adam added the status: accepted label 2025-12-29 18:31:08 +01:00
adam closed this issue 2025-12-29 18:31:08 +01:00
adam commented 2025-12-29 18:31:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 15, 2020):

Go to the parent prefix 10.181.90.0/24 and go to the tab ip addresses. The ips for the network and broadcast remain available and someone can use them

This is because, within the context of the prefix being viewed, they are available. If you're using the prefix as a container for other prefixes, you'll need to consider available IPs within each child prefix, rather than from a parent prefix. The "child IP addresses" view has no real significance when viewing a container prefix. (Note that utilization for containers is calculated based on child prefixes, not IP addresses.) Perhaps we should simply hide the tab to avoid confusion.

@jeremystretch commented on GitHub (Jun 15, 2020): > Go to the parent prefix 10.181.90.0/24 and go to the tab ip addresses. The ips for the network and broadcast remain available and someone can use them This is because, within the context of the prefix being viewed, they _are_ available. If you're using the prefix as a container for other prefixes, you'll need to consider available IPs within each child prefix, rather than from a parent prefix. The "child IP addresses" view has no real significance when viewing a container prefix. (Note that utilization for containers is calculated based on child prefixes, not IP addresses.) Perhaps we should simply hide the tab to avoid confusion.
adam commented 2025-12-29 18:31:09 +01:00
Author
Owner
Copy Link

@enribla commented on GitHub (Jun 15, 2020):

Thanks Jeremy for your fast feedback
My point of view is that these ips are not available even from the parent prefix. As you tell: "The "child IP addresses" view has no real significance when viewing a container prefix" So he solution that you propose suits well to avoid mistakes and it looks coherent with the reality. Hiding the tab or giving RO Access from the container parent prefix should be fantastic. Many thanks in advance

@enribla commented on GitHub (Jun 15, 2020): Thanks Jeremy for your fast feedback My point of view is that these ips are not available even from the parent prefix. As you tell: "The "child IP addresses" view has no real significance when viewing a container prefix" So he solution that you propose suits well to avoid mistakes and it looks coherent with the reality. Hiding the tab or giving RO Access from the container parent prefix should be fantastic. Many thanks in advance
adam commented 2025-12-29 18:31:09 +01:00
Author
Owner
Copy Link

@cpbruton commented on GitHub (Aug 19, 2020):

This change really took me by surprise after I upgraded. Very frequently I want to list all IP addresses within a Container prefix. E.g. I have a /20 assigned to a site, with several /24s within it for individual networks. I have the /20 set as a 'Container' prefix and the /24s set as 'Active'. However I often want to see all of the IP addresses within the /20 in one list. Before this change, it was one click to do this. Now it's awkward - I have to go to the IP address search page and type or paste the parent prefix.

My workaround for now is changing my prefixes from 'Container' status to 'Active', but now I lose the utilisation information.

In short I don't feel like this was the correct fix for the OP's reported issue. There are many legitimate reasons one might want to list all IP addresses within a Container prefix.

@cpbruton commented on GitHub (Aug 19, 2020): This change really took me by surprise after I upgraded. Very frequently I want to list all IP addresses within a Container prefix. E.g. I have a /20 assigned to a site, with several /24s within it for individual networks. I have the /20 set as a 'Container' prefix and the /24s set as 'Active'. However I often want to see all of the IP addresses within the /20 in one list. Before this change, it was one click to do this. Now it's awkward - I have to go to the IP address search page and type or paste the parent prefix. My workaround for now is changing my prefixes from 'Container' status to 'Active', but now I lose the utilisation information. In short I don't feel like this was the correct fix for the OP's reported issue. There are many legitimate reasons one might want to list all IP addresses within a Container prefix.
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: accepted
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#3771
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?