The Nautobot Data Model models your network using a few core objects, the most important ones are Sites, Locations, Devices, Device Types, Interfaces, IP Addresses and Prefixes.
Each object represents something real in your network and together they form a hierarchy that describes your infrastructure.
Why a Source of Truth Matters
Traditionally network information is scattered across spreadsheets, diagrams, monitoring tools & configuration files.
This creates a problem:
You end up with inconsistent data, outdated documentation and more importantly automation scripts that break.
A Source of Truth solves this by creating a single authoritative database for your network.
Automation tools like Ansible, Python scripts, or CI pipelines can then query Nautobot for accurate network data.
But for that to work, Nautobot needs a structured way to represent networks.
And that’s where the data model comes in.
Core Nautobot Objects
At a high level, Nautobot models your network using a few core objects.
The most important ones are:
- Locations
- Devices
- Device Types
- Interfaces
- IP Addresses
- Prefixes
You can think of these as building blocks, each object represents something real in your network and together they form a hierarchy that describes your infrastructure. Let’s start at the top.
Locations & Location Types
The highest level in the Nautobot model is Locations, a Location represents a physical location in your network.
Examples might include:
- Data Centre
- Office
- Branch Location
- Edge Location
An example Location might be London DC or New York DC it can also be UK or North West
Within Locations you can also define Location Types – this can be named whatever you wish e.g Region or Site
Locations allow you to break a site down further into things like:
- Buildings
- Floors
- Network Rooms
- Racks
An example hierarchy starts to look this this:
Locations → New York DC → Device
Devices and Device Types
Next we have Devices, devices represent the actual network equipment.
Examples include:
- Routers
- Switches
- Firewalls
- Load Balancers
Each device is created from a Device Type
A Device Type defines things like:
- Vendor
- Model
- Number of interfaces
- Hardware characteristics
For example you might define device types like:
- Cisco Catalyst 9300
- Arista 7050
- Juniper SRX
Then when you create a device in Nautobot you select the device type.
This keeps your inventory consistent and scalable. You also associate each device with:
- a Site
- a Location
- a Role e.g Core, Access, PE etc
Interfaces and Connectivity
Once devices exist in Nautobot, the next level down is interfaces. Interfaces represent the actual ports on your devices.
Examples include:
- Ethernet interfaces
- Loopback interfaces
- Port channels
- VLAN interfaces
Each device contains its own list of interfaces.
Interfaces can then be connected together using cables inside Nautobot.
IP Address Management (IPAM)
Another major part of the Nautobot data model is IP Address Management, often called IPAM.
This is where Nautobot tracks:
- prefixes
- subnets
- IP addresses
- VRFs
For example you might define a prefix like:
10.0.0.0/24
Then assign specific IP addresses to device interfaces.
For example:
Router1 Loopback0 → 10.0.0.1
This creates a relationship between:
Interface → IP Address → Prefix.
Now Nautobot understands both:
- the physical network
- the logical addressing plan.
And this becomes incredibly powerful for automation.
How Everything Connects Together
Let’s quickly visualise the full model.
At the top you have:
Site
Inside that you have:
Locations
Inside locations you have:
Devices
Devices contain:
Interfaces
Interfaces can have:
IP addresses
And interfaces can connect to other interfaces.
So Nautobot effectively builds a graph of your entire network infrastructure.
Once that data exists, automation tools can query Nautobot to answer questions like:
- What devices exist in a site?
- What interfaces are connected?
- What IP addresses are assigned?
- What devices belong to a specific role?
Understanding this model is critical because every automation workflow in Nautobot depends on this data structure.
This is why Nautobot is so powerful as a network automation platform.
Leave a Reply