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

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

New Issue
Closed
opened 2025-12-29 17:21:26 +01:00 by adam · 3 comments
adam commented 2025-12-29 17:21:26 +01:00
Owner
Copy Link

Originally created by @JSystem1 on GitHub (Sep 17, 2018).

Environment

  • Python version: v2.6
  • NetBox version: v2.4.2

Steps to Reproduce

Note: All in the same VRF e.g TEST-VRF

  1. Create a container e.g 1.1.1.1/24 & assign VRF
  2. Create a child prefix e.g 1.1.1.0/30
  3. Create the 2 available IP address associated with the 1.1.1.0/30 (1.1.1.1/30 & 1.1.1.2/30)
  4. If you then navigate to the container 1.1.1.0/24 (which we use to get the next available IP address and assign out) the network & broadcast address will be shown as an available IP address which is not correct due to the child prefix of 1.1.1.1/30.
  5. If you then assign 1.1.1.3/30 (from the container view of available IP address) the IP creates which can be seen from the container and the child prefix also (utilization being now 150% from the /30)

capture
capture1

Expected Behavior

What should be expected at the container view is the network/broadcast address should not be shown as available when a child prefix exists that use that IP as there network/broadcast address.

I know this needs to be like this due to a container being in a global VRF table (Which will show you all VRFs within that container) If there can be some sort of option implemented when creating a container when child prefixes are created their network/broadcast address are assumed unusable in the container view and if IP address creation is attempted an error is given

Current solution is to make the child prefix a pool (So it wont show 200% utilization) and reserving the network and broadcast address

Observed Behavior

If this is intended for purposes I am unaware of a recommendation on what way best to bypass the above problem

Originally created by @JSystem1 on GitHub (Sep 17, 2018). <!-- NOTE: 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. --> ### Environment * Python version: v2.6 * NetBox version: v2.4.2 <!-- Describe in detail the steps that someone else can take to reproduce this bug using the current stable release of NetBox (or the current beta release where applicable). --> ### Steps to Reproduce Note: All in the same VRF e.g TEST-VRF 1. Create a container e.g 1.1.1.1/24 & assign VRF 2. Create a child prefix e.g 1.1.1.0/30 3. Create the 2 available IP address associated with the 1.1.1.0/30 (1.1.1.1/30 & 1.1.1.2/30) 4. If you then navigate to the container 1.1.1.0/24 (which we use to get the next available IP address and assign out) the network & broadcast address will be shown as an available IP address which is not correct due to the child prefix of 1.1.1.1/30. 5. If you then assign 1.1.1.3/30 (from the container view of available IP address) the IP creates which can be seen from the container and the child prefix also (utilization being now 150% from the /30) ![capture](https://user-images.githubusercontent.com/22867821/45629129-90f60f00-ba8d-11e8-9ae3-38945d77aad4.PNG) ![capture1](https://user-images.githubusercontent.com/22867821/45629134-94899600-ba8d-11e8-9fd4-e2f12cb715f8.PNG) <!-- What did you expect to happen? --> ### Expected Behavior What should be expected at the container view is the network/broadcast address should not be shown as available when a child prefix exists that use that IP as there network/broadcast address. I know this needs to be like this due to a container being in a global VRF table (Which will show you all VRFs within that container) If there can be some sort of option implemented when creating a container when child prefixes are created their network/broadcast address are assumed unusable in the container view and if IP address creation is attempted an error is given Current solution is to make the child prefix a pool (So it wont show 200% utilization) and reserving the network and broadcast address <!-- What happened instead? --> ### Observed Behavior If this is intended for purposes I am unaware of a recommendation on what way best to bypass the above problem
adam closed this issue 2025-12-29 17:21:26 +01:00
adam commented 2025-12-29 17:21:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 27, 2018):

If you then navigate to the container 1.1.1.0/24 (which we use to get the next available IP address and assign out) the network & broadcast address will be shown as an available IP address which is not correct due to the child prefix of 1.1.1.1/30.

This will happen if you check "is a pool" on the container prefix. Uncheck this field and the IP addresses will be displayed as expected.

Please also note that the latest stable release of NetBox is v2.4.4.

@jeremystretch commented on GitHub (Sep 27, 2018): > If you then navigate to the container 1.1.1.0/24 (which we use to get the next available IP address and assign out) the network & broadcast address will be shown as an available IP address which is not correct due to the child prefix of 1.1.1.1/30. This will happen if you check "is a pool" on the container prefix. Uncheck this field and the IP addresses will be displayed as expected. Please also note that the latest stable release of NetBox is v2.4.4.
adam commented 2025-12-29 17:21:28 +01:00
Author
Owner
Copy Link

@sabintsonev commented on GitHub (Oct 17, 2018):

Netbox Version 2.4.6 - This happens also, when "is a pool" is not checked.

@sabintsonev commented on GitHub (Oct 17, 2018): Netbox Version 2.4.6 - This happens also, when "is a pool" is not checked.
adam commented 2025-12-29 17:21:28 +01:00
Author
Owner
Copy Link

@sabintsonev commented on GitHub (Oct 17, 2018):

“Is pool” is “hidding” only the subnet and the broadcast addresses of the container prefix, not for all child prefixes. Why should someone add IP address from the container view? Probably will be better, when the tab “IP Addresses” is hidden, when the prefix type is container. This of course will not solve all the problems, but will minimise the possibility for a human error.

@sabintsonev commented on GitHub (Oct 17, 2018): “Is pool” is “hidding” only the subnet and the broadcast addresses of the container prefix, not for all child prefixes. Why should someone add IP address from the container view? Probably will be better, when the tab “IP Addresses” is hidden, when the prefix type is container. This of course will not solve all the problems, but will minimise the possibility for a human error.
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#2008
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?