Add more "support" for VRF

[lunkwill42]

There are intermittent requests from the NAV reference committee meetings to "add support for VRF" in NAV.

However, it is quite unclear what "support for VRF" actually entails. This discussion exists to keep a log of comments from users about what would constitute "VRF support".

Apparently, some of the discussed needs would be covered by NAV's feature to avoid VRF polling redundancies using master/slave device registrations (see also #3303). While this feature is useful for those who monitor each VRF as individual IP devices in NAV, one representative comments that they do not assign separate management addresses to VRF instances. Not all routing information can be fetched from the physical device's management (at least not for Juniper devices, as this comment pertains to). No further details were provided in this discussion thread.

The University of Tromsø has also expressed a need to monitor logical (layer 3) links between VRFs, as these may go down independently of the layer 2 links that NAV monitors. It is somewhat unclear what this entails and how this could be monitored, so UiT is advised to post their own issue on this.

So, does anyone have any comments as to what should be done here?

[lunkwill42]

I had a short discussion internally with @knutvi, and there doesn't seem to be any currently unresolved VRF needs in Sikt's CNaaS service. We get all the information we need from our Juniper routers, and there is no need for VRF specific information currently.

But there seems to be some confusion within these discussions as to what VRF actually IS. It seems to mean different things to different users, and potentially mean different things to different vendors. So we may need to really define what we mean when we are discussing the term "VRF".

[ingeborgoh]

What is VRF: https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding

In UiTs setup (mainly Cisco-shop) we use VRF Lite for creating virtual routing environments for different use cases. I.e. for splitting tenants and organizations, or for segregations between different security zones (VLANs for L2 vs VRFs for L3). Sometimes these separations makes it hard to create these virtual routers as separate devices and poll from NAV due to routing/access/security-settings.

We use dynamic routing between most of these virtual routers (in these specific VRF Lite's), sourcing from either ports/interfaces, sub-interfaces or loopbacks. There is no fields showing VRFs when we list these types of interfaces, port details or prefixes. This makes it somewhat hard to debug issues or use the information from NAV "as is" without support from other tools/cli.

How this maps to some data model/structure in NAV we do not know. We feel that the data model from Netbox seems like a good start (Netbox/IPAM/VRF). Here VRFs have names and route distinguishers, and prefixes could be mapped to one (and only one) VRF.

Examples from LibreNMS that illustrates out basic needs:
For a VRF, a list of interfaces.
For an interface, which interfaces does it belong to.