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

Child prefixes do not show up as child if they belong to a different VRF than the parent #4269

New Issue
Closed
opened 2025-12-29 18:34:19 +01:00 by adam · 8 comments
adam commented 2025-12-29 18:34:19 +01:00
Owner
Copy Link

Originally created by @anubisg1 on GitHub (Nov 11, 2020).

Environment

  • Python version: unknown
  • NetBox version: 2.8.8

Steps to Reproduce

  1. create a prefix (for example a /24) and ensure it's listed as a "pool" and assign to NO vrf
  2. click on child prefixes --> create a child prefix
  3. create a new child prefix, for example a /30 , belong to a vrf
  4. the new /30 is not seen as a child prefix of the main prefix

image

  1. BUT the child prefix recognizes the parent

image

Expected Behavior

in this example, the /24 is a range where we can subnet and allocate different subnets.
i need to allocate the range and track it's usage as new subnets are created.
those subnets do not need to belong to the same vrf, this is just a pool.
i should see all of those prefixes as child of the main prefix

it's important to note, that vrf should not be the only way to define a child prefix.
VRFs can be used for application segregation not necessarily for IP overlapping.

A very common use case is that a customer has VRF Production with subnet a.b.c.0/25 and VRF Test with subnet a.b.c.128/25 southbound of a firewall (so that prod and test do not communicate directly with each other), but then, northbound the two subnets are summarized and advertised to the WAN.

Observed Behavior

the subnetted prefixes have no correlation with the main one

Originally created by @anubisg1 on GitHub (Nov 11, 2020). ### Environment * Python version: unknown * NetBox version: 2.8.8 ### Steps to Reproduce 1. create a prefix (for example a /24) and ensure it's listed as a "pool" and assign to NO vrf 2. click on child prefixes --> create a child prefix 3. create a new child prefix, for example a /30 , belong to a vrf 4. the new /30 is not seen as a child prefix of the main prefix ![image](https://user-images.githubusercontent.com/4518931/98805107-673f9500-2417-11eb-9be6-7b83d0a2a1e7.png) 5. BUT the child prefix recognizes the parent ![image](https://user-images.githubusercontent.com/4518931/98805067-598a0f80-2417-11eb-9c85-35893418ed39.png) ### Expected Behavior in this example, the /24 is a range where we can subnet and allocate different subnets. i need to allocate the range and track it's usage as new subnets are created. those subnets do not need to belong to the same vrf, this is just a pool. i should see all of those prefixes as child of the main prefix it's important to note, that vrf should not be the only way to define a child prefix. VRFs can be used for application segregation not necessarily for IP overlapping. A very common use case is that a customer has VRF Production with subnet a.b.c.0/25 and VRF Test with subnet a.b.c.128/25 southbound of a firewall (so that prod and test do not communicate directly with each other), but then, northbound the two subnets are summarized and advertised to the WAN. ### Observed Behavior the subnetted prefixes have no correlation with the main one
adam closed this issue 2025-12-29 18:34:19 +01:00
adam commented 2025-12-29 18:34:19 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Nov 13, 2020):

IMO - the child isn't a child if it's in a different VRF and shouldn't show a "parent" in a different VRF. Changing that data model would severely break things for me, and I imagine many others.

@tyler-8 commented on GitHub (Nov 13, 2020): IMO - the child isn't a child if it's in a different VRF and shouldn't show a "parent" in a different VRF. Changing that data model would severely break things for me, and I imagine many others.
adam commented 2025-12-29 18:34:20 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Nov 13, 2020):

IMO - the child isn't a child if it's in a different VRF and shouldn't show a "parent" in a different VRF. Changing that data model would severely break things for me, and I imagine many others.

how exactly does it break things?

I can see the following use cases which do NOT break (and if you have a different one, PLEASE describe it).

assumption - If a prefix is used to track subnetting (i.e. parent/child relationships), it should be marked as an IP pool

  1. Overlapping IP address per VRF --> this requires same subnet allocated to different tenants
  2. Non overlapping ip addresses per VRF (vrf segregation used as security segmentation) --> all subnets belong to the same tenant

In the first case, you would break child/parent relationship because each subnet must belong to a separate tenant therefore denying the parent/child relationship between subnets
In the second case, (for the same reason), because main prefix and subnetted prefixes belong to the same tenant the child/parent relationship would be maintained regardless of the vrf each subnet belongs to

@anubisg1 commented on GitHub (Nov 13, 2020): > IMO - the child isn't a child if it's in a different VRF and shouldn't show a "parent" in a different VRF. Changing that data model would severely break things for me, and I imagine many others. how exactly does it break things? I can see the following use cases which do NOT break (and if you have a different one, PLEASE describe it). assumption - If a prefix is used to track subnetting (i.e. parent/child relationships), it should be marked as an IP pool 1) Overlapping IP address per VRF --> this requires same subnet allocated to different tenants 2) Non overlapping ip addresses per VRF (vrf segregation used as security segmentation) --> all subnets belong to the same tenant In the first case, you would break child/parent relationship because each subnet must belong to a separate tenant therefore denying the parent/child relationship between subnets In the second case, (for the same reason), because main prefix and subnetted prefixes belong to the same tenant the child/parent relationship would be maintained regardless of the vrf each subnet belongs to
adam commented 2025-12-29 18:34:20 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 13, 2020):

I think there's some understandable confusion around how NetBox views relationships among global and non-global prefixes. For planning purposes, it can be helpful in certain texts to see all of these as a single hierarchy. However, from a technical standpoint, the global table is just another isolated routing table the same as a VRF, so it makes sense to treat it separately. Admittedly, NetBox hasn't been terribly consistent in this regard.

