IPAM nesting bug - showing false positive

[Jeffrey-FB]

Deployment Type

Self-hosted

NetBox Version

v4.3.0

Python Version

3.11

Steps to Reproduce

create a IPAM prefix container for 10.100.0.0/15
Then a container 10.100.0.0/16
Then a container 10.100.241.0/24
Then create a vrf for 10.100.241.0/29
and 10.100.241.8/29

Expected Behavior

10.100.241.0/29 and 10.100.241.8/29 show show as stepped on the prefix page as a child of 10.100.241.0/24
e.g.
--10.100.241.0/24
---10.100.241.0/29
---10.100.241.8/29

The /29 should show as child prefixes in the /24 'Child Prefix' tab

Observed Behavior

the /29 do not step on the IPAM -> Prefix menu
But they do show in the 'Child Prefixes' in the tab of 10.100.241.0/24
the 10.100.241.0/24 container Utilization also shows 0.0% even though it say it has Child Prefixes
As per images attached.

I have tried changing the container /24 to active all this seems to do is remove all the child /29 from it.
And the same applies if i try change the status of the /29's they just remove themselves as a child prefix from the /24

Is there a way to fix this, can I gather some extra info to help resolve this for us?
Thanks

[kyerlasswell]

Your container prefixes aren't in the same VRF as your /29s.

The whole hierarchy you created needs to be in the VRF you made; they default to the Global VRF otherwise.

IPAM > Prefixes list:

Child prefixes of 10.100.241.0/24 in the custom VRF:

[Jeffrey-FB]

Aah, I see.
The /29 's are the isc's for each vrf, which is why 10.100.241.0/24 is in global.
So I'm using 10.100.0.0/15 for our region (Also Global) and then we break it down to /18, /20, /22, /24 from there.
And assign those to the vrf's

Guess there is no way around that?
e.g. Instead of using Global for the /15 is there a way to place it for a region so that all the 10.100.0.0/15 will fall in there.
Everything seems to show up in the Child Prefixes for the /15.
It was just more an aesthetic thing so everything nests nicely.

[kyerlasswell]

Logically, those networks are separate from any network in the Global VRF just like they are separate from any other VRF. So while it is more verbose, any prefix + its parents/containers should also be separated by VRF:

10.100.0.0/15         (Custom VRF)
| 10.100.0.0/15       (Custom VRF)
| | 10.100.241.0/24   (Custom VRF)
| | | 10.100.241.0/29 (Custom VRF)
| | | 10.100.241.8/29 (Custom VRF)

By doing this, the containers for each VRF will sit beside each other and properly nest everything in their respective VRFs. If each region has its own VRF, you would just create a new top-level for each region.

10.100.0.0/15         (First VRF)
| 10.100.0.0/16       (First VRF)
| | 10.100.241.0/24   (First VRF)
| | | 10.100.241.0/29 (First VRF)
| | | 10.100.241.8/29 (First VRF)
10.100.0.0/15         (Second VRF)
| 10.100.0.0/15       (Second VRF)
| | 10.100.242.0/24   (Second VRF)
| | | 10.100.242.0/29 (Second VRF)
| | | 10.100.241.8/29 (Second VRF)

[Jeffrey-FB]

All those vrf's are for 1 site for 1 region.
We've designed it like this to meet security requirements.

We would use a different /15 for another region. e.g. 10.40.0.0/15

If we take the range I provided in the original ticket.
This is what I was hoping to achieve

10.100.0.0/15 (Site CIDR)
| 10.100.0.0/16 (First VRF)
| | 10.100.20.0/22 (First VRF)
| | 10.100.30.0/24 (First VRF)
| | | 10.100.241.0/29 (First VRF)
| | 10.100.50.0/22 (Second VRF)
| | 10.100.60.0/24 (Second VRF)
| | | 10.100.241.8/29 (Second VRF)
And Repeat for remaining VRFs

Would something like this be possible?

[cliveandrades]

We are experiencing similar structuring problem

I understand that from a router and security perspective below structure is correct.

