Netbox nomenclature.

[USQ-CJD]

In regards to Netbox's nomenclature, what would be the best way to interpret Sites, Regions, Site Groups, Locations and Tenants to a single organisational structure with multiple campuses, multiple buildings, multiple floors, data centres, comms rooms and racks?

[candlerb]

It's entirely up to you.

Locations are recursive within a Site. So you can use Locations to represent rooms; or you can use them to represent buildings containing floors containing rooms containing closets. The structure is fully flexible, so a particular room does not have to contain a closet for example.

Regions are recursive above a Site. These typically represent geographical aggregations such as districts, cities, counties, countries, continents.

The key things which are not recursively defined, i.e. don't have a multi-level parent-child hierarchy, are:

• Site
• Rack
• Device [note 1]

Hence the most important decision you have to make is what is a "Site". You could pick whatever has its own a postal address, although I understand that in a large campus, each main building might have its own postal address. From the point of view of Netbox, normally I would choose "site" to match "the (local campus) network", because Netbox makes it easy to scope VLANs and Prefixes to a Site. However, Netbox does now allow VLANs to be scoped to regions or locations too. (You may find some issues though if you scope some VLANs to Site and others to Location or Region).

Site Groups are an awkward one. A Site can only belong to a single Site Group, just as it can only belong to a single Region. I haven't used them myself, but they could be used to represent a collection of sites which are logically grouped, as opposed to geographically grouped.

Tenants are logical and cross-cutting. In a university campus you might use them to represent administrative units which own resources (e.g. departments) or which manage resources (e.g. teams). In the latter case you could use this to determine who gets notifications of problems with a device, although you could also use Contacts for that.

Groups don't always work the way you'd expect or like. For example, I believe it's true to say that you can assign a device to a single Tenant, but not a Tenant Group [note 2]. You can assign it to multiple Contacts, but not to a Contact Group.

---

[note 1]: Devices do have "device bays" which can hold other devices, where the "device bay" is a component of the "parent" and the enclosed device is the "child". This is primarily intended for modelling blade servers, which are independent devices that happen to share a chassis. They can be used for passive modelling too, e.g. where two devices share the same 1U of rack space side by side. I have used them for modelling modular patch panels like these, where the cassettes are child devices.

[note 2]: "Tenant Group" is shown in the UI when creating or editing a device, but I believe this is just for filtering the list of Tenants visible in the adjacent dropdown.

[USQ-CJD]

Thank you for your reply, but it is kind of disappointing that there isn't any documentation on how to setup Nebox for just a single institution.

[gdprdatasubect]

I really depends on how you want to use it and what your organizational structure dictates.

We use one Site per Campus (even if the individual buildings have different addresses) and have the rest modeled via locations.
Depending on how you administratively differentiate between all your objects it might be a good idea to just recreate that as good as possible. "Regions" don't even have to be physical regions, they can be your administrative regions too.