In this post I am going to show you how to use NetBox as a Source of Truth for Network Automation.
What Source of Truth means in network automation
In network automation, a “Source of Truth” is the single, authoritative place where accurate network data lives. A centralised, authoritative repository containing the intended state of the network, including device inventories, IP addresses, and configurations. It defines what the network should look like rather than what the network happens to be doing at any given moment. Network Automation systems rely on this trusted data to generate configurations, validate state, and detect drift. Without a clear Source of Truth, automation becomes fragile, inconsistent, and error-prone. By centralising and standardising network information, teams reduce manual work, improve reliability, and ensure changes are intentional, repeatable, and aligned with design and policy.
What data should live in NetBox (and what should not)
The first thing to consider when setting up Netbox is what data should live in Netbox and what data should not.
NetBox should store authoritative, intent-level, slowly changing data.
It should not store:
- Ephemeral state
- Vendor-specific rendered configuration
- Anything discovered from the network that can change without intent
If a value answers “what should exist?” → NetBox
If it answers “what is happening right now?” → somewhere else
Data That Should Live in NetBox
1. Physical & Logical Inventory (Authoritative)
NetBox excels at inventory — especially when humans and automation both need to trust it.
Examples:
- Sites, regions, locations
- Racks and device placement
- Devices, device types, and platforms
- Interface definitions (names, types, speeds)
- Power connections
Why:
This data rarely changes and is foundational for all automation workflows.
2. Network Intent (Not Rendered Config)
Store what you want the network to look like, not how the vendor implements it.
Good NetBox data:
- VLANs and VLAN groups
- IP prefixes and allocations
- VRFs
- ASN assignments
- Interface roles (e.g. access, trunk, uplink)
- High-level routing intent (e.g. “this device participates in BGP”)
Bad NetBox data:
router bgp 65001neighbor 10.0.0.1 remote-as 65002
Rule of thumb:
If it’s vendor-neutral intent → NetBox
If it’s vendor syntax → templates
3. IP Address Management (IPAM)
This is NetBox’s strongest area and should almost always be authoritative.
Store in NetBox:
- Prefixes and hierarchy
- Address assignments
- IP roles (gateway, loopback, VIP)
- VRF separation
- Allocation status (active, reserved, deprecated)
Avoid:
- Learned ARP tables
- DHCP leases
- Interface operational IPs discovered via SNMP
4. Metadata That Drives Automation
NetBox is excellent at holding metadata that makes automation decisions possible.
Examples:
- Device roles
- Tags (e.g.
edge,leaf,prod) - Custom fields (sparingly!)
- Tenant and environment data
- Lifecycle state (planned, active, decommissioned)
Automation use cases:
- “Apply this config only to devices with role=leaf”
- “Generate BGP only for devices tagged
wan”
5. Cross-Domain Relationships
NetBox shines when relationships matter more than raw data.
Examples:
- Which device belongs to which site
- Which prefix belongs to which VRF
- Which interface connects to which peer
- Which tenant owns which network
These relationships are extremely hard to infer reliably from the live network.
Data That Should Not Live in NetBox
1. Live / Operational State
NetBox is not a monitoring system.
Do NOT store:
- Interface up/down state
- BGP neighbor status
- MAC tables
- CPU / memory usage
- Link utilization
Better tools:
SNMP, streaming telemetry, Prometheus, InfluxDB, Grafana
2. Rendered or Vendor-Specific Configuration
NetBox is not a config repository.
Avoid storing:
- Full device configs
- CLI snippets
- Vendor-specific commands
- Generated templates
Instead:
- Store intent in NetBox
- Render configs using Jinja2 / Ansible / Nornir
- Store rendered configs in Git (if needed)
3. Discovered Data Without Human Validation
Just because you can import it doesn’t mean you should.
Examples to avoid:
- Auto-imported interface descriptions
- Learned VLANs from switches
- Discovered neighbors written back blindly
Why:
Discovered data ≠ intent
It can overwrite carefully curated models and break automation trust.
4. Highly Volatile or Ephemeral Data
If it changes frequently without human intent, it doesn’t belong in a Source of Truth.
Examples:
- Temporary IP assignments
- Lab test configs
- Short-lived tunnel endpoints
- Failover states
5. Secrets and Credentials
NetBox is not a secrets manager.
Never store:
- Passwords
- SNMP communities
- API tokens
- Private keys
Use instead:
Vault, 1Password, AWS Secrets Manager, Azure Key Vault
When deciding whether data belongs in NetBox, ask:
- Is this authoritative?
- Is it vendor-neutral?
- Does it change only when humans intend it to?
- Will automation break if this data is wrong?
If the answer is yes to most of these → NetBox
If not → another system
Leave a Reply