IPAM Without the Ticket: NetBox, Salt, and VCF 9.1

This is a companion to my automation framework. That one is about the general idea — how a manual step earns its way up the ladder to being automated. This one is the concrete case study: IP address management, which is about as manual and repetitive as infrastructure gets.

The loop everyone knows

Here is the workflow IPAM has had for decades. An application owner needs a network. They file a helpdesk ticket. A network engineer opens the IPAM tool — or worse, a spreadsheet — finds a free block, carves it out, writes it down, updates DNS by hand, and replies to the ticket. Maybe a day later, the requester gets their addresses.

Every step in that chain is a human relaying state between systems. None of it requires judgement. It is pure clerical work, and it is slow precisely because a person has to be in the path. It is also where IP conflicts come from: two people allocate from the same range because the spreadsheet was stale, or someone forgets the DNS entry.

This is the loop worth closing. The only real question is how you close it, and there are two honest answers.

The native answer: VCF 9.1 and Infoblox

If you are an Infoblox shop, VCF 9.1 closes the loop for you. The release ships a direct DDI integration — DNS, DHCP, and IPAM — between VCF and Infoblox. Infoblox stays the single source of truth across the wider data centre, and VCF talks to it in the background: vCenter admins and VCF Automation tenants provision networks on demand, VCF allocates and reserves the IP blocks from Infoblox automatically, and FQDN entries get registered in Infoblox DNS as workloads come up. No tickets, no spreadsheet, no manual DNS.

The important word is direct. This is a first-class, in-product integration — you configure the pairing and consume it, you do not build it. VMware’s own writeup frames it exactly as I would: keep the governance and central visibility your network team wants, while unlocking the self-service consumption your application owners want. If Infoblox is your DDI platform, this is the easy button, and it is a good one.

I do not run Infoblox. I run NetBox. I chose it because it is open source and robust, and because some of my customers use it too — so the patterns I work out here are ones I can actually demonstrate to them on a platform they already know. In my lab its primary use case is demonstration and learning, which is exactly why it is a good place to prove out automation like this.

The built answer: NetBox as the source of truth

NetBox is my inventory and IPAM source of truth, and it has the primitive that makes all of this possible: the available-prefixes and available-ips endpoints. A POST to a prefix’s available-ips/ atomically hands out the next free address and creates the object in one DB-locked call. No read-then-write window, no race. That single endpoint is the thing that lets a person leave the loop safely — the database, not a human, guarantees you never hand the same address out twice.

You can hit that endpoint a few ways. There is the raw REST call, there is pynetbox in a Terraform or Ansible step, and — if you want the Infoblox-style experience inside VCF Automation — there is the third-party IPAM SDK, with a community NetBox provider that runs as a containerised extensibility action. That last one is worth a sidebar of caution: a community connector you carry across version bumps is real surface area to maintain. It is the part of this I trust the least unattended, which, by the framework, means it is the part I keep a human closest to.

But raw API calls scattered through pipelines are not an abstraction — they are the same clerical work moved into YAML. What I actually wanted was a single, safe surface that any system could call the same way, with the guardrails built in. So I built one.

The runner: a contract, not a script

In my Salt estate, every infrastructure concern is exposed as a runner that conforms to one contract — the same seven verbs, the same result envelope, every time. IPAM is ipam_api. It is a thin, race-safe, deliberately end-tool-agnostic surface over NetBox: it knows about prefixes, ranges, and addresses, and nothing about NSX or Kubernetes or DHCP. Those mappings belong to whatever system is consuming the addresses, not to IPAM itself.

Salt is where I built it, but it is worth being clear that the runner is not the point — the contract is. And I do not have to choose where it gets consumed, because my runners are published into vRO. The verbs, the preview-before-commit, the deprecate-don’t-delete release, the canonical tagging: all of that logic lives once, in the Salt runner, and is then exposed as something VCF Automation blueprints and VMware-native processes can call directly. There is no second implementation to keep in sync and no external hop to bolt on later — a blueprint asking for addresses and an operator typing salt-run are hitting the exact same contract, fronting the exact same NetBox, with the exact same guardrails. The abstraction sits in one place and reaches into the VMware world from there. That is the real payoff of treating the contract as the asset: build it once, consume it everywhere.

And the relationship runs both ways. I am just as comfortable flipping the direction — making vRO the contract system and having Salt call it. The choice of which engine holds the abstraction and which one consumes it is not a religious one; it is a question of where your team already lives and what you want to be the system of record for orchestration. The contract is what is portable. The host is an implementation detail you get to pick.

The contract is the interesting part, because the guardrails from the human-in-the-loop framework turned out to map almost one-to-one onto its verbs.

plan is the approval rung. It is read-only. It previews exactly what apply would carve — which prefix, which range, how many addresses — and writes nothing. That is the “human approves before commit” step made concrete: you can look before you leap, and a machine can diff it without consequences.

apply is where the human leaves. It converges to the desired state using those DB-locked NetBox endpoints. This is the actual moment of automation: nobody eyeballs anything, the lock kills the race, and the allocation comes back tagged, tenanted, and described in a single operation.

The release model is the off-ramp, designed first. The hardest part of trusting automation is not the happy path — it is what happens when something is wrong. My release verbs do not destroy anything. They deprecate: flip the object’s status, tag it, and capture the prior state so it can be restored while the object still exists. A separate, deliberately boring cleanup runner is the only thing allowed to issue an actual delete. That means the worst failure mode — automation confidently doing the wrong thing and erasing the evidence — is closed by design. The undo is built in.

The tag policy is a guardrail that says no. Every allocation carries a canonical allocated tag. But the runner refuses to create tags — they have to be declared in the schema and reconciled into NetBox first. Automation that declines to quietly drift your taxonomy is automation you can leave running.

The envelope fails loud, never silent. Every verb returns one of three shapes — success, an explicit no-op with a reason, or a failure with errors. It never raises an unhandled exception back through the API boundary. Things either work, politely decline, or fail in a way you can see. Nothing fails quietly.

Put together, the runner is not really “a script that calls NetBox.” It is a place where I got to decide, per operation, exactly how much trust to extend and what the off-ramp looks like — and then encode that decision so every caller inherits it.

So which one should you build?

That is the honest comparison, and it is not “native good, custom bad.”

If you run Infoblox, VCF 9.1 hands you the closed loop for free. Take it. You will spend your effort on policy — which containers, which ranges, what governance — instead of plumbing.

If you run NetBox, or anything else, nobody is going to hand you the button. You build it. That costs more up front, but you get something the native integration cannot give you: you decide where every operation sits on the trust ladder. The plan preview, the deprecate-don’t-delete release, the tag policy that refuses to drift — none of that came for free, but all of it is exactly the shape I wanted, because I had to choose it.

The native integration optimises for getting out of your way. The built one optimises for control. Both take the human out of the ticket queue. That was always the point.