"Container" prefix for loopbacks no longer shows child IP addresses

[candlerb]

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)

[DanSheps]

Appears it was changed in d5d87e0 5bcf85e

[DanSheps]

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

[leec-666]

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 Container prefixes showing Network/Broadcast available of child prefix #4744 a configurable option - per-prefix or globally? Perhaps it could be displayed when the container is marked as a pool.

[cpbruton]

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.

[leec-666]

another workaround :)

[falz]

A few days ago i had created #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:

• Container prefixes showing Network/Broadcast available of child prefix #4744 'fix' (hiding the ip addresses tab) seemed too large of a hammer to me

• 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. Reserved however says for future use, which was indeed how we were using it previous to this workaround.

My $.02.

[sgips-godaddy]

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.

[github-actions]

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.

[candlerb]

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.