Source of truth: IPAM and DCIM tools such as NetBox and why they matter

The problem: many versions of the truth

In many organisations, IP addresses live in a spreadsheet, rack layouts in a drawing, device lists in the monitoring system and the real answer only on the devices. They drift apart, and nobody knows which to trust. Automation makes this worse: if a script reads the wrong spreadsheet, it pushes the wrong configuration everywhere. A source of truth (SoT) solves this by being the single, agreed place that records the intended state of the network.

IPAM, DCIM and NetBox

• IPAM (IP address management) tracks aggregates, prefixes, VLANs, VRFs (virtual routing and forwarding instances) and individual addresses.
• DCIM (data centre infrastructure management) tracks sites, racks, device types, devices, interfaces, power and cables.

NetBox is a widely used open-source tool that combines both, with a web interface and a full REST API. Nautobot, which began as a fork of NetBox, offers a similar model with its own app ecosystem. Commercial IPAM and DDI (DNS, DHCP and IPAM) products exist too. The tool matters less than the discipline of keeping one source authoritative.

Querying NetBox from Python

The pynetbox library wraps the NetBox API. Create an API token for a service account with only the permissions it needs, and load it from an environment variable.

import os
import pynetbox

nb = pynetbox.api("https://netbox.example.com", token=os.environ["NETBOX_TOKEN"])

for dev in nb.dcim.devices.filter(site="london", role="access-switch"):
    ip = dev.primary_ip4.address if dev.primary_ip4 else "no IP"
    print(dev.name, dev.platform, ip)

prefix = nb.ipam.prefixes.get(prefix="192.168.10.0/24")
free = prefix.available_ips.list()
print("Next free address:", free[0] if free else "none")

The same data can feed a Jinja2 template, a Nornir inventory (through the nornir_netbox plugin) or an Ansible dynamic inventory.

Working with intent

The golden rule is that changes start in the SoT. If an engineer changes a device directly, the next automated run will either undo it or report it as drift. That is a feature: it forces changes through review.

1. Import existing data carefully and clean it up; bad data in means bad config out.
2. Decide which system owns which data, for example NetBox for addresses and the HR system for staff.
3. Lock down write access and require change tickets for edits.
4. Generate configuration from the SoT for one small area first.
5. Run regular reports comparing live devices with intended state.

Tip: the SoT is now a high-value target. Anyone who can edit it can change the network through automation, so protect it with SSO (single sign-on), MFA (multi-factor authentication), role-based permissions, backups and audit logs.