Expand and make 'VRF' concept consistent

[PieterL75]

Currently, NetBox supports Layer3 separations using the 'VRF' concept.
Within a VRF, all IP/Prefixes have to be unique.

While this is a good concept to create the separation, I believe it is not the correct name for it.

My proposal is to introduce a 'Layer3 Domain'.
The function of a VRF, then needs to changed to a 'Routing Domain'.

The major difference is that

• a 'Layer3 Domain' defines the uniqueness of IP space
• a 'VRF' defines what prefixes can reach each other.

In the most simplistic implementation

• A prefix belongs to a Layer3 Domain
• A VRF is linked to a Layer3 Domain and can have prefixes out of that L3Domain assigned
• Multiple VRFs can be linked to the Layer3 Domain
• one Predix can only be linked to one VRF.

Further fleshing out can include route leaking, vrfs with prefixes from different layer3 domains,

Any ideas or suggestions on this ?

[candlerb]

I agree, but this has been proposed and rejected before. e.g. #7608, #6621, #6533.

EDIT: #7608 was yours :-)

[PieterL75]

And still wondering why ...
Having to maintain 5 different 10.0.0.0/8, and each of that /8 spread across hundreds of small vrfs (one per customer one), this will solve all that.
And it is not something that I alone do...

[mtinberg]

Since I still had custom object fields on the brain, could you implement this policy within the existing netbox framework by creating 5 dummy VRFs for each of your layer3 domains then use a custom_field single-object reference to link the prefix to the customer VRF, that would allow you to use the db to enforce uniqueness. Maybe there is a way to create a custom validator to get some of the other properties you want or even a Report to catch misclicks. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: PieterL75 ***@***.***> Sent: Thursday, June 8, 2023 10:43 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Expand and make 'VRF' concept consistent (Discussion #12840) And still wondering why ... Having to maintain 5 different 10.0.0.0/8, and each of that /8 spread across hundreds of small vrfs (one per customer one), this will solve all that. And it is not something that I alone do... — Reply to this email directly, view it on GitHub<#12840 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM767G75PQ3Q3W3WXHTXKHXI7ANCNFSM6AAAAAAY7OFW5U>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[PieterL75]

I can do that with custom fields, sure thing.
But then the ui gets weird. The vrf fields has to be there but it does not represent a vrf, and a custom field (way down the page) that will also be called vrf.
Custom validators also need to be created, but that's one of the cool things, that it is possible...

Another option is to write a plugin for this, but then we still have that 'vrf' native field..

[a084ed22]

Bringing my own experience on this, my setting is managing an environment where mergers have resulted in the same address space being reused in what used to be independent companies. Netbox's current VRF objects allows to split the addresses by context, but this keeps me from mapping actual VRF usage into netbox. I'd welcome something akin to L3 domains replacing VRFs.

[DetunizedGravity]

I am among those who already discussed this topic, and regret that the feature has not been approved so far.

Here are my thoughts as of today, summarized:

1. Any mechanism enforcing address and/or prefix unicity in Netbox should be optional, since it is optional in real life (anycast, multicast, ECMP...).
2. Unicity may be desired for exploitability purposes only. E.g. link local prefixes may be reused on many devices, but one may want to ensure bijection between a local link prefix and a given device to ease exploitation. This is the use case that led us to use in Netbox a pseudo VRF to enforce unicity, and a custom field to store the actual VRF, and that is a PITA.
3. Netbox cannot and will probably never be able to fully replicate the behaviour of route leaking between VRFs to (if requested) determine unicity: it would need on the fly reverse engineering of routing policies, route maps, et al.
4. Proposals to implement a way to enforce unicity for purely administrative purposes have been shot down so far and I don't have much hope for this new one.

Netbox right now does not try to enforce unicity based on route targets (rightly so, cf. points 1 and 3), and even that would not have helped my use case. Maybe I'll try to see if I can do something with custom validators, but that is one feature of Netbox that I have absolutely no experience with, today. I can't tell if it is possible, not to mention appropriate.