NetBox IPAM Guide: Model Prefixes, VLANs and IP Addresses

Spreadsheets stop scaling the moment your address plan has more than one site, and that is exactly when IP conflicts start costing outages. NetBox is the open-source source-of-truth for IPAM and DCIM, and its IP model is deliberately hierarchical: aggregates contain prefixes, prefixes nest inside each other, and IP addresses are arranged automatically underneath the prefix that matches them. This guide walks through modelling an address plan in NetBox, handling overlapping space with VRFs, keeping the data current through the REST API, and the workflow habits that keep the database trustworthy.

The IP hierarchy, and why it matters

Because the hierarchy is formed automatically, you never assign a parent manually - NetBox places 10.10.20.0/24 under 10.10.0.0/16 based purely on the addressing. Prefix utilisation reflects child objects: a Container prefix reports utilisation based on its child prefixes, while an active prefix reports utilisation based on the IP addresses and ranges assigned inside it.

Modelling a site end to end

1. Create the aggregate for the block in use, tied to the correct RIR.
2. Create VLAN groups scoped to the site, then the VLANs (IDs 10, 20, 30) with roles such as Data, Voice, Guest, Management.
3. Create prefixes with a functional role and status, and nest them under the aggregate.
4. Assign the VLAN to the prefix, so the L2 and L3 view stay linked.
5. Add IP ranges for DHCP scopes and mark them as pools.
6. Assign IP addresses to device interfaces (or VM interfaces) instead of typing them as free text - this is what makes the database verifiable.

Handling overlapping addressing with VRFs

Every IP object can be assigned to a VRF, and each VRF maintains its own isolated hierarchy. That is how you track the same 10.0.0.0/24 in five different tenants without a conflict. Define the VRF once with a unique route distinguisher, then assign it whenever you create overlapping prefixes or addresses. Mark the primary VRF in your templates so operators do not create duplicate space in the wrong context.

Keeping it current with the REST API

# token in the header, JSON in and out
TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxx

# find the next free prefix inside a container
curl -s -H "Authorization: Bearer $TOKEN"   "https://netbox.example.com/api/ipam/prefixes/?within=10.10.0.0/16&status=container"

# create a prefix scoped to a site
curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json"   https://netbox.example.com/api/ipam/prefixes/   --data '{"prefix":"10.10.99.0/24","scope_type":"dcim.site","scope_id":6,"status":"active"}' | jq .

# reserve an address, then read it back
curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json"   https://netbox.example.com/api/ipam/ip-addresses/   --data '{"address":"10.10.99.5/24","status":"active"}' | jq .

# list only written-down details to audit
curl -s -H "Authorization: Bearer $TOKEN"   "https://netbox.example.com/api/ipam/ip-addresses/?status=active&limit=0" | jq 'length'

Use ?brief=true for dropdown-style lookups; it returns only identifying fields and keeps large automation runs fast. Write operations always need a token, and every create should carry a description so a human can tell why the object exists.

Automation patterns that work

The highest-value integration is generating device configuration from NetBox instead of typing it: pull the interface list, IPs and VLANs for a device, render Jinja2 templates, and push with Ansible or NAPALM. The second is a reconciliation job that compares show ip interface brief output with the database and opens a ticket for every mismatch - that is the loop which actually keeps a source of truth accurate. Useful companions on this site: Ansible inventory and playbooks, NAPALM getters and config diff, and NETCONF vs RESTCONF vs gNMI.

Discipline that keeps NetBox useful

Define a small set of statuses and enforce them; require a description on every prefix and address; run the reconciliation job weekly and treat mismatches as incidents; and never let a deployment process create address space outside NetBox. A source of truth that is 90% accurate is worse than no source of truth, because people stop checking it.

原文链接：https://netbox.readthedocs.io/en/stable/features/ipam/