Bill Gernert
Automation & Tooling

NetBox IPAM

The IP address source of truth - the first stop in provisioning, where an address is allocated before a VM exists, so the inventory and the network never disagree.

What it is & why I use it

NetBox is the IP address management (IPAM) and inventory system for AutomationLab. It is the authoritative record of which addresses are in use, which are free, and what each one is for. When the pipeline provisions a machine, its first action is to ask NetBox for an address - allocation happens in the record before the VM is built.

I use it because "which IPs are free?" should have one trustworthy answer, queryable by automation, not a spreadsheet or a guess. An IPAM that the provisioning flow actually consults is what keeps a growing lab from quietly handing out the same address twice.

How I use it in the lab

  • Allocate first. The provisioning pipeline requests an address from NetBox as its opening step, so the record reserves it before anything downstream uses it.
  • Feeds the rest of the flow. The allocated address flows into the infrastructure-as-code and configuration stages, so every later step builds on the same authoritative value.
  • Released on decommission. Tearing a machine down returns its address to the pool in NetBox, so freed space is actually reusable and the record keeps matching reality.
  • Queried, not remembered. Automation reads NetBox through its API rather than relying on anyone's memory of what is assigned where.

Architecture

Diagram coming Provisioning flow: NetBox allocate -> IaC -> configure -> (decommission) release back to pool. Scrubbed of addresses, prefixes, and hostnames.

In action

Screenshot coming A prefix view with allocations and free space, and an address just reserved by a pipeline run. Captured per the publishing checklist - prefixes, addresses, and hostnames redacted.

Lessons learned & gotchas

Gotcha - a source of truth is only true if everything goes through it NetBox is authoritative right up until someone assigns an address out of band - a quick manual static IP, a machine stood up outside the pipeline. The moment that happens, the record and the network disagree, and the next automated allocation can hand out an address that is already quietly in use. An IPAM does not enforce reality; it only reflects what it is told. So the discipline is absolute: every allocation goes through NetBox, or NetBox is just a stale document that looks authoritative while lying to you.
  • Allocate before you build, not after. Reserving the address first means two concurrent provisions can never race for the same one. Recording it after the fact leaves a window where a conflict can slip in.
  • Release on teardown or the pool silently shrinks. If decommission does not return the address, the free pool leaks over time and you eventually "run out" of space that is actually idle. The reverse path matters as much as the forward one.
  • Reconcile occasionally. Because out-of-band changes are always possible, it is worth periodically checking the record against what is really answering on the network, and fixing drift before it causes a conflict.

Impact

First
step in provisioning
1
authoritative IP record
0
double-allocations by design

NetBox is what makes address management a solved problem instead of a recurring source of conflicts. The lesson generalizes to every source of truth: it is only worth the name if it is the single door everything passes through - the instant work routes around it, it stops being truth and becomes a confident-looking liability.

Code & further reading

Allocation tooling (link coming) NetBox docs

Published tooling is scrubbed of prefixes, addresses, hostnames, and any secret references before it goes public.