Introduce a SiteGroup model to provide a secondary mechanism for classifying sites

[jeremystretch]

Environment

• Python version: 3.7.9
• NetBox version: 2.10.5

Proposed Functionality

Introduce a new SiteGroup model, recursively nested similar to Region. Each site can be assigned to both a region and a site group.

Use Case

As regions are intended for the geographic classification of sites (e.g. continent > country > city), site groups can be used to classify sites by function. Site groups also offer an attractive avenue for supporting more flexible L2/L3 domain scoping.

Database Changes

• Create a table for the SiteGroup model
• Add a ForeignKey field on Site to SiteGroup

External Dependencies

None

[ryanmerolle]

I like this approach, and I think it addresses current concerns with the model, BUT have you thought about calling it a "site role" instead to follow the consistency of other models (racks and devices)?

[jeremystretch]

Possibly. I think we've established two patterns of organizational models: "flat" (device roles, rack roles, etc.) and hierarchical (regions, rack groups, tenant groups). I like the hierarchical approach because it allows users to employ nesting. It might be beneficial to stick with the "group" naming for organizational models which support recursive hierarchy (via MPTT) for consistency.

(I know that the VLANGroup model is not hierarchical, but #5895 proposes renaming it for unrelated reasons.)

[networkhorse]

I think this would be quite nice. Personally I've resorted to putting roles on racks, but putting them on sites would be much nicer. My use case has been marking "Data Centre", "Field" or "Exchange" with respect to ISP network deployment. This way, we know what type of set up to expect.

[fischa]

I like the idea as well. Having an option for a "meta" grouping that is not geographical sounds promising 😄 But I also like the idea of roles for sites.

[bryanward-net]

For our campus network, we've run into some challenges surrounding the lack of ability to nest sites. Our network and geographical hierarchy is similar to:

-Main Campus
  -North
    -Building Group A
      -Building A1
      -Building A2
      -Building A3
    -Building Group B
      -Building B1
      -Building B2
    -Building C
    -Building D
  -South
    -Building Group E
      -Building E1
      -Building E2
    -Building Group F
      -Building F1
      -Building F2
      -Building F3
      -Building F4
    -Building G
    -Building H
-Remote Offices
  -Remote Office 1
  -Remote Office 2
  -Remote Office 3
  -Remote Office Group A
    -Remote Office A1
    -Remote Office A2

Where South and North would have distribution-layer routers, and each Building would have switches that connect to the distribution layer. However, all buildings in a Building Group would have several VLANs and config contexts in common with each other (such as building management devices, where the water pump in Building B1 needs to be Layer2 adjacent to the water pump in Building B2 - we span these VLANs between the buildings). Additionally, all buildings in a North/South level organization would also have several VLANs and config contexts in common with each other (such as for WiFi clients, to allow seamless roaming of a client device around that section of the campus).
I've managed to make this work by calling North and South each a Site in netbox, and then using VLAN Groups for each Building. But, I end up having to duplicate data between VLAN Groups.

Ideally, each building would be a Site, and then a Building Group could be this new proposed Site Group, and North/South could also be Site Groups. Inheritance would trickle down from the top-most level with lower levels overriding as necessary. Allowing for an arbitrary amount of nesting levels would be ideal.

For the Remote Offices, each Remote Office has the same VLAN IDs as each other (vlan 10 is data, vlan 11 is voice, vlan 12 is guest wifi, etc.) For now, I end up having to duplicate all these as well. That's not a bad thing, as technically VLAN 10 as it exists in Remote Office 1 is totally separate from VLAN 10 in Remote Office 2. I'm OK with these having to be created per-site, but it raises the question of how to enforce uniqueness of VLAN IDs within a Site or Site Group. I'd want to enforce unique VLAN IDs within the North and South Site Groups, but not within the Remote Offices Site group or the Main Campus Site Group.

For those who might ask "Why not use Regions?" - VLANs belong to Sites, not Regions. Using Regions would allow me to model the geographical hierarchy, but not the network one.

[jeremystretch]

VLANs belong to Sites, not Regions.

The assignment of a VLAN to a site is optional. You can have "global" VLANs available to all sites. #5284 seeks to provide more flexibility in this regard, however it is possible with the current release.