IMO the bug here is that NetBox displays the global prefix 10.138.89.0/24 as a parent for the prefix 10.238.89.20/30, which exists in a VRF. We should be more strict about treating global prefixes as belonging to a discrete table. The upcoming addition of route import/export tracking in v2.10 may help with this conceptually.

VRFs can be used for application segregation not necessarily for IP overlapping.

Regardless of its use, each VRF is a discrete layer three routing table. Prefixes which exist in one VRF may or may not exist in another, or in the global table.

@jeremystretch commented on GitHub (Nov 13, 2020): I think there's some understandable confusion around how NetBox views relationships among global and non-global prefixes. For planning purposes, it can be helpful in certain texts to see all of these as a single hierarchy. However, from a technical standpoint, the global table is just another isolated routing table the same as a VRF, so it makes sense to treat it separately. Admittedly, NetBox hasn't been terribly consistent in this regard. IMO the bug here is that NetBox displays the global prefix 10.138.89.0/24 as a parent for the prefix 10.238.89.20/30, which exists in a VRF. We should be more strict about treating global prefixes as belonging to a discrete table. The upcoming addition of route import/export tracking in v2.10 may help with this conceptually. > VRFs can be used for application segregation not necessarily for IP overlapping. Regardless of its use, each VRF is a discrete layer three routing table. Prefixes which exist in one VRF may or may not exist in another, or in the global table.
adam commented 2025-12-29 18:34:20 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Nov 13, 2020):

@jeremystretch you are right but then, if am using netbox as an IPAM how am i supposed to track my ip allocation?

other ipam softwares like infoblox do not have this issue.

If i create a pool prefix, and i manually decide to create a child prefix (as in i pressed the button "child prefix"), why does it matter in which vrf the child prefix belongs to?

how can i track subnetting and how can i track iprefix usage if the parent/child relation is disregarded simply because i am in a different vrf?

@anubisg1 commented on GitHub (Nov 13, 2020): @jeremystretch you are right but then, if am using netbox as an IPAM how am i supposed to track my ip allocation? other ipam softwares like infoblox do not have this issue. If i create a pool prefix, and i manually decide to create a child prefix (as in i pressed the button "child prefix"), why does it matter in which vrf the child prefix belongs to? how can i track subnetting and how can i track iprefix usage if the parent/child relation is disregarded simply because i am in a different vrf?
adam commented 2025-12-29 18:34:20 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 13, 2020):

If i create a pool prefix, and i manually decide to create a child prefix (as in i pressed the button "child prefix"), why does it matter in which vrf the child prefix belongs to?

Again, each VRF is an entirely independent routing table. 192.168.0.0/24 in VRF A may be an entirely different network than 192.168.0.0/24 in VRF B. This is how VRFs work, and the concept is not at all unique to NetBox.

@jeremystretch commented on GitHub (Nov 13, 2020): > If i create a pool prefix, and i manually decide to create a child prefix (as in i pressed the button "child prefix"), why does it matter in which vrf the child prefix belongs to? Again, each VRF is an entirely independent routing table. 192.168.0.0/24 in VRF A may be an entirely different network than 192.168.0.0/24 in VRF B. This is how VRFs work, and the concept is not at all unique to NetBox.
adam commented 2025-12-29 18:34:20 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Nov 13, 2020):

Again, each VRF is an entirely independent routing table. 192.168.0.0/24 in VRF A may be an entirely different network than 192.168.0.0/24 in VRF B. This is how VRFs work, and the concept is not at all unique to NetBox.

1 - wouldn't those prefixes belong to different tenant?
2 - i am forcing a parent/child relationship by clicking on "create child", button, why would netbox "assume" otherwise ?
3 - how can netbox address the use case i am describing, which is pretty common to be honest

@anubisg1 commented on GitHub (Nov 13, 2020): > Again, each VRF is an entirely independent routing table. 192.168.0.0/24 in VRF A may be an entirely different network than 192.168.0.0/24 in VRF B. This is how VRFs work, and the concept is not at all unique to NetBox. 1 - wouldn't those prefixes belong to different tenant? 2 - i **am** forcing a parent/child relationship by clicking on "create child", button, why would netbox "assume" otherwise ? 3 - how can netbox address the use case i am describing, which is pretty common to be honest
adam commented 2025-12-29 18:34:20 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 13, 2020):

It sounds like you've made some incorrect assumptions about how several parts of NetBox work. If you'd like assistance using NetBox, please post to our mailing list, as GitHub discussions should be focused on development.

As far as this issue goes, I'm going to close it because the cited behavior is intentional as @tyler-8 mentioned.

@jeremystretch commented on GitHub (Nov 13, 2020): It sounds like you've made some incorrect assumptions about how several parts of NetBox work. If you'd like assistance using NetBox, please post to our [mailing list](https://groups.google.com/g/netbox-discuss), as GitHub discussions should be focused on development. As far as this issue goes, I'm going to close it because the cited behavior is intentional as @tyler-8 mentioned.
adam commented 2025-12-29 18:34:20 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Nov 13, 2020):

if you don't want to think about it i understand but honestly nor you nor tyler really answered any question challenging your ideas...

this really is confusing and demotivating.. sorry for being brutally honest

@anubisg1 commented on GitHub (Nov 13, 2020): if you don't want to think about it i understand but honestly nor you nor tyler really answered any question challenging your ideas... this really is confusing and demotivating.. sorry for being brutally honest
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
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#4269
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?