Intended ontology of IPAM: VRF model in Netbox? (Meant to represent the device-local instantiation of a VRF, or the extended/multi-device routing-domain of all nodes using the same route-targets values?)

[menckend]

I can't quite suss out what the authorial intent is with the VRF model in Netbox's IPAM application. On the one-hand, it includes a route-distinguisher field, which at least suggests that it's meant to represent the device-local VRF construct (since RD values need to be at least VRF-unique by device within an MP-BPG routing domain.) On the other hand; there's no foreign key relationship to the device table, making it un-tenable to "mean"/use-as that.

Alternatively, If it's meant to represent the extended/distributed routing-domain comprised by all the MP-BGP routers swapping routes with the same import-export values. In the MPLS or EVPN use-cases, I think this would essentially be a VPN-IPv4 address family (again, in the distributed/shared sense.) If that's the intent though, the presence of the RD field seems inappropriate.

Ideally, I'd like to be able to model both usages of the "VRF" concept, but I don't want to start ice-skating up-hill if one or the other is what was originally intended by the developers.

For my part, I've tried adding a "VRF-type" custom field, so that I can have entries for the shared/distributed VRF concept. (Which I can associate individual interface objects with). And I've also considered adding a custom-field that's a reference to the device model/object. In that scenario, I might end up with:

Devices

• Device-A
  • Interface-A
    • VRF-m
  • Interface-B
    • VRF-n
• Device-B
  • Interface-A
    • VRF-m
  • Interface-B
    • VRF-n

VRFs

• VRF-m (type=distr.; rt-tg-exp=100; rt-tg-imp=100)
• VRF-n (type=distr.; rt-tg-exp=200; rt-tg-imp=200)
• VRF-o (type=local; rt-tg-exp=100; rt-tg-imp=100; device = Device-A, RD=1.2.3.4:1)
• VRF-p (type=local; rt-tg-exp=200; rt-tg-imp=200; device = Device-A, RD=1.2.3.4:2)
• VRF-q (type=local; rt-tg-exp=100; rt-tg-imp=100; device = Device-B, RD=1.2.3.5:1)
• VRF-r (type=local; rt-tg-exp=200; rt-tg-imp=200; device = Device-B, RD=1.2.3.5:2)

That let's me capture more-or-less everything I want to, but seems pretty janky to me. I think that the local-context usage is the more "important" one, in terms of modeling actual device configuration intent, but I do see the appeal in being able to easily/directly pluck a list of interfaces across dozens of different devices that are all in "the same VRF". I wonder if maybe it would make sense to lean fully into the device-local context data model, and setting the "VRF" field of the interface object to the device-local VRF object. And if we wanted to get a list of all interfaces "in the same VRF" across multiple devices, we'd need a more complex query (an outer join?) the grabbed all interfaces that were bound to VRF objects with matching route-target import/export values?

Anyone have any insights as to what the design intent is/was here? (Or any novel implementation strategies they've considered?)

[tyler-8]

Related: #7608

Just to cross-pollinate my discussion around this topic from the Slack today:

Tyler Bigler
I find myself struggling with this question lately as well: #18020
The VRFs in NetBox create what is essentially a totally separate IP space from the “global” space, but that isn’t actually true in all applications of a VRF on devices. The “device” VRF for a given IP space might only be relevant for that device (or any of its siblings), but is otherwise “globally routable/reachable”. Other times you have an IP space that might be repeated 100 times, each one being its own VRF (within your network, but not necessarily configured as a VRF on any device).

Jamie Murphy
The idea of l3 domains or ip namespace has come up a few times to solve that.

Chris Russell
and recently in the initial 4.2 discussions - its still on the long term radars. There's also another use case not covered which is where you might have a VRF with an x.x.x.x:VPN as a coverall, but routers with loopback:vpn as the RD. In my old job I had a plugin which created a vrf instance underneath VRF for this purpose

Dave Kempe
having recently watched a new hire at a customer attempt to model the tangled mess of fortigate VDOMs and VRFS that last guy left, yes, netbox could be better at this. Of course we could just insist there was no need for VRFs ever too

[brownej]

L3VPN RFC introduced the term VRF and provided general mechanisms to manage exchanging and using routing objects. Subsequently, the RFC gave a very small number of use cases but left actual architectures as an exercise for the reader. The standards give tools, but there’s many ways to use those tools which result in non-functioning networks. Further confusion was created by IOS conflating RD/RT. The term “vrf-lite” was introduced but never “really” defined. On top of that, there’s years and years of folklore about how all of this works. Most of the folklore is wrong in subtle ways. Netbox continues that folklore in using the term VRF to mean a set of routes shared across a bunch of routers that are isolated from other sets of routes. This is a useful concept but technically wrong. By the standards, VRF only has a local meaning in the context of a single logical router.
Are we surprised it’s complex and difficult? It’s kind of a dumpster fire.
One more note specific to Tyler Bigler’s thread here: It’s totally reasonable for route objects that reference private IPv4 space to be repeated in many tenancies or VRFs or different organizations. It’s the beauty of the medusa that we call private IP space. (You just get the horrifying task of looking straight at it when you try to merge networks.) Public IP space on the other hand really can’t get allocated multiple times across different VRFs, but repeating route objects that reference them might make sense in some configurations. I don’t think NB makes any distinction between an IP allocation and a route object. Some more subtlety to make our heads spin.
Our modeling tools either need to allow the full complexity enabled by the standards or be very opinionated about the particular architectures supported by the model. Either way it should be spelled out.
I guess my point in adding this to the discussion is to add the warning that if you follow this path you may find dragons.