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.

[steffann]

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.

What ideas do you already have? A per-prefix list of "also exported to VRF x", or more on a "VRF y is imported into VRF z" level? I wouldn't mind spending some brain cycles on this…

[nward]

Having thought more about this from last time I posted on the subject, I don't think that Netbox can or should model VRF import/export stuff. Different vendors and options and so on really makes this too complex a problem to solve, and there will always be deficiencies.

I think the original poster's suggestion is reasonable. I (and others I know) use the term "addressing domain" to describe an area of a network where addresses cannot overlap. I think that to achieve this, we could re-purpose netbox's "VRF" concept as an "Addressing Domain" and remove "RD" and other parameters from the VRF model.

Then, we should add in links between Addressing Domains, for example:

• 3 domains - A, B, C
• "Link" between A and B preventing overlapping prefixes/addresses between these two domains
• "Link" between B and C preventing overlapping prefixes/addresses between these two domains
• A and C can have overlapping addresses, as they are not linked

I think this is the most flexible, and doesn't impose any limitations or network specific concepts about what a "VRF" is. It means users can define however many addressing domains they like, including zero.

[steffann]

I think the original poster's suggestion is reasonable. I (and others I know) use the term "addressing domain" to describe an area of a network where addresses cannot overlap. I think that to achieve this, we could re-purpose netbox's "VRF" concept as an "Addressing Domain" and remove "RD" and other parameters from the VRF model.

Euhm, No, we actively use the VRF information in NetBox. And I'm sure others do as well.

[jeremystretch]

The scope of this issue is the implementation of route target modeling to inform the import/export of prefixes among VRFs. This is all well-defined in RFC 4364 so the implementation should be fairly straightforward.

[LukeDRussell]

Will that include the functionality to prevent overlapping addresses across VRFs?

An arbitrary “VRF group” might be another seperate option. IIRC @jeremystretch you changed the title of this Issue way back.

It’s simple enough to implement a report that would show overlaps, but it wouldn’t prevent users creating those prefixes in the first place.

[jsenecal]

@jeremystretch I could start working on this and submit a PR if nobody has already started working on this.

I had planned to map what VRFs are leaked into another and augment the uniqueness validation to what has been mentionned earlier in this issue.

Do we need/want to track the directionality of the leaking? ie. Import vs Export ?

[jeremystretch]

Seems like we jumped the gun a bit by tagging this for v2.10 without having a firm model in place. Below is a quick draft of my proposal:

class RouteTarget(ChangeLoggedModel):
    name = models.CharField(
        max_length=??,
        unique=True
    )
    description = models.CharField(...)

    class Meta:
        ordering = ['name']


class VRF:
    ...
    import_targets = models.ManyToManyField(
        to='ipam.RouteTarget',
        related_name='import_for_vrfs',
        blank=True
    )
    export_targets = models.ManyToManyField(
        to='ipam.RouteTarget',
        related_name='export_for_vrfs',
        blank=True
    )

This adds a new RouteTarget model and provides two relationships from VRF to it (for import and export). It then becomes possible to query all the prefixes or IP addresses that one would expect to be visible by any given VRF:

vrf = VRF.objects.get(name='MyVRF')
Prefix.objects.filter(
    Q(vrf=vrf) |
    Q(vrf__import_targets__in=vrf.export_targets.all())
)

I like this approach because it's relatively simple and it very closely mirrors how route targets work in reality. We'd probably extend the RouteTarget model to support tenancy and tags as well.

[LukeDRussell]

Love your work @jeremystretch