Ensure unique IP space between VRF and the Global routing table

[angel...@gmail.com]

Hello,

First of all, thanks for Netbox.

It is a great tool that covers a lot of our needs as an NSP.

Here is my question: is there a way when I create a prefix to ensure it does not exist elsewhere (in another VRF or in the Global routing table)?

The idea behind is that the prefix is advertised to some others VRF and then it must be globally unique.

If not, then I guess we will have to script this feature ourselves.

Thanks!

Regards.

[Brian Candler]

If you set ENFORCE_GLOBAL_UNIQUE = True in configuration.py, it will ensure uniqueness within the global table (i.e. null VRF).

There is no uniqueness enforced between VRFs.  That's kind-of the point of VRFs - that you can re-use the address space in a different network.

But it sounds like using the global table when you want a prefix to be globally unique might do what you need.

[angel...@gmail.com]

Hello Brian,

Thanks for your answer.

That's kind-of the point of VRFs

Yes. But the point of VRFs is also Route Target import/export and so it may be necessary to ensure uniqueness of a subnet between multiple VRFs.

I think we will create the subnet both in the Global routing table and the VRFs implied.

Regards,

[Lukasz Polanski]

Hello to all the community,

I would like to back an idea of enforcing uniqueness of prefixes across VRFs. We are deploying Netbox in an University based on 3 separate campuses and having a number of large prefixes to manage. In an IT architecture we would like to use it both as a source of truth for building configurations from and for planning purposes as well. We are having our infrastructure a bit dis-homogeneous trying to deploy EVPN and VXLAN in some places. For this reason prefixes assigned to some VRFs in an EVPN fabric should be unique at least in the global table (we still need to be able to route to this prefixes from anywhere on the campuses).

Is it feasible to think of having a flag per VRF that enables a kind of "JOIN" of tables (global and specific VRF) when determining uniqueness of a prefix?

I understand that there might open a discussion (as suggested by angely.pro) whether or not to permit this "JOIN" of different tables one between another. I would see it as a kind of a VRF selection tool in each VRF, but this is way more advanced.

Please share your thought on this approach.

Regards

Lukasz

[Angély -]

Hello Lukasz,

Sorry for late reply, I hope you will see it anyway.

I think the point here is the real handling of VRF RT import/export (issue #259).

A simple “join” is tempting but it would only cover full-mesh topology (where all specified VRFs import/export each other).

As mentioned in the first message of the issue #259, we decided to duplicate the prefixes in the VRFs.

And also in the GRT in our case.  Why that?

Because even if we have different VRFs for traffic segmentation purposes, our backbone IP plan is unique no matter what the VRFs (to prevent overlapping).

As suggested by Brian, we set the ENFORCE_GLOBAL_UNIQUE to true.

The GRT is the real entry point and it ensures uniqueness.

For our customers' however, we only create prefixes in their VRFs and not the GRT.

It works but prefixes/IP addresses must be created multiple times, so scripting is necessary for creation and deletion.

Regards.

[Brian Candler]

ISTM there are two requirements:

- recording a VRF tag to be used on an address/prefix

- allowing overlapping addresses (i.e. the concept of an address 'namespace')

If you had to label every single address and prefix with both "VRF" and "namespace", I think it would be painful and error-prone.

Would it meet people's requirements to make the namespace a property of the VRF? e.g.

VRF (none) namespace (none)  = global table

VRF "foo" namespace (none) = a different VRF, but addresses cannot overlap with global table

VRF "bar" namespace "bar" = another VRF, where addresses *can* overlap with global table

VRF "baz" namespace "bar" = another VRF, where addresses can overlap with global table but not with VRF "bar"

Then you'd associate an address or prefix with a VRF as today, and the namespace would be inherited from the VRF.

(Might be tricky enforcing namespace at the database level though - especially if you change the namespace on an existing VRF)

[Angély -]

Hello Brian,

Yes, the "namespace" attribute could do the trick.

Actually, I see it more as an "L3VPN" attribute: if some VRFs share the same namespace, it certainly means there are some RT import/export behind.

Now, in our case, some prefixes in a VRF are part of the global namespace and some others (in the same VRF) are part of the customer namespace.

So to cover this complexity, this has to be based on prefix/IP address and not only VRF.

For the moment, I'm creating prefixes/IP addresses both in the GRT and the VRF because I want to leverage the existing overlapping checking.

Thanks for your thoughts.

[LuPo]

Thank you Brian and Angely for the clarification and suggestions.

I missed the discussion on RT import/export (#239), certainly it would be a great feature, for which I see use case in our environment as well. Your straightforward idea of namespaces seams to me complementary to the broader feature of RT import/export and immediately applicable in our environment as a viable solution. I see though, the more specific case of Angely.

I started to fill in prefixes in both global and VRF tables as well, using some python code it is not a problem. Right now I am adapting those scripts to leverage recent "custom scripts" feature.

thank you

Lukasz

[Angély -]

Hello again,

Afterthought, the namespace solution you suggest seems enough to me for most of use cases.

Duplicating each prefix/IP address is difficult to maintain.

We can add the namespace as a custom field in the VRF but it won't be of much use for the prefix/IP address reservation through the WebUI.

We'll have to script the reservation ourselves to ensure uniqueness in the namespace, right?

Or did you suggest this solution for an upcoming feature?

Then you'd associate an address or prefix with a VRF as today, and the namespace would be inherited from the VRF. 

(Might be tricky enforcing namespace at the database level though - especially if you change the namespace on an existing VRF)

I doubt it is necessary to inherit the namespace from the VRF to the prefixes/IP addresses.

If a VRF belongs to a namespace and a prefix belongs to this VRF, then we know the prefix belongs to the namespace.

Why add any more complexity?

Anyway, thanks for the idea.

I think it would cover the L3VPN needs without RT import/export inventory.

Le jeudi 19 septembre 2019 13:32:03 UTC+2, Brian Candler a écrit :