IP Prefix in VRF showing in all parent global container prefixes as well as master prefix list

[DanSheps]

Environment

• Python version: 3.4
• NetBox version: 2.3.7

Prefixes that are within a global container also visible on the main prefix list page, as well as subsequent child prefix lists within a prefix.

Related: #1073

Steps to Reproduce

1. Create a IP Prefix in the Global as a container: 10.0.0.0/8
2. Create a IP Prefix in the Global as a any status: 192.16.0.0/16
3. Create a Child IP Prefix of 10.0.0.0/8 in the Global as a container: 10.0.0.0/16
4. Create a Child IP Prefix of 10.0.0.0/8 in the Global as a active: 10.1.0.0/16
5. Create a Child IP Prefix of 10.0.0.0/16 in VRF as a active network: 10.0.0.0/24
6. Create a Child IP Prefix of 10.0.0.0/16 in VRF as a active network: 10.1.0.0/24
7. Create a Child IP Prefix of 10.0.0.0/16 in VRF as a container network: 10.0.1.0/24
8. Create a Child IP Prefix of 10.1.0.0/24 in VRF as a active network: 10.1.0.0/25
9. Create a Child IP Prefix of 10.1.0.0/16 in VRF as a active network: 10.1.1.0/24

Expected Behavior

• 10.0.0.0/24 visible as a child of 10.0.0.0/16
• 10.1.0.0/24 visible as a child of 10.0.0.0/16
• 10.1.0.0/25 visible as a child of 10.1.0.0/24

Observed Behavior

Prefix 10.0.0.0/24 is visible in (incorrect):

• The main prefix list page (/ipam/prefixes) (incorrect)
• 10.0.0.0/8 Child Prefixes (incorrect)
• 10.0.0.0/16 Child Prefixes (correct)

Prefix 10.1.0.0/24 is visible in:

• The main prefix list page (/ipam/prefixes) (incorrect)
• 10.0.0.0/8 Child Prefixes (incorrect)
• 10.0.0.0/16 Child Prefixes (correct)

Prefix 10.1.0.0/25 is visible in (this behaviour is correct, just included as a test case):

• 10.1.0.0/24 child prefixes (correct)

[DanSheps]

I am unable to recreate as was originally posted.

I am able to recreate this by importing my prefixes from production onto development. Further information, this looks like it is related to the amount of prefixes in the database.

I will slowly add prefixes and see where it errors out.

[DanSheps]

Edited test case, should now be able to reproduce.

Import(s) for prefixes:

prefix,vrf,tenant,site,vlan_group,vlan_vid,status,role,is_pool,description 10.0.0.0/8,,,,,,Container,,, 10.0.0.0/16,,,,,,Container,,, 10.1.0.0/16,,,,,,Container,,, 192.168.0.0/16,,,,,,Container,,, 10.0.0.0/24,1:1,,,,,Active,,, 10.0.1.0/24,1:1,,,,,Active,,, 10.1.0.0/24,1:1,,,,,Container,,, 10.1.0.0/25,1:1,,,,,Active,,, 10.1.1.0/24,1:1,,,,,Active,,,

Imports for VRFs:

name,rd,tenant,enforce_unique,description Test,1:1,,,

[DanSheps]

Screenshots

Observed:

Expected:

[DanSheps]

Looks like this might be related to #1073

Root cause appears to be annotate_depth as annotate depth expects the next prefix to either be a child prefix or a new prefix and when something gets in the way between two child prefixes, it breaks.

[DanSheps]

I did some work on this, and discovered that the fix isn't as easy as I originally thought, It does hide the prefix, but it also hides the prefix if it is in a different VRF, so there will need some logic added to check for that, which is where I think it was failing before.

[DanSheps]

I can confirm that this is still a bug.

I will be starting work on this shortly

[jeremystretch]

@DanSheps What is the status of this?

[jeremystretch]

After speaking with @DanSheps, I don't think it's feasible to address this efficiently given the current logic in place for determining the IP prefix hierarchy. I'm going to close this out, and hope to revisit the issue once we have a better performing solution in place for calculating nested prefix depth.

[vladsol]

So, at this moment is it not possible to display nested subnets in different VRF display as child with respect to global container?
Earlier we used phpipam, and there the hierarchy of networks was very convenient.
In netbox, this is more complicated :) In this case, it is probably easier to completely abandon the use of VRF.

[DukeNuke3D]

Hi developers!
Imagine the following - we have contiguous IPv6 /32 prefix. Next we slice it into peaces and assign child prefixes to different security zones, locations. projects and VRFs - these are all containers. This result in deep hierarchy of address plan and in netbox last lowest-level /64 assignments will be shown apart from top-level containers. This would make sense in IPv4, but it looks weird for IPv6 since all the address space is flat.
I hope I described the problem clearly, if needed I could show screenshots with actual address plan example.