Prefix in different VRF wrongly sees global prefix as its parent

[candlerb]

NetBox version

v3.4.4

Python version

3.8

Steps to Reproduce

1. Create VRF "testvrf"
2. Create prefix 192.168.0.0/24 in global VRF
3. Create prefix 192.168.0.0/28 in "testvrf"
4. Browse to 192.168.0.0/28 (which is where you'll be right after creation)

Expected Behavior

192.168.0.0/28@testvrf and 192.168.0.0/24 should be independent from each other, as they are in different VRFs.

Observed Behavior

192.168.0.0/28@testvrf sees 192.168.0.0/24 as its parent.

However, 192.168.0.0/24 does not see 192.168.0.0/28@testvrf as its child.

This is inconsistent: this child<->parent relationship should either work in both ways, or neither.

In this case, I think it should be neither: otherwise 192.168.0.0/24 could see many different prefixes and IP addresses in different VRFs as its children, which would mix lots of VRFs together in the same view.

EDIT: the current behaviour does appear to be intentional in the code:

        # Parent prefixes table
        parent_prefixes = Prefix.objects.restrict(request.user, 'view').filter(
            Q(vrf=instance.vrf) | Q(vrf__isnull=True)

[jsenecal]

The current behavior is indeed intentional. This allows for Container prefixes in the Global VRF to nest under it smaller prefixes in the table views.

Can you clarify what you would like fixed in that case, if anything ?

[candlerb]

If A is the parent of B, then B should be the child of A. This isn't the case currently.

If you want to make a container prefix for prefixes in VRF X, then the container should also be within VRF X (IMO).

[bobbwest]

Worse still, if there are two 192.168.0.0/24 prefixes, one in global, one in the VRF "testvrf", which one would be the parent of 192.168.0.0/28@testvrf ? Both? It should be the one in the same VRF.

VRFs are separate routing domains; there's no reason for a prefix in global to show up in a VRF. In the rare cases when route leaking is happening between VRFs, then I think that the prefix should be listed in each VRF with a note as to how it is appearing there.

[DanSheps]

The current behavior is indeed intentional. This allows for Container prefixes in the Global VRF to nest under it smaller prefixes in the table views.

Can you clarify what you would like fixed in that case, if anything ?

It is only suppose to work this way if it is set as "Container" for status.