If you are reading this, you are about to populate Nautobot with data that will power your NVIDIA Config Manager network automation. This guide walks you through the core concepts and objects you will work with, and by the end, you will understand how all the pieces fit together and be ready to create your first dataset.
Nautobot is a network source of truth and network automation platform. In the Config Manager ecosystem, Nautobot serves as the central repository for all information about your network infrastructure:
Config Manager installs several Nautobot apps which extend the functionality of Nautobot to support Config Manager’s specific needs. In particular, the Field Serviceable Units (FSUs) and NVDataModels apps model NVIDIA’s high-performance compute resources.
When you populate Nautobot, you create a structured, queryable representation of your network that Config Manager automation workflows can use to:
Continue to the Nautobot Integration page to learn how Config Manager interacts with Nautobot.
Config Manager uses YAML files to define bootstrap data that gets loaded into Nautobot through the LoadBootstrapData job. Here is the flow:
data/ directory, organized by schema type (manufacturers, device types, locations, and so on)LoadBootstrapData job in NautobotThe beauty of this approach is that your infrastructure definition lives in version-controlled YAML files, making it easy to review changes, collaborate with teammates, and maintain consistency across environments.
Before diving into the details, take a moment to understand how the physical world maps to Nautobot objects.
Think about how you would describe your datacenter to someone:
Beyond the physical, you need to define how devices are configured:
Let’s walk through the building blocks. Understanding these objects and their attributes is key to working with Config Manager and Nautobot.
Schema reference: Devices & Device Types
What they are:
Why they matter: Devices are the core objects that everything else supports. They are what you are actually managing, configuring, and monitoring. When you create a device in Nautobot, you specify its device type, which defines physical characteristics like how many ports it has, what kind of ports (Ethernet, Infiniband, and so on), power requirements, rack space, and more.
Key distinction:
Example: A network switch named “spine-01” with serial number ABC123, located in Rack 1, Site DataCenter-1, of device type “SN5600” (which defines it has 64 ports, specific power requirements, and 2U rack height), with role “Spine”, running “Cumulus Linux”. Config Manager would generate and deploy configuration for this switch. Or a GPU server named “dgx-01” with serial number XYZ789, located in Rack 2, of device type “DGX H100”—tracked for topology and cabling but not configured by Config Manager.
Quick tip: Devices are not created by ZTP. Create device inventory before provisioning by using the Nautobot UI, Nautobot API, bulk import, migration scripts, or a Design Builder topology job. Device types ARE defined in bootstrap data and must exist before you can create devices. Device types are organized in subdirectories by manufacturer: data/device_types/NVIDIA/SN5600.yaml
Schema reference: Location Types and Locations
What they are: Physical rack enclosures where you mount your equipment. Racks have a height (typically 42U), a location, and can track which rack units (RUs) are occupied by which devices.
Why they matter: Racks are where devices physically live. They provide the connection between your location hierarchy and your actual equipment. When you create a device, you specify which rack it goes in and which rack units it occupies. This helps datacenter operators know exactly where to install equipment and helps you visualize rack elevation and space utilization.
Example: “Rack-01” in location “DataCenter-1”, 42U height, with “spine-01” occupying units 1-2 (because it is 2U high) and “leaf-01” occupying units 3-4.
Quick tip: Racks belong to locations (typically Sites or Modules in your hierarchy). Define your location hierarchy before creating racks.
Schema reference: Roles
What they are: Functional roles that define what a device or interface does in your infrastructure. Device roles include network functions (Spine, Leaf, TOR, Border Leaf, Management Switch, and so on) and compute functions (GPU Server, Storage Node, and so on). Interface roles define port purposes (Uplink, Downlink, Management, Out-of-Band, and so on).
Why they matter: Roles are fundamental in Config Manager. For network devices, the device role determines which base configuration template gets applied. This is the primary mechanism for differentiating device configurations—a Spine gets different config than a Leaf or TOR switch. For compute and storage devices, roles help organize topology and reporting even though Config Manager does not configure them.
Common Device Role Examples:
Example: A device with role “Spine” gets spine-specific configuration templates with BGP settings for a Clos fabric. A device with role “Leaf” gets leaf templates with server-facing port configurations. A device with role “GPU Server” is tracked for topology but not configured by Config Manager.
Quick tip: Roles must specify the content types they apply to, including devices, interfaces, and so on. This is required in Nautobot.
Schema reference: Manufacturers
What they are: The companies that make your equipment—NVIDIA, Arista, Dell, and so on.
Why they matter: Device types and platforms reference manufacturers, and Config Manager uses this to organize device-specific templates and configurations.
Example: If you are deploying NVIDIA switches, you would create a manufacturer entry for “NVIDIA”.
Quick tip: Manufacturer names must match the directory names in your data/device_types/ folder for device types to associate correctly.
Schema reference: Platforms
What they are: The operating systems or software platforms that run on your devices—Cumulus Linux, NV-OS, Arista EOS, and so on.
Why they matter: Config Manager uses platforms to select the right configuration templates and apply platform-specific config contexts. A Cumulus Linux switch gets different template rendering than an Arista EOS switch.
Example: “Cumulus Linux” platform associated with the NVIDIA manufacturer.
Quick tip: Platforms are optional but highly recommended. They are crucial for template rendering and configuration management.
Schema reference: Tags
What they are: Flexible labels for categorization and filtering that can be applied to devices, interfaces, and other objects (production, test, dns-exempt, and so on).
Why they matter: Tags provide a flexible way to organize and filter objects beyond their structural attributes. They are used in automation workflows to control which devices are included or excluded from operations.
Quick tip: Tags can apply to multiple content types, making them versatile for cross-cutting concerns like operational state or automation control.
Schema reference: Statuses
What they are: Lifecycle states for your objects—Active, Planned, Maintenance, Decommissioned, Provisioning, Provisioned, and so on.
Why they matter: Statuses help you track where devices are in their lifecycle and control which devices are included in automation workflows. For example, cable validation typically runs against “Provisioned” devices.
Example: A device moves from “Planned” → “Provisioning” -> “Provisioned” (after ZTP) → “Active” (after validation).
Quick tip: Make sure you have an “Active” status, as it is the default for many operations.
Schema reference: Location Types and Locations
What they are:
Why they matter: Locations organize your physical infrastructure and help with multi-site deployments. Racks belong to locations, and devices go in racks.
Example hierarchy:
Quick tip: Define your location types before your locations, and define parent locations before child locations.
Schema reference: Tenants
What they are: Organizational units for grouping and isolating resources—think business units, customers, or projects.
Why they matter: If you are managing infrastructure for multiple teams or customers, tenants provide logical separation. Locations, devices, IP addresses, and other objects can be assigned to tenants.
Example: “Superpod” tenant for infrastructure devices, “NGC” tenant for GPU Cloud workloads.
Quick tip: Tenants are optional; if you are managing a single network, you might not need them.
Schema reference: Namespaces
What they are: Logical containers for IP addresses and VLANs that allow the same addresses to exist in different contexts.
Why they matter: Namespaces enable network isolation. You can have the same IP prefix in different namespaces without conflict (think VRFs, but at the IPAM level).
Example: “Global” namespace for shared infrastructure, “Superpod” namespace for pod-specific addressing.
Quick tip: Start with a single “Global” namespace if you are unsure. You can always add more later.
Schema reference: Namespaces
What they are: Virtual LANs that segment network traffic at Layer 2. VLANs have an ID (1-4094), a name, and belong to a namespace.
Why they matter: VLANs are fundamental to network segmentation. They define broadcast domains and are used extensively in switch configurations. Devices interfaces are often tagged with VLANs, and IP prefixes can be associated with VLANs to define gateway addressing.
Example: VLAN 100 named “Management” in namespace “Global”, VLAN 200 named “Storage” in namespace “Global”.
Quick tip: Like IP addresses, VLANs exist within namespaces, allowing the same VLAN ID to be reused in different contexts.
Schema reference: Namespaces
What they are: Routing tables that provide network isolation at Layer 3. VRFs allow overlapping IP address spaces by creating separate routing domains.
Why they matter: VRFs enable multi-tenancy and traffic isolation on the same physical infrastructure. They are commonly used to separate management, storage, and compute networks, or to provide isolated networks for different customers or tenants.
Example: VRF “management” for out-of-band management traffic, VRF “tenant-a” for customer A’s isolated network.
Quick tip: VRFs work with namespaces—prefixes and IP addresses can be assigned to specific VRFs within a namespace for complete routing isolation.
Schema reference: Config Contexts
What they are: JSON data structures that get applied to devices based on their attributes (role, platform, location, and so on).
Why they matter: Config contexts are the bridge between Nautobot data and your configuration templates. They provide device-specific variables that Jinja2 templates use to generate configurations.
Example: A config context that applies to all “Cumulus Linux” devices, providing default password mappings and intended firmware versions.
Quick tip: Config contexts have weights—lower weight = higher priority when multiple contexts apply to the same device.
Schema reference: Relationships
What they are: Custom associations between different object types in Nautobot beyond the built-in relationships.
Why they matter: Relationships let you model domain-specific connections that are not covered by Nautobot standard relationships. For example, you might want to explicitly link a prefix to its gateway IP address, or connect devices to external management systems.
Example: A “prefix-to-gateway” relationship that associates each prefix with its gateway IP address, making it easy to query which gateway serves which network.
When to use: Only create custom relationships when the built-in associations do not meet your needs. Most deployments can rely on standard Nautobot relationships (device-to-interface, interface-to-cable, interface-to-IP, and so on).
Quick tip: Relationships are advanced—start with built-in associations and add custom relationships only when you have a specific use case that requires them.
Let’s walk through creating a minimal dataset for a simple deployment: a small site with two spine switches.
Create data/manufacturers.yaml:
Create data/device_types/NVIDIA/SN5600.yaml:
About bracket notation: The swp[1-64] syntax is a convenient shorthand that creates 64 interfaces named swp1, swp2, swp3, … swp64. This bracket notation works anywhere you define interface names and saves you from listing each port individually. You can also use it for other components like PSU[1-2] or qsfp[1-32].
About optional components: Device types can include several optional components beyond interfaces: console_ports for serial console access, power_ports for power connections (PSU1, PSU2), and module_bays for modular expansion slots. These are useful for complete hardware modeling but not required for basic switch definitions. Note that only model, part_number, u_height, and is_full_depth are actually stored in Nautobot’s device type; other fields like weight, weight_unit, and comments are informational only and used for documentation purposes.
Create data/platforms.yaml:
Create data/roles.yaml:
Create data/statuses.yaml:
Create data/location_types.yaml:
Create data/locations.yaml:
Create data/tenants.yaml:
Create data/namespaces.yaml:
Now that you have your YAML files:
The job will process your files in dependency order and create all the objects in Nautobot.
After the job completes:
Most schemas support a deployment_types field. This lets you maintain a single repository with data for multiple deployment scenarios:
Set the NV_CONFIG_MANAGER_DEPLOYMENT_TYPE environment variable to control what gets loaded.
All field names in bootstrap YAML files use lowercase with underscores (snake_case):
Key conventions:
name or modelis_active: true for config contexts)true when not specified# symbol (for example, 2196f3) or Nautobot color names (for example, grey)When you run the LoadBootstrapData job multiple times, different object types behave differently:
Get or Create (creates only if it does not exist, does not update existing):
content_types are always updated even on existing roles)Update or Create (updates existing or creates new):
This means you can safely re-run the bootstrap job to add new items or update certain fields, but some objects will not be modified after they are created. If you need to change a manufacturer name or platform description, you will need to update it manually in Nautobot or delete and recreate it.
When referencing parent objects, you can use simple or complex lookups:
Simple (when names are unique):
Complex (when names might collide):
Roles, tags, and statuses must specify which Nautobot content types they apply to:
Config contexts can target devices by role, platform, location, or any combination:
Organize your data files logically:
You might notice that bootstrap data focuses on foundational objects like device types, roles, statuses, platforms, tenants, locations, and config contexts. Operational objects such as devices, interfaces, cables, prefixes, and IP addresses are usually loaded through a topology-specific workflow. For repeatable site data, use a Nautobot Design Builder job; for smaller changes, use the Nautobot UI, API scripts, CSV imports, or migration tooling.
How they are created:
What you need first: Before creating a device, you must have the following objects defined:
ZTP relationship: ZTP consumes existing Nautobot data; it does not create the device inventory. Before a switch boots for provisioning, Nautobot should already contain the device record, identifiers used by DHCP/ZTP, management interface data, and the config context required to render its startup configuration.
Example workflow: Load bootstrap data → run a Design Builder topology job for the site → verify devices, interfaces, IP addresses, and cables in Nautobot → power on the switch → DHCP/ZTP matches the booting switch to the existing Nautobot data and serves the provisioning artifacts.
How they are created:
What you need first: Devices and their interfaces must exist before you can cable them together.
Why they matter: Cables define the physical topology. The cable validation workflow compares this documented design with LLDP neighbor information from devices and reports mismatches before they cause problems.
Example: Connect interface “swp1” on “spine-01” to interface “swp49” on “leaf-01” with a cable labeled “CAB-001”.
How they are created:
What you need first:
Why they matter: Prefixes represent network ranges (like 10.1.0.0/24). They are essential for IP address management and help Config Manager understand your addressing scheme when generating configurations.
Example: Create prefix 10.1.0.0/24 in namespace “Global”, assigned to location “DataCenter-1”, with role “Loopback addresses” and status “Active”.
How they are created:
What you need first:
Why they matter: IP addresses are assigned to device interfaces for management, routing, and connectivity. They are crucial for device reachability and are used in generated configurations.
Example: Assign IP address 10.1.0.1/32 from prefix 10.1.0.0/24 to interface “lo” (loopback) on device “spine-01”, with role “Loopback” and status “Active”.
For a typical deployment, here is the order you would create these objects:
The bootstrap data you have learned about in this guide provides the foundation—the device types, roles, locations, and config contexts that these operational objects will use when they are created.
If you run into issues:
The key insight is that Nautobot data is hierarchical and interdependent. Start with the foundation (manufacturers, platforms, roles, statuses, locations), then build up to more complex objects (config contexts, relationships). Each layer builds on the previous layers.
Now that you understand the core concepts, here are some next steps:
Learn about Config Manager’s automation workflows: