Enable many-to-many site assignment for VLAN groups

[jeremystretch]

Environment

• Python version: 3.6.9
• NetBox version: 2.9.7

Proposed Functionality

Convert the current ForeignKey field assigning a VLANGroup to a site to a ManyToManyField, to allow the assignment of a VLANGroup to multiple sites.

Use Case

This change will allow the tracking of discrete L2 domain which extend beyond a single site. Today, this can be modeled only with the coarseness of a "global" VLANGroup (one which is not assigned to any site).

IMO this approach is preferable to allowing many-to-many assignment directly between VLANs and sites, because it provides a layer of abstraction for the domain. A user can add many VLANs to a multi-site VLANGroup without needing to ensure the correct multi-site assignment of each VLAN.

Database Changes

Change VLANGroup.site from a ForeignKey to a ManyToManyField, which results in the introduction of an intermediate table. The actual database migration would probably involve creating a new sites field, replicating all existing relations, and finally deleting the current site field.

External Dependencies

None

[anubisg1]

This is perfect, and should honestly be extend to vlans and prefixes

[jeremystretch]

@anubisg1 that wouldn't make any sense. a prefix can be assigned to only one L2 and/or L3 domain.

[anubisg1]

@jeremystretch prefix can only be assigned to a L2 (vlan) or a L3 (vrf) domain.
But such domains are not bound to sites.

A vlan, especially in DC environments, can exist across multiple physical sites.
I can have a DC in Milan and another in Rome, such vlans is extended between DCs via OTV or VXLAN.

This means that the same vlan (and the same IP subnet) actually exists on 2 (ore more) sites at the same time.

netbox fits perfectly for DCIM (Data Center Inventory Management) part, as a physical box can exist either here or there, but we really struggle to model DC networks and overlays.

maybe the simplest way would be to have the possibility to have an "overlay" object.
a vlan/subnet could be assigned to an overlay, then 1 or more sites could belong to the overlay.

i don't know exactly, but the problem remains, once a vlan moves outside of a physical site, the whole model breaks down

[jeremystretch]

Implementing this feature would obviate the need for mapping VLANs to multiple sites. It would also be unnecessary to map prefixes to multiple sites because we can infer that from their association to the multi-site L2 domain.

[xkilian]

If the overlay/underlay is an object, we associate its scope to devices and interfaces. (Terminology: underlay = ex. Shortest Path Bridging, Overlay= ex. Vxlan). The site an overlay/underlay is present in, should automatically be known(via the meta-data of the device attached to the overlay) and should not be manually associated with an overlay, IMO.

[jeremystretch]

After giving this some more thought, I wonder if it might be better to change the site foreign key to a scope generic foreign key, capable of assigning a VLANGroup to either a region, site, rack group, or rack. It might also be worthwhile to introduce a new SiteGroup model (edit: see #5892) to serve as a second dimension along which sites can be grouped (in addition to geographic region).

This approach would allow us to provide more flexibility around the establishment of a L2 domain while avoiding the headaches that come with many-to-many relationships.