starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

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

New Issue
Closed
opened 2025-12-29 16:26:24 +01:00 by adam · 7 comments
adam commented 2025-12-29 16:26:24 +01:00
Owner
Copy Link

Originally created by @martink2 on GitHub (Apr 12, 2017).

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.

Originally created by @martink2 on GitHub (Apr 12, 2017). The recent [change](https://github.com/digitalocean/netbox/commit/d89314a559a887484e2fd8e5985bb1b2cdf8777f#diff-4f32f0b261822fd085a875ffb8a16bacR423) 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.
adam added the status: acceptedtype: feature labels 2025-12-29 16:26:24 +01:00
adam closed this issue 2025-12-29 16:26:24 +01:00
adam commented 2025-12-29 16:26:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 12, 2017):

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.

@jeremystretch commented on GitHub (Apr 12, 2017): 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.
adam commented 2025-12-29 16:26:25 +01:00
Author
Owner
Copy Link

@martink2 commented on GitHub (Apr 12, 2017):

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.

@martink2 commented on GitHub (Apr 12, 2017): 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.
adam commented 2025-12-29 16:26:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 18, 2017):

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.

@jeremystretch commented on GitHub (Apr 18, 2017): 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.
adam commented 2025-12-29 16:26:25 +01:00
Author
Owner
Copy Link

@martink2 commented on GitHub (Jan 31, 2018):

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:
    image

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

@martink2 commented on GitHub (Jan 31, 2018): 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: ![image](https://user-images.githubusercontent.com/1143193/35647090-bea9a4f4-06d1-11e8-97d9-a223dfe041f6.png) 2) The Utilisation of the parent container only counts the utilisation of sub-prefixes in the global VRF
adam commented 2025-12-29 16:26:26 +01:00
Author
Owner
Copy Link

@nikkytub commented on GitHub (Feb 9, 2018):

Hi @jeremystretch and @martink2 I made some minor changes based on issue-1073 and pushed them recently which you can see here a5f61497f3 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.

@nikkytub commented on GitHub (Feb 9, 2018): Hi @jeremystretch and @martink2 I made some minor changes based on issue-1073 and pushed them recently which you can see here https://github.com/sapcc/netbox/commit/a5f61497f37470f8dc0dd126708abb140771b4af 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.
adam commented 2025-12-29 16:26:26 +01:00
Author
Owner
Copy Link

@nbaillie commented on GitHub (Apr 30, 2018):

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.

screen shot 2018-04-30 at 15 13 47
screen shot 2018-04-30 at 15 14 06

it can see the childs though in Child Prefixes under the prefix.
screen shot 2018-04-30 at 15 14 21

@nbaillie commented on GitHub (Apr 30, 2018): 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. ![screen shot 2018-04-30 at 15 13 47](https://user-images.githubusercontent.com/19475901/39431578-198cee42-4c89-11e8-9441-ef3a777543d4.png) ![screen shot 2018-04-30 at 15 14 06](https://user-images.githubusercontent.com/19475901/39431681-5e8fd05e-4c89-11e8-934c-e81e702833ef.png) it can see the childs though in Child Prefixes under the prefix. ![screen shot 2018-04-30 at 15 14 21](https://user-images.githubusercontent.com/19475901/39431703-6abdffae-4c89-11e8-9e2f-9c7e70341ec8.png)
adam commented 2025-12-29 16:26:26 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 7, 2020):

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

@DanSheps commented on GitHub (Apr 7, 2020): Going to close this out, discussion can continue under #2562
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#859
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?