VRF route target import/export tracking

[LukeDRussell]

After #43 we would like to be able to stop duplicate addresses across different VRFs, in an arbitrary manner.

Some of our customers have multiple VRFs for security reasons but they shouldn't be NATing between VRFs. We also have some customers wanting to talk to each other directly (not via the internet). We would also want to reserve some RFC1918 to never overlap with any VRF for certain UC and network services.

I imagine there would be some sort of linking of multiple VRFs to a "address space", with an option to prevent duplicate IPs within the namespace. I'm seeing "address space" as being seperate from "tenant".

[jeremystretch]

This is probably best served by introducing import/export tracking among VRFs. This is something I've had in the back of my mind for a while as a long-term goal. Not sure what the timeline would be.

[LukeDRussell]

Yeh that fits with the technology too. In our case it's all done via firewalls instead of MPLS import/export, but it's the same concept.

It's probably not a common use case, I just wanted to get it on the pipeline.

[bdlamprecht]

I'd like to see this get added as well... (so bump?)

I'm trying to model the VRF RT (or "route-target") into the existing VRF RD (or "route-distinguisher"), but it doesn't work very well and I end up doing a lot of hacks to make it work.

I don't think it would be too complex to implement, but don't want to assume things as I tend to not fully conceptualize how things are modeled and how those changes impact the DB and overall application performance.

[nward]

This is a tricky one, as there are instances where you have a VRF or routing instance configured which has different import/exports than other routers. Or, you might have two VRFs on one router with very similar exports and imports, but maybe a couple of differences.

I generally dislike the idea of modelling a network-wide "VRF" or IPVPN or whatever construct. The only way to accurately model it is to model:

• VRFs per router, with import/export lists of RTs, with notes against each RT (i.e. "except community x").
• List of RTs associated through import/exports with VRFs above
• List of RDs associated to VRFs above

At that point you can inspect a VRF on a router and see what other VRFs on the network it interacts with.

Right now VRFs have a network wide "RD" which is how I got to this issue - on many (most modern?) networks, RD is unique per VRF per router.

[afics]

@nward We use L3VPN extensively, so we would need a way to tie a VRF to a group of routers.
In our network VRF import/export is configured the same on all of those. On each of these routers only the VRFs which are actually used on a specific router are configured.

To summarize, what we'd need are per group-of-routers VRFs and VRF import/export information. We could then use that to automatically provision required VRFs to a router if an L3 interface with a prefix in a certain VRF is added to it.