What Is Nautobot Device Onboarding?
Nautobot Device Onboarding is a Nautobot app that automates the discovery and initial population of network devices into Nautobot, turning existing network infrastructure into structured, usable source-of-truth data.
https://docs.nautobot.com/projects/device-onboarding/en/latest
To onboard devices in Nautobot, I am going to use the nautobot-device-onboarding app via its dedicated jobs, like Sync Devices From Network and Sync Network Data From Network, which leverage Netmiko/NAPALM to automatically discover and populate device details (IPs, Interfaces, VLANs) from your network using just an IP/Hostname and Location, simplifying data entry significantly. You can find these under the Jobs menu in the Nautobot UI, or manually create devices by defining their core attributes like Name, Role, Type, and Location in the Devices section first.
Prerequisites for Nautobot Device Onboarding
✔ Nautobot installed and running
✔ Device Onboarding app enabled
✔ SSH/API access to devices
✔ Valid credentials configured
✔ Supported network OS
✔ Sites and metadata created
✔ Permissions to run jobs
✔ Python drivers installed
How Nautobot Device Onboarding Works
At a mechanical level, Nautobot Device Onboarding is a job-driven discovery workflow that connects to network devices, collects live operational data, normalizes it, and maps it into Nautobot’s data models.
It is a one-time or ad-hoc discovery process, not a continuous polling system.
1. Device Onboarding Is Triggered as a Nautobot Job
Device Onboarding runs as a Nautobot Job, which means:
- It is executed:
- From the Nautobot UI
- Via the REST API
- Or via automation (e.g., CI/CD)
- It runs asynchronously using Nautobot workers
- All actions are logged and auditable
Mechanically:
- A job instance is created
- Input parameters are passed (IP, hostname, site, role, credentials, etc.)
- The job execution context controls permissions and scope
2. Nautobot Establishes a Connection to the Device
Once the job starts:
- Nautobot attempts to connect to the device using:
- SSH (most common)
- Or API access if supported
- Connection handling is delegated to:
- NAPALM
- Netmiko
- Platform-specific drivers
What happens here:
- Device OS and platform are identified
- Connection validation occurs
- Failures stop the process early with clear error output
3. Live Device Data Is Collected (Discovery Phase)
After a successful connection, Nautobot pulls operational data from the device.
Typical data collected includes:
- Hostname
- Serial number
- Device model and vendor
- OS version
- Interface list and status
- Interface MAC addresses
- IP addresses (IPv4/IPv6)
- VLAN membership (where supported)
Important detail:
This data reflects the current running state of the device, not intended state.
4. Data Is Normalised and Translated
Raw device data is not written directly into Nautobot.
Instead:
- Platform-specific outputs are normalized
- Vendor-specific differences are abstracted
- Data is mapped to Nautobot’s internal object models
For example:
- A physical interface becomes a
dcim.Interface - An IP address becomes an
ipam.IPAddress - The device itself becomes a
dcim.Device
This normalization is what allows multi-vendor onboarding.
5. Nautobot Matches or Creates Core Objects
Next, Nautobot decides whether to create or update objects.
Device Matching Logic:
- If the device already exists:
- Update allowed attributes
- Skip protected fields
- If it does not exist:
- Create a new Device object
- Assign:
- Site
- Role
- Device Type
- Manufacturer
Device Types:
- Can be auto-created
- Or matched to existing types depending on configuration
6. Interfaces and IP Addresses Are Created or Updated
Once the device exists:
- Interfaces are created or updated:
- Physical interfaces
- Logical interfaces (VLANs, loopbacks)
- IP addresses are:
- Created in IPAM
- Assigned to interfaces
- Marked with appropriate status
Key behavior:
- Onboarding typically adds missing data
- It avoids deleting existing objects unless explicitly configured
7. Data Validation and Conflict Handling
Before committing changes:
- Nautobot enforces:
- Uniqueness constraints
- Required fields
- Relationship rules
- Conflicts are logged, not silently ignored
Examples:
- Duplicate serial numbers
- IP conflicts
- Missing required metadata
Failures at this stage prevent partial or corrupt data ingestion.
8. Data Is Written to the Nautobot Database
After validation:
- Objects are committed to the database
- Relationships are finalized
- Transaction boundaries prevent partial writes
This ensures:
- Data consistency
- Atomic updates
- Clean rollback on failure
9. Job Results Are Logged and Exposed
After completion:
- Job output shows:
- Created objects
- Updated objects
- Skipped objects
- Errors and warnings
- Results are stored for audit and troubleshooting
This is critical for:
- Compliance
- Change tracking
- CI/CD integration
10. Nautobot Becomes the Source of Truth
At the end of the process:
- Discovered data becomes authoritative in Nautobot
- Teams can now:
- Generate configs
- Run compliance checks
- Feed automation tools
- Enforce validation rules
Leave a Reply