-
I am building our prefix tree in netbox. We use a fully redundant design with different subnets on two sites, which are also available on the other site and are managed by separate VRF with transit VLANs etc. My problem now is, that the prefix tree does not seem to be able to reflect a complete structure, including sub-prefixes that are in another VRF then the parent prefix. In my example below, The yellow /24 should be a child of the yellow /19. Same for the green and the orange. I think it's a quite common scenario that you have supernet which includes several prefixes, each belonging to a different VRF. So i want them to be displayed accordingly in the tree strucuture with correct parent/child information and not separated by VRF. Am i overseeing something? If i go into the details of the child prefix, i do see it's parents, but the direct parent is showing "0" children, which does not make sense at all. Is this a bug or just a setting i have missed?? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
This is intentional / by design: different VRFs in Netbox are effectively different network namespaces and form their own trees. For example, 192.168.0.0/24@VRF1 is a completely different prefix to 192.168.0.0/24@VRF2, and each has its own independent child prefixes and child IP addresses. The use case this supports is overlapping address space for different tenants, rather than distinct layer 3 routing zones within an overall address plan. I would personally like to see a separation between network namespace (i.e. a domain of IP address uniqueness) and a VRF (i.e. a layer 3 routing domain), but this has been proposed and rejected before. |
Beta Was this translation helpful? Give feedback.
-
One thing that just occurred to me is that when you have a use case which doesn't fit with a design fundamental like VRFs being independent, that you can effectively paper over this with Object Custom Fields. So in your case, instead of using the VRF model, create a VRF custom_field on Prefix and link that instead, then IPs are in one namespace/tree but you can still build process and tools around the VRF reference. This doesn't work for all the other places that VRF would be displayed or used to filter a form, but might be a useful compromise depending on how you are using the info. You can get some references using Custom Links to template a button that searches for the linked object, eg on VRF, but it won't be able to show the Display Name of the object.
A trade off, depending on what is more important for you and your teammates.
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Brian Candler ***@***.***>
Sent: Thursday, February 9, 2023 9:20 AM
To: netbox-community/netbox ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [netbox-community/netbox] Prefix tree not including prefixes in different VRF (Discussion #11687)
This is intentional / by design: different VRFs in Netbox are effectively different network namespaces and form their own trees. For example, ***@***.*** is a completely different prefix to ***@***.***, and each has its own independent child prefixes and child IP addresses.
The use case this supports is overlapping address space for different tenants, rather than distinct layer 3 routing zones within an overall address plan.
I would personally like to see a separation between network namespace (i.e. a domain of IP address uniqueness) and a VRF (i.e. a layer 3 routing domain), but this has been proposed and rejected before.
—
Reply to this email directly, view it on GitHub<#11687 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMZRS7K2OI3WUKXUVTLWWUDKTANCNFSM6AAAAAAUUAPJPY>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Thanks for your explanations. It was my first thought as well, that there may be a separation because of the VRF. But that does not make sense at all. I guess it is very common that VRF only come into place at a "deeper" level but should be considered as a legit child to the toplevel prefixes. I also understand that even within one tenant, it could happen that you have overlapping prefixes. So i guess the right way would be to implement something like a namespace/domain to allow further separation or grouping. What makes the least sense for me, is that the details of the child prefix is showing me the correct parents, but the parent is not showing it as a child. That's just nowhere consistent and made me think that this may be a bug. |
Beta Was this translation helpful? Give feedback.
This is intentional / by design: different VRFs in Netbox are effectively different network namespaces and form their own trees. For example, 192.168.0.0/24@VRF1 is a completely different prefix to 192.168.0.0/24@VRF2, and each has its own independent child prefixes and child IP addresses.
The use case this supports is overlapping address space for different tenants, rather than distinct layer 3 routing zones within an overall address plan.
I would personally like to see a separation between network namespace (i.e. a domain of IP address uniqueness) and a VRF (i.e. a layer 3 routing domain), but this has been proposed and rejected before.