VRF-Lite with IP addresses unique in the global table and all VRFs

[robert-maat]

Hi All,

In some enterprise environment I see that VRF are used to create separate "security zones". They are often connected by firewalls to other VRFs and the Global routing table. So, in this case the IP addresses/prefixes need to be unique across the Global Routing table and all VRFs together.

Now I'm using the description field of prefixes for this, but it would be nice to also have an overview of the VRFs with connected prefixes in the current Netbox VRF section and have the global and VRF IP prefixes/addresses unique. This way you still keep the overview of all used and free prefixes like you have when all IP Prefixes are in the global table.

I'm wondering if there is a feature or configuration to make use of a "VRF-Lite" type to support this?

[candlerb]

Netbox "VRFs" are really "IP address namespaces" - perhaps VRF wasn't a great name for this.

If you want to enforce uniqueness of addresses and prefixes, then you should put them into the global VRF. If you then want to label specific prefixes and/or IP addresses as belonging to a VRF-Lite style VRF, then you could create a custom field for that purpose (note that a single custom field can be linked simultaneously to IPAM > IP Address and IPAM > Prefix)

[robert-maat]

Thank you for your replay, that's also a good option indeed, creating a custom field.
I just thought of another option which is using tags. That way I can have an overview on what is connected to the tags/VRFs in the web interface. I will experiment with both options and see what best suits me.

[jeremystretch]

In some enterprise environment I see that VRF are used to create separate "security zones".

This is a pretty clear misuse of the model. A VRF is a discrete L3 domain, whereas security zones generally are not.

Netbox "VRFs" are really "IP address namespaces" - perhaps VRF wasn't a great name for this.

@candlerb The name VRF comes from the definition in RFC 4364.

[patrickpreuss]

Maybe we can add some clarity to it.

My understanding would be there is a Enterprise this is something like "Routing Domain".
And the VRFs are technically implemented on routers.

So that Datacenter routers would have a landing zone, in front of the Secured Zones.
The Firewalls would have routes to the Secured Zones, routed in different VRFs on the Datacenter Routers.

@robert-maat Does this capture your question?

Can this be captured by import and export between VRFs or "assigning" addresses to a different VRF?

[5x3]

It is possible to set default VRF for newly added addresses? if not - treat it as feature request.
It is possible to search in DB all IP's in "Global" VRF?

[patrickpreuss]

I would vote to have a feature to assign a VRF on Tennant / Region / Site / Device level as "Default" VRF, that new addresses for a Tennant can end up in their default VRF.
Reason would be that some of us have multiple Tennants using the same Private Addressing. But Systems are already rolled out and will never configured with VRFs on them.

[mtinberg]

I think Netbox tries to stick to modeling the potential relationships between things but doesn't try to enforce design behavior too much, so if you want non-default behavior in forms the best bet is to re-create the form using a Script that enforces your business rules. In this case, a custom field single object reference on Tenant to VRF then have a Script for New Address creation that asks for the Tenant and VRF and if the VRF is unspecified will look up and assign the "default" VRF for that tenant, then a Report to find discrepancies, where someone uses the built-in forms and mis-assigns something, data entry doesn't have to be perfect if a report can find a problem and it can be fixed before it becomes a Problem. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Patrick Marc Preuss ***@***.***> Sent: Wednesday, February 22, 2023 7:45 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] VRF-Lite with IP addresses unique in the global table and all VRFs (Discussion #6533) I would vote to have a feature to assign a VRF on Tennant / Region / Site / Device level as "Default" VRF, that new addresses for a Tennant can end up in their default VRF. Reason would be that some of us have multiple Tennants using the same Private Addressing. But Systems are already rolled out and will never configured with VRFs on them. — Reply to this email directly, view it on GitHub<#6533 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5V6VGKLT7BH6T3L23WYYJ7DANCNFSM46AKCEAA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[smasharov]

We have several VRF with route leaking between them by prefixes, so It would be nice to have an option to require uniqueness of ip addresses an prefixes between such kind of VRF marked by the same route target

[PieterL75]

Ah, my beloved VRF discussion :-)
I had some FR/Discussion in the past on exaclty this issue, but they all ran dead...

I think the 'VRF' concept in Netbox really need a big review.
I'm not going to go into the naming, but only how things work.

In my opinion it would be required that these concepts (again, don't fall over the name, its a concept)

• Layer3 domain: All IPs need to be unique in this domain
• VRF: Set of prefixes/IPs that are routable to eachother. These can come from one ore more layer3 domains, but they need to be unique in the vrf.
• you can link a prefix and even an IP to a layer3 domain and optionally to a vrf.
• prefixes/ips that belong to the same layer3 domain are shown in the prefix/ipaddress list (currently that is the same vrf)

I have some use cases that are solved with this idea:

• 10.0.0.0/8 is split in multiple VRF's
• each VRF has a connection to a central device (router, firewall, ...)
• on a side, there is a vrf that is not connected to any firewall, but services that needs to be enabled for some servers
  -- the prefix is assigned to VRF1
  -- on IP in the prefix is assigned to VRF2
  -- because all IPs are from the same layer3 they are still related to eachother in the prefix

I hope this really gets more attention. working with tags or custom fields to document this is not working properly..

Pieter

[PieterL75]

See #12840