search

dropbox / nsot

Network Source of Truth is an open source IPAM and network inventory database
https://nsot.readthedocs.io
Other
399 stars 66 forks source link

Native VRF / Route Distinguisher support #205

Open LukeDRussell opened 8 years ago

LukeDRussell commented 8 years ago

Hello,

Could you add native support for overlapping IP address space through Route Distinguishers?

In service provider or large enterprise, we need to be able to support overlapping IPs, but we also want to make sure we don't have overlaps within a RD/VRF.

A VPNV4 address is made up of the RD:IP. For example

65000:1:192.168.0.0/24 65000:2:192.168.0.0/24

Both could exist in the same device, but we still need to check that 192.168.0.0/24 only exists once in the 65000:1 VRF.

jathanism commented 8 years ago

@lukerussell Thanks for the feature request! I like this idea as something we can plan for.

I'd like to kickoff a discussion on how you might see this data used. As I don't have any direct experience using VRFs, if you could provide some conceptual modeled examples of devices, interfaces, vrfs and how they might be used, that would really help.

At a glance, it doesn't seem too complicated.

Assuming we have something like VRF(rd='65000:1', network='192.168.0.0/24'), where the representation would be 65000:1:192.168.0.0/24, then we'd also be able to do the inverse where we could look up all VRFs for a Network.

coxley commented 8 years ago

The VRF resources should be keyed by VRF(rd='65000:1', name='Blue') with a network in a VRF being keyed Network(network='10.0.0.0', prefix_length=24, rd='65000:1')

RD should always be 8 bytes and can be formatted in one of 3 ways:

For how we want to implement the network-keying part I'm unsure. At first glance I thought we could default a hidden null RD which could still work.

LukeDRussell commented 8 years ago

Well we need a hidden/null VRF for the global routing table as well anyway, so that would work.

On 25 May 2016, at 11:46, Codey Oxley notifications@github.com<mailto:notifications@github.com> wrote:

The VRF resources should be keyed by VRF(rd='65000:1', name='Blue') with a network in a VRF being keyed Network(network='10.0.0.0', prefix_length=24, rd='65000:1')

RD should always be 8 bytes and can be formatted in one of 3 ways:

For how we want to implement the network-keying part I'm unsure. At first glance I thought we could default a hidden null RD which could still work.

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHubhttps://github.com/dropbox/nsot/issues/205#issuecomment-221451941

jathanism commented 8 years ago

@coxley: I was thinking it would be better to have a relationship to an existing Network object from the VRF object, vs. having a hard-field on the Network.

jathanism commented 8 years ago

@lukerussell: Can you clarify what you mean by a hidden/null VRF for the global routing table? How is that represented?

coxley commented 8 years ago

I should look and see what you're doing to keep network resources unique, but if you don't change how the networks are keyed how could you have multiple with the same address and prefix_length?

jathanism commented 8 years ago

@coxley: Think of it the other way. A Network being able to be associated with multiple VRFs. (From database it's VRF having a foreign key to a Network). We'd then be able to look up the relationship both directions.

coxley commented 8 years ago

I see. The same network prefix between one VRF and another could be used for different purposes and thus might want to have different attributes, description, etc.

Maybe this is unimportant, maybe not.

LukeDRussell commented 8 years ago

Networks should not be able to be part of multiple VRFs - there could be overlaps, different mask lengths, same mask lengths and it would probably screw with auditing and reporting down the track.

Think about it this way - Let's say 192.168.0.0/24 exists in three seperate VPNs/networks/VRFs. I should have three seperate network objects in the database because they really are three seperate networks. On a router I can't assign more than one VPNV4 network per interface. I.E. I need a sub-interface per VPN at the MPLS to IP boundary.

So I have a device, it has multiple logical sub-interfaces, each sub-interface has a VPNV4 network attached.

One obvious use case is that I want an operator to be able to search for a straight IP subnet and get that network in all RDs. I want to also be able to search for a specific VPNV4 network, or all networks within an RD.

I'm not enough of programer to even know where to look in the code to see what your database structure looks like. But looking at your documentation again, I like @coxley 's idea for the hard coded RD field for every network. The default value for RD field for existing and newly created networks would be 'none', noting that 0:0 is a valid RD.

I'm going with 'RD' being the key because the RD is transitive - the VRF name is locally significant to the device only (although of course you usually make your VRF name the same on every device).

jathanism commented 8 years ago

@lukerussell: This is really helpful, thank you.

Without boring you too much on the database-level details, I think that we're actually saying the same thing as far as implementation goes. I can't prioritize this right now but it's definitely something I want to get to after the web UI work has been caught up! :)