By Yair Knijn · April 3, 2025

The subnet your IPAM marked 'free' was running payroll. You found out when you reassigned it.

You are the cloud network engineer who needs a /27 for a new staging tier, and the IPAM says 10.42.18.0/27 is free. So you reassign it, push the route, and go home. The flag was honest about one thing: someone typed "free" into a field once. It said nothing about whether anything is actually answering on those addresses right now.

That gap is where Friday outages live. The block was carrying a payroll appliance that nobody had registered, because the person who racked it left, and the IPAM only ever recorded what humans told it.

Why 'free' in a spreadsheet means 'nobody updated it'

A "free" flag set by a human edit is a claim about the past, not a fact about the present. It tells you that on some Tuesday months ago, someone believed those addresses were idle. Between then and now: a contractor stood up an appliance, a forgotten DHCP reservation kept a lease alive, a VM was cloned with a hardcoded address. None of that touched the spreadsheet, because spreadsheets do not watch the wire.

IP address state has three honest categories worth distinguishing: reserved (held back from DHCP on purpose), available (open for leasing), and free (previously leased, now released). The trap is treating a stale "free" the same as a verified-idle address. One was checked against reality. The other is a memory.

Reconciling intent against DHCP, ARP, and live scans

The fix is boring and it works: never trust the record alone, cross it against what the network is actually doing. Three independent signals catch most of what a human edit misses.

• DHCP leases: an active or recently expired lease on an address you think is free means a device asked for it and got it. Stale-but-unexpired leases are the classic cause of reassigning live space.
• ARP and live scans: arp-scan across the segment shows you MACs that are answering right now, including statically configured boxes that DHCP never knew about. Your payroll appliance shows up here even though it has no lease.
• DNS: forward and reverse records pointing at the block tell you something still expects to find a service there.

If any of these disagrees with "free," the address is not free. It is a conflict waiting for a trigger.

The duplicate-IP conflict: how the outage actually unfolds

Here is the mechanics, not the metaphor. You reassign 10.42.18.20 to a staging node. Two hosts now claim one address. Some DHCP servers do try to defend against this: Microsoft's DHCP pings an address before leasing it, and if it gets a reply it marks the entry BAD_ADDRESS and skips to the next one. But that guard only fires inside the DHCP scope. Your reassignment was a static config change on a host that bypassed DHCP entirely, so nothing pinged first, nothing got marked bad.

The switch now sees the same IP behind two MACs. ARP cache entries flap, traffic for payroll lands on the staging node half the time, and the finance team's submission times out at 4 p.m. on a Friday. The incident reads as "payroll system down." The root cause is an allocation made against a flag that was never reconciled.

Trust but verify: gating reclamation on a usage check

Reclamation is the single most dangerous IPAM operation, because it turns a stale record into an active conflict. The rule that prevents this: an address cannot move from "free" to "reassigned" until a live usage check confirms silence across DHCP, ARP, and DNS. No green check, no reclaim. If arp-scan sees a MAC, the workflow blocks and tells you which device, not "are you sure?"

Spot IPAM treats every address as a claim to be proven, not a flag to be trusted. Each Environment reconciles its records against live DHCP leases, ARP responses, and DNS continuously, so the block marked free is the block that answered nothing on the last scan, and reclamation refuses to fire while a device is still talking. See how the reconciliation engine gates reassignment before it can take down a system you didn't know existed.