10.100.0.0/15 (First VRF)
| 10.100.0.0/16 (First VRF)
| | 10.100.241.0/24 (First VRF)
| | | 10.100.241.0/29 (First VRF)
| | | 10.100.241.8/29 (First VRF)
10.100.0.0/15 (Second VRF)
| 10.100.0.0/15 (Second VRF)
| | 10.100.242.0/24 (Second VRF)
| | | 10.100.242.0/29 (Second VRF)
| | | 10.100.241.8/29 (Second VRF)

But from a subnetting perspective below structure makes sense

10.100.0.0/15 (Site CIDR)
| 10.100.0.0/16 (First VRF)
| | 10.100.20.0/22 (First VRF)
| | 10.100.30.0/24 (First VRF)
| | | 10.100.241.0/29 (First VRF)
| | 10.100.50.0/22 (Second VRF)
| | 10.100.60.0/24 (Second VRF)
| | | 10.100.241.8/29 (Second VRF)

When we link a Scope Type > Site DCIM and Site to these prefixes, we get the following representation. Organisation> Sites > Site name > Prefixes.

10.100.0.0/15 (First VRF)
| 10.100.0.0/16 (First VRF)
| | 10.100.241.0/24 (First VRF)
| | | 10.100.241.0/29 (First VRF)
| | | 10.100.241.8/29 (First VRF)
10.100.0.0/15 (Second VRF)
| 10.100.0.0/15 (Second VRF)
| | 10.100.242.0/24 (Second VRF)
| | | 10.100.242.0/29 (Second VRF)
| | | 10.100.241.8/29 (Second VRF)

When we go to IPAM > prefixes, the structure makes no sense because of the way prefixes are listed as per VRFs Global (default if vrf is unassigned) then numerically. This breaks the representation of parent child structure in terms of simple subnetting example

what it should look likr (convenient, easy to understand and plan)
10.100.0.0/15 (Site CIDR)
| 10.100.0.0/16 (First VRF)
| | 10.100.20.0/22 (First VRF)
| | 10.100.30.0/24 (First VRF)
| | | 10.100.241.0/29 (First VRF)
| | 10.100.50.0/22 (Second VRF)
| | 10.100.60.0/24 (Second VRF)
| | | 10.100.241.8/29 (Second VRF)

what it looks like currently
10.100.0.0/15 (First VRF)
| 10.100.0.0/16 (First VRF)
| | 10.100.20.0/22 (First VRF)
| | 10.100.30.0/24 (First VRF)
| | | 10.100.241.0/29 (First VRF)
172.168.0.0/15 (First VRF)
| 172.168.0.0/16 (First VRF)
| | 172.168.0.0/24 (First VRF)
192.168.0.0/15 (First VRF)
| 192.168.0.0/16 (First VRF)
| | 192.168.0.0/24 (First VRF)
| 10.100.50.0/22 (Second VRF)
| | 10.100.60.0/24 (Second VRF)
| | | 10.100.241.8/29 (Second VRF)

What it means is if a site is not associated with a child subnet regardless of what its VRF is, its going to let lost in the list of prefixes and prefixes do not have simple subnet listing.

This will lead to a complicated prefix list, specifically for environments that use multiple IP ranges example 192, 172, 10....

This also means we need to create multiple parent CIDR blocks with different VRFs which adds to the complexity and ultimately managing the prefixes becomes an administration issue.

Thus an option to switch to below parent-child entity relation regardless of VRFs will be handy.

10.100.0.0/15 (Site CIDR)
| 10.100.0.0/16 (First VRF)
| | 10.100.20.0/22 (First VRF)
| | 10.100.30.0/24 (First VRF)
| | | 10.100.241.0/29 (First VRF)
| | 10.100.50.0/22 (Second VRF)
| | 10.100.60.0/24 (Second VRF)
| | | 10.100.241.8/29 (Second VRF)

[Jeffrey-FB]

Yeah, I understand what you're saying and that's what we have implemented.
But it still comes down to you'd had to have a separate /24 for each vrf even though we only using a /29.
It's a waste to use a whole /24 for 8 addresses.
As we want 10.100.241.0/24 as the container for all our /29 's.
And you cannot link multiple vrf's to a container, would be nice if this was possible for a container only.

Thanks for the detailed explanation @cliveandrades

[arthanson]

@Jeffrey-FB It sounds like this isn't a bug if I'm reading this correctly as per Kyler's comment. Converting this to a discussion.