Include VRF-assigned child prefixes when viewing a global container prefix

[martink2]

The recent change introduced a behavioral change in the way GLOBAL
prefixes relate to child prefixes in named VRF's.

Before the change sub-prefixes in any VRF were treated as child from the global parent.
After the change only child prefixes from within the same VRF (Global and named) are considered child prefixes.

From a pure technical routing table perspective the global VRF is only normal VRF
without a name. But from a ipam perspective there is a different definition of Global
in the sense of globally unique prefix.

Especially for the type container, which is not a "real" routable entity but a bucket for
organisational purposes the pure routing table interpretation is maybe too strict.
Valid use-cases for globally unique prefixes are buckets for sub-allocations
like Router-ID's or Transit Networks, where the bucket is created to group a larger
range for the purpose of sub-allocating as needed across VRF's while maintaining
an overview of the bucket usage. Another reason
would be BGP-L3VPN route-leaking where prefixes are expected to be present
in multiple VRF's, which should be reflected in the IPAM, since they are not the same
range in different VRF's but truly the same entity in all VRF's.

Except of simply reverting to the old behavior I could imagine the following
approaches to the problem:

1. Treat type Container and vrf GLOBAL is globally unique as a convention
2. Introduce a flag on a prefix marking it as globally unique irrespective of the VRF it is defined in
3. Treat all containers as cross vrf parents

My personal vote would go to 2. As 1. would introduce a major behavioral change based
on an attribute combination for only a single combination of attributes. 3. would remove
the ability to have a container which is on purpose only valid within a given VRF.

[jeremystretch]

I think you're conflating uniqueness with address space. Whether or not a prefix is unique is dependent entirely upon whether it has been defined multiple times within a table, regardless of how many instances there are of it across different tables.

The concern you brought up in #1067 was that child prefixes in VRFs that are covered by a container prefix in the global table were not being displayed as children. For example, if you had:

• 10.0.0.0/8 - Global (container)
• 10.1.0.0/16 - VRF A
• 10.2.0.0/16 - VRF B
• 10.3.0.0/16 - VRF C

When you view 10.0.0.0/8, you want to see the children from all VRFs as well, correct? There are inevitably going to be contexts where this is and is not desirable, but I think making the exception for prefixes defined as containers is a good compromise.

[martink2]

True maybe i was trying to package too much into a single feature.
Yes my expectation would be that your example would indeed list
10.1/16,10.2/16 and 10.3/16 as child of 10/8.

However to be more precise I would also expect given the following:

• 10.0.0.0/8 - VRF A (Container)
• 10.1.0.0/16 - VRF A
• 10.2.0.0/16 - VRF B
• 10.3.0.0/16 - VRF A

That a container in Global is encapsulating al sub-prefixes regardless of sub-prefix VRF where as containers belonging to a named VRF is only in relation to sub-prefixes in his own VRF.

• 10.0.0.0/8
  • 10.1.0.0/16
  • 10.3.0.0/16
• 10.2.0.0/16

So the point i was trying to make was the question if the combination Global + Container
treated as a special case for child-parent relationship is a desired behavior or
if a separate flag signifying a global uniqueness has an effect on a prefix depending
on the prefix type, example:

Type Container + Flag unique: Shows all sub-prefixes in any VRF as child.
Type not Container + Flag unique: Results in an error if a user is trying to define the same prefix in any other VRF.

For the second example the question would be shall any sub-prefix of a globally unique prefix be automatically treated as globally unique?

For my specific use-case which was affected by the recent change i would be
very happy with the special case container you proposed.

[jeremystretch]

As I said, this has nothing to do with uniqueness. There's no need to add a flag to the model for this. The question is simply whether to include VRF-assigned prefixes when displaying the children of a container prefix in the global table.

[martink2]

Hi @jeremystretch thanks for taking a look into the issue. In the latest version (2.2.9) i can now correctly see all children regardless of the VRF in the child prefixes tab. As far as i can see there
are still two little inconsistencies, although i might be wrong and it is intended behaviour:

1. in the prefix list the VRF children are still shown as individual prefixes and not children:
   

2. The Utilisation of the parent container only counts the utilisation of sub-prefixes in the global VRF

[nikkytub]

Hi @jeremystretch and @martink2 I made some minor changes based on issue-1073 and pushed them recently which you can see here sapcc@a5f6149 It has solved the utilization problem and now prefixes are ordered in the prefix list view on the basis of parent child relationship. Here I wanted to add one more functionality in the Prefix list view which should be similar to what we see once we click on an individual parent prefix which in case of VRF 'Global' and status 'Container' shows all the child prefixes irrespective of their VRF's by taking its primary key. And in case of parent prefix with VRF 'A' and status 'Container' shows only child prefixes associated to that VRF only which is 'A' in this case. I found two ways to implement it either we could make the change in IPAM/querysets.py which is currently using stack.pop() to remove the last element from the list in the while loop which I found a bit cumbersome and I need @jeremystretch advice or either if we could find a way to apply conditional expressions in class Meta in ordering in IPAM/models.py under class Prefix which I couldn't find in Django's documentation. I found we can use 'when' 'then' in filtering the queryset for instance but not inside Class Meta ordering. Please look into the matter. Thanks.

[nbaillie]

Hi, all.
I just started to look using netbox in this way.

Im running version v2.3.3 and looks like its not grouping in the prefix top level page, or doing the utilisation as i would expect.

Might be im trying this all wrong, but wanted to check if this is expected.

it can see the childs though in Child Prefixes under the prefix.

[DanSheps]

Going to close this out, discussion can continue under #2562