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" prefix for loopbacks no longer shows child IP addresses #4624

New Issue
Closed
opened 2025-12-29 18:38:24 +01:00 by adam · 10 comments
adam commented 2025-12-29 18:38:24 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Mar 4, 2021).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.6.9
  • NetBox version: 2.10.5

Steps to Reproduce

I have a "Container" prefix from which loopbacks are allocated. If I go to the loopback address, it shows its parent prefix. But if I go to the parent prefix, I don't see the child IPs.

  1. Create prefix 1.2.3.0/24 with status "Container", "is a pool"
  2. Create IP address 1.2.3.0/32, role "Loopback"
  3. Create IP address 1.2.3.1/32, role "Loopback"
  4. Create IP address 1.2.3.2/32, role "Loopback"
  5. Under "Parent prefixes" you'll see 1.2.3.0/24; navigate to this

Expected Behavior

Under the parent prefix, I expected to see the child IPs and utilisation. (I think that some time ago, it did)

Observed Behavior

No child IPs seen, and utilisation remains at 0%

Workaround

Change the prefix status to "Reserved". Child IPs are now seen, and utilisation shows as 1%.

(Not "Active", because it isn't an actual subnet on an interface)

Originally created by @candlerb on GitHub (Mar 4, 2021). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.6.9 * NetBox version: 2.10.5 ### Steps to Reproduce I have a "Container" prefix from which loopbacks are allocated. If I go to the loopback address, it shows its parent prefix. But if I go to the parent prefix, I don't see the child IPs. 1. Create prefix 1.2.3.0/24 with status "Container", "is a pool" 2. Create IP address 1.2.3.0/32, role "Loopback" 3. Create IP address 1.2.3.1/32, role "Loopback" 3. Create IP address 1.2.3.2/32, role "Loopback" 4. Under "Parent prefixes" you'll see 1.2.3.0/24; navigate to this ### Expected Behavior Under the parent prefix, I expected to see the child IPs and utilisation. (I think that some time ago, it did) ### Observed Behavior No child IPs seen, and utilisation remains at 0% ### Workaround Change the prefix status to "Reserved". Child IPs are now seen, and utilisation shows as 1%. (Not "Active", because it isn't an actual subnet on an interface)
adam added the status: acceptedtype: feature labels 2025-12-29 18:38:24 +01:00
adam closed this issue 2025-12-29 18:38:24 +01:00
adam commented 2025-12-29 18:38:24 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 4, 2021):

Appears it was changed in d5d87e0fdd 5bcf85e57d

@DanSheps commented on GitHub (Mar 4, 2021): Appears it was changed in ~~d5d87e0fdd4a297cea5385432054d54f649cd5a4~~ 5bcf85e57d72fca70064ab2c49290b62cbfecb50
adam commented 2025-12-29 18:38:24 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 4, 2021):

Personally, I think the "Reserved" workaround is the way to go with this one, but not sure.

@DanSheps commented on GitHub (Mar 4, 2021): Personally, I think the "Reserved" workaround is the way to go with this one, but not sure.
adam commented 2025-12-29 18:38:25 +01:00
Author
Owner
Copy Link

@leec-666 commented on GitHub (Mar 17, 2021):

Noticed the same today. The workaround feels dirty and I agree with @cpbruton in #4744. Could it be an acceptable solution to keep everyone happy to either

  • have a loopback container prefix type
  • display the IP addresses tab when a container prefix contains IPs of role Loopback
  • make #4744 a configurable option - per-prefix or globally? Perhaps it could be displayed when the container is marked as a pool.
@leec-666 commented on GitHub (Mar 17, 2021): Noticed the same today. The workaround feels dirty and I agree with @cpbruton in #4744. Could it be an acceptable solution to keep everyone happy to either - have a loopback container prefix type - display the IP addresses tab when a container prefix contains IPs of role Loopback - make #4744 a configurable option - per-prefix or globally? Perhaps it could be displayed when the container is marked as a pool.
adam commented 2025-12-29 18:38:25 +01:00
Author
Owner
Copy Link

@cpbruton commented on GitHub (Mar 17, 2021):

Thanks for tagging me @chonty. A few things to add:

  • As another workaround option, the original human and API endpoints are still available. The change was cosmetic only. E.g. visiting /ipam/prefixes/xxx/ip-addresses/ still shows the list of addresses even for Container prefixes; it doesn't produce an error. (note I'm still on v2.9.9, haven't checked this in the latest)
  • Setting prefixes as Reserved or Active brings the link back on the prefix page, but it also changes how the Utilization is calculated. In a Container prefix, the entire child prefix counts toward utilization, whereas in Reserved or Active, only used addresses count. There would be no difference if your Container only contains loopback prefixes (/32), but it's noticeable if you have a container of larger prefixes.
  • Automatically choosing to display the link based on loopback or pool status wouldn't work for me - because my use case doesn't involve loopbacks or pools. I have Containers with /24 child prefixes that are not pools. I would prefer either a configurable option per-prefix or globally or some more advanced logic to decide.
@cpbruton commented on GitHub (Mar 17, 2021): Thanks for tagging me @chonty. A few things to add: - As another workaround option, the original human and API endpoints are still available. The change was cosmetic only. E.g. visiting /ipam/prefixes/xxx/ip-addresses/ still shows the list of addresses even for Container prefixes; it doesn't produce an error. (note I'm still on v2.9.9, haven't checked this in the latest) - Setting prefixes as Reserved or Active brings the link back on the prefix page, but it also changes how the Utilization is calculated. In a Container prefix, the entire child prefix counts toward utilization, whereas in Reserved or Active, only used addresses count. There would be no difference if your Container only contains loopback prefixes (/32), but it's noticeable if you have a container of larger prefixes. - Automatically choosing to display the link based on loopback or pool status wouldn't work for me - because my use case doesn't involve loopbacks or pools. I have Containers with /24 child prefixes that are not pools. I would prefer either a configurable option per-prefix or globally or some more advanced logic to decide.
adam commented 2025-12-29 18:38:26 +01:00
Author
Owner
Copy Link

@leec-666 commented on GitHub (Mar 17, 2021):

another workaround :)

image

@leec-666 commented on GitHub (Mar 17, 2021): another workaround :) ![image](https://user-images.githubusercontent.com/20431435/111468789-0ab00600-877a-11eb-80f2-93859bdb07ea.png)
adam commented 2025-12-29 18:38:26 +01:00
Author
Owner
Copy Link

@falz commented on GitHub (Apr 27, 2021):

A few days ago i had created https://github.com/netbox-community/netbox/issues/6260 about this, and it was pointed out that mine is a duplicate of this, so closing it. See that case for my use case, which appears to be pretty similar to this one (loopbacks in a prefix).

I've just tested the 'Reserved' workaround and it does work here, so it seems like we have to go with that for now. A few additional thoughts:

My $.02.

@falz commented on GitHub (Apr 27, 2021): A few days ago i had created https://github.com/netbox-community/netbox/issues/6260 about this, and it was pointed out that mine is a duplicate of this, so closing it. See that case for my use case, which appears to be pretty similar to this one (loopbacks in a prefix). I've just tested the 'Reserved' workaround and it does work here, so it seems like we have to go with that for now. A few additional thoughts: * https://github.com/netbox-community/netbox/issues/4744 'fix' (hiding the ip addresses tab) seemed too large of a hammer to me * Perhaps [the documentation could use updating](https://netbox.readthedocs.io/en/stable/models/ipam/prefix/)? It does properly say that a Container is for child prefix, but it seems easy to miss that it is *not* for IP addresses. Reserved however says for future use, which was indeed how we *were* using it previous to this workaround. My $.02.
adam commented 2025-12-29 18:38:26 +01:00
Author
Owner
Copy Link

@sgips-godaddy commented on GitHub (Jun 12, 2021):

Personally, I think the "Reserved" workaround is the way to go with this one, but not sure.

I disagree.
As far as I can tell prefixes of type "Active" or "Reserved" calculate the utilization based on the IP addresses within the prefix whereas a prefix of type "Container" calculates it based of the child prefixes. To me this is a huge difference (based on my own individual use case).
I would prefer having the "IP Addresses" tab back for "Container" prefixes.

@sgips-godaddy commented on GitHub (Jun 12, 2021): > Personally, I think the "Reserved" workaround is the way to go with this one, but not sure. I disagree. As far as I can tell prefixes of type "Active" or "Reserved" calculate the utilization based on the IP addresses within the prefix whereas a prefix of type "Container" calculates it based of the child prefixes. To me this is a huge difference (based on my own individual use case). I would prefer having the "IP Addresses" tab back for "Container" prefixes.
adam commented 2025-12-29 18:38:27 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 12, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Aug 12, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:38:27 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Sep 1, 2021):

Perhaps the documentation could use updating? It does properly say that a Container is for child prefix, but it seems easy to miss that it is not for IP addresses

Regardless of the intention (documented or not), there is no logic in NetBox which enforces the invariant that "IPs cannot exist directly inside Container Prefixes". As a result, if you create an IP inside a Container, it apparently vanishes in the GUI - i.e. you cannot navigate to it, unless you happen to know it exists and search for it directly. It doesn't even count towards prefix utilisation, so you have no indication that it exists. That's not good.

In any case, such an invariant would be difficult to enforce correctly, given that IPs can exist outside any prefix; prefixes can have their status changed; sub-prefixes can be inserted and removed which sit between outer prefixes and IPs, etc etc.

The simple solution is simply to revert the change and allow browsing child IPs within container prefixes.

It would also be possible be to do a DB query to determine if there are any direct child IPs and display the tab only if there are, but that could be an expensive query for a large container prefix.

@candlerb commented on GitHub (Sep 1, 2021): > Perhaps the documentation could use updating? It does properly say that a Container is for child prefix, but it seems easy to miss that it is not for IP addresses Regardless of the intention (documented or not), there is no logic in NetBox which enforces the invariant that "IPs cannot exist directly inside Container Prefixes". As a result, if you create an IP inside a Container, it apparently vanishes in the GUI - i.e. you cannot navigate to it, unless you happen to know it exists and search for it directly. It doesn't even count towards prefix utilisation, so you have no indication that it exists. That's not good. In any case, such an invariant would be difficult to enforce correctly, given that IPs can exist outside any prefix; prefixes can have their status changed; sub-prefixes can be inserted and removed which sit between outer prefixes and IPs, etc etc. The simple solution is simply to revert the change and allow browsing child IPs within container prefixes. It would also be possible be to do a DB query to determine if there are any direct child IPs and display the tab only if there are, but that could be an expensive query for a large container prefix.
adam commented 2025-12-29 18:38:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 1, 2021):

It seems that the consensus here is to simply always show the "IP Addresses" tab for a prefix, regardless of its status, which I think is reasonable.

@jeremystretch commented on GitHub (Oct 1, 2021): It seems that the consensus here is to simply always show the "IP Addresses" tab for a prefix, regardless of its status, which I think is reasonable.
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 type: feature
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#4624
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?