Best practice for campus-spanning VLANs and prefixes

[heiko-ma]

Hello guys,

I have a question about the best practice of implementing VLANs and prefixes which are present in more than one site but are one logical unit.
Below you can find a quick sketch so you can understand my problem:

The VLAN 150 as well as the prefix 10.1.0.0/24 is present on 3 different sites but the hosts in those VLAN/prefix are in one L2 topology.

Until now, I've created a "pseudo site" which contains both the VLAN and the prefix but the physical devices are unable to use this VLAN if I do so.

My other possibility is to create a site group which consists of both the physical and the pseudo sites. I then create a VLAN group and attach it to the newly created site group. Then I'm able to use the VLANs attached to the group on the whole campus. As described in #10104 , I'm lastly able to connect the prefix to this construct.

This works, but I wonder if this is the best approach to design this kind of structure. Do you have similar setups and how did you implement them into netbox?

[xkilian]

Our solution: global vlans not attached to a site scoped limited by a VRF.
If the vlan handles the same function it can be re-used in different equipment, if it is a different function assign a new vlan #. We use the vlan function of netbox primarly to document function of vlans and their association to L3 devices, and not apply artificial constraints to vlan assignment to devices/sites. We have the same issue with vlans spanning two Sites, so could not use the "site" constraints. Site groupes made no sense to us, As some intermediate sites could have vlans from L3 devices in two different sites.
Ex. Site A --physical tunnel-- Site B(containing vlan 3 from site A and C in two independant switches) --physical tunnel-- Site C

We also have some L2 underlays spanning multiple sites, currently they are just defined in the global vlan list with a special description. We have not yet looked at the new L2VPN model, but that is on our radar so that that we can correctly model our different underlay and overlay networks.

[candlerb]

Site C(containing vlan 3 from site B and A in two independant switches)

Maybe I'm misunderstanding you, but if vlan 3 in site A and vlan 3 in site B are different broadcast domains, then you should create two separate VLAN objects in Netbox, both with ID 3.

[xkilian]

Yeah, but the devices in site B (sorry I renamed them to be sequential) have vlan 3 from the two adjoining sites.

[xkilian]

Yes, but as you known, once they are assigned to a a site, they cannot be re-used in a second site (B in the middle).

[candlerb]

What Netbox version are you using?

I've not needed to use this functionality myself, but I thought it was possible to:

1. Create a Site Group containing sites A, B and C
2. Create a VLAN Group which is scoped to the Site Group from (1)
3. Add VLAN 150 to the VLAN Group from (2)

This might have some limitations though - e.g. if you search for VLANs in Site A, it's possible you may not see Vlan 150. (I had a similar issue with #9989, although that was about Locations within a Site, rather than Sites within a Site Group)

[xkilian]

I believe there is also a limitation in that a site cannot be a member of two Site groups. See my example above with an intermediate physical site that has switches belonging logically to site A and C.

[heiko-ma]

I'm currently going with this solution, I created a VLAN Group containing all 3 physical sites and my pseudo sites. The reason I need those pseudo sites are not the VLANs but the prefixes. As far as I know, a prefix only can be attached to a site, not to a site group.

Maybe a feature request implementing "Prefix groups" using the same logic as VLAN groups would be beneficial for this problem?

[xkilian]

Here is how we did it in more detail:
Create global vlan, assign the vlan to a vlan group, put the description of the function of the vlan
The scope of the vlan group is meant to be the same as the VRF (logical environment typically limited by a border device like a firewall or routers actually implementing VRFs)
Create the prefix, assign it to vlan, only add a description if it has a non standard vlan role (ex. overlay or underlay), L3device custom field should be added with the name of the router/routers associated with the prefix. Use a standard naming convention for routers so that consistency is present. (All prefixes are typically associated with routers!)
So our vlans, vlan groups, prefixes are NEVER associated with sites, only actual physical devices are placed in sites.

Hope this helps. Went through a lot of thinking to get a model that fits all of our toplogies and constraints, and that is the best we came up with. We have large MAN with multiple datacenters and underlays (and some overlays). Open to suggestions! Campus architectures are very similar to MAN setups, so you are probably facing similar issues. ;-)

[heiko-ma]

Interesting approach, I need to discuss this with my network colleague.
Did you know that you can change the L3device custom field type to object? This way you can really link the prefix to the device and don't have to use text-fields.
This could look like this:

[xkilian]

Nope, I did not know! This is a new feature of 3.2.x or 3.3 I think. That is really interesting. We will also take a look at that. Much cleaner. As long as we can search for the objects associated in the custom-field.
It also goes without saying that the L3device names or objects names need to have a good naming convention.

[xkilian]

Also, the prefix table needs to display the "L3device" custom-field so that it can be filtered on and searched for.
Cheers,