Skip to content

Sites, Locations, and Racks


How you choose to employ sites when modeling your network may vary depending on the nature of your organization, but generally a site will equate to a building or campus. For example, a chain of banks might create a site to represent each of its branches, a site for its corporate headquarters, and two additional sites for its presence in two co-location facilities.

Each site must be assigned a unique name and operational status and may optionally be assigned to a region and/or tenant. The following operational statuses are available by default:

  • Planned
  • Staging
  • Active
  • Decommissioning
  • Retired

The site model also provides a facility ID field which can be used to annotate a facility ID (such as a data center name) associated with the site. Each site may also have an autonomous system (AS) number and time zone associated with it. (Time zones are provided by the pytz package.)

The site model also includes several fields for storing contact and address information as well as geo-location data (GPS coordinates).


In a future Nautobot release, sites may become just another Location Type, and the Site model may be collapsed into the Location model.


Sites can be arranged geographically using regions. A region might represent a continent, country, city, campus, or other area depending on your use case. Regions can be nested recursively to construct a hierarchy. For example, you might define several country regions, and within each of those several state or city regions to which sites are assigned.


In a future Nautobot release, regions may become another Location Type, and the Region model may be collapsed into the Location model.

Location Types

Added in version 1.4.0

Before defining individual Locations, you must first define the hierarchy of Location Types that you wish to use for the organization of your network. An example hierarchy might be Building ← Floor ← Room, but you might have more or fewer distinct types depending on your specific organizational requirements.

Each Location Type can define a set of "content types" that are permitted to associate to Locations of this type. For example, you might permit assigning Prefixes and VLAN Groups to an entire Building or Floor, but only allow Devices and Racks to be assigned to Rooms, never to a more abstract location. Doing so can help ensure consistency of your data.

Added in version 1.5.0

Location Types can now be marked as nestable. When this flag is set, Locations of this type may nest within one another, allowing for variable-depth hierarchies of Locations and reducing the number of distinct Location Types you may need to define. For example, with two Location Types, "Building Group" and "Building", by flagging "Building Group" as nestable, you could model the following hierarchy of Locations:

  • Main Campus (Building Group)
    • West Campus (Building Group)
      • Building A (Building)
      • Building B (Building)
    • East Campus (Building Group)
      • Building C (Building)
      • Building D (Building)
    • South Campus (Building Group)
      • Western South Campus (Building Group)
        • Building G (Building)
      • Eastern South Campus (Building Group)
        • Building H (Building)
  • Satellite Campus (Building Group)
    • Building Z (Building)


Although it is possible to define a "tree" of Location Types with multiple "branches", in the majority of cases doing so adds more unnecessary complexity than it's worth. Consider the following hypothetical Location Type tree:

Branch Office
  ↳ Branch Floor
      ↳ Branch Floor Room
  ↳ Branch Basement
      ↳ Branch Basement Room
  ↳ Headquarters Floor
      ↳ Headquarters Floor Room
  ↳ Headquarters Basement
      ↳ Headquarters Basement Room

This would complicate your life significantly when constructing queries, filters, and so forth to actually work with your data - for example, if you wanted a list of all Prefixes that are mapped to floors rather than individual rooms, you would now need to construct a query for Prefixes that are mapped to (a Branch Floor OR a Headquarters Floor OR a Branch Basement OR a Headquarters Basement). In most cases you would be better served with a far simpler "linear" sequence of Location Types, such as Building ← Floor ← Room; you could then use tags or custom fields to distinguish whether a given Building is a Branch Office or a Headquarters, if that distinction is even important to your network model.


Added in version 1.4.0

To locate network information more precisely than a Site defines, you can define a hierarchy of Locations within each Site. Data objects such as devices, prefixes, VLAN groups, etc. can thus be mapped or assigned to a specific building, wing, floor, room, etc. as appropriate to your needs.

Once you have defined the hierarchy of Location Types that you wish to use, you can then define Locations. Any "top-level" Locations (those whose Location Type has no parent) belong directly to a Site, while "child" Locations belong to their immediate parent Location, rather than to the Site as a whole.


At present, Locations fill the conceptual space between the more abstract Region and Site models and the more concrete Rack Group model. In a future Nautobot release, some or all of these other models may be collapsed into Locations. That is to say, in the future you might not deal with Regions and Sites as distinct models, but instead your Location Type hierarchy might include these higher-level categories, becoming something like Country ← City ← Site ← Building ← Floor ← Room.

Much like Sites, each Location must be assigned a name and operational status. The same default operational statuses are defined for Locations as for Sites, but as always, you can customize these to suit your needs. Locations can also be assigned to a tenant.


The rack model represents a physical two- or four-post equipment rack in which devices can be installed. Each rack must be assigned to a site, and may optionally be assigned to a location, rack group, and/or tenant. Racks can also be organized by user-defined functional roles.

Rack height is measured in rack units (U); racks are commonly between 42U and 48U tall, but Nautobot allows you to define racks of arbitrary height. A toggle is provided to indicate whether rack units are in ascending (from the ground up) or descending order.

Each rack is assigned a name and (optionally) a separate facility ID. This is helpful when leasing space in a data center your organization does not own: The facility will often assign a seemingly arbitrary ID to a rack (for example, "M204.313") whereas internally you refer to is simply as "R113." A unique serial number and asset tag may also be associated with each rack.

A rack must be designated as one of the following types:

  • 2-post frame
  • 4-post frame
  • 4-post cabinet
  • Wall-mounted frame
  • Wall-mounted cabinet

Similarly, each rack must be assigned an operational status. The following statuses are available by default:

  • Reserved
  • Available
  • Planned
  • Active
  • Deprecated

Each rack has two faces (front and rear) on which devices can be mounted. Rail-to-rail width may be 10, 19, 21, or 23 inches. The outer width and depth of a rack or cabinet can also be annotated in millimeters or inches.

Rack Groups

Racks can be organized into groups, which can be nested into themselves similar to regions. As with sites, how you choose to designate rack groups will depend on the nature of your organization.

Each rack group must be assigned to a parent site (and optionally also a more specific location within that site). Rack groups may optionally be nested within one another to model a multi-level hierarchy.

The name and facility ID of each rack within a group must be unique. (Racks not assigned to the same rack group may have identical names and/or facility IDs.)

Rack Roles

Each rack can optionally be assigned a user-defined functional role. For example, you might designate a rack for compute or storage resources, or to house co-located customer devices. Rack roles are fully customizable and may be color-coded.

Rack Reservations

Users can reserve specific units within a rack for future use. An arbitrary set of units within a rack can be associated with a single reservation, but reservations cannot span multiple racks. A description is required for each reservation, reservations may optionally be associated with a specific tenant.