What Is IPAM and When You Need It

IPAM is the practice of knowing which addresses you hold, what each one is assigned to, and how much room is left. The tooling matters less than the discipline: a single authoritative record of address space that people trust enough to consult before making a change.

What IPAM actually covers

Four things, in decreasing order of how often they get neglected:

Allocation records. Which block belongs to which site, service, tenant, or customer, and who approved it. This is the part everyone implements.

Assignment records. Which individual addresses are in use, by what, and since when. This is the part that decays first, usually because assignments get made during incidents and recorded never.

Utilization. How full each block is, measured against a target rather than against 100%. A block at 95% has no room for a failover range or a new rack.

Consistency with external records. Your view of the space has to match DNS, DHCP reservations, firewall objects, and — for space you hold from a registry — the registry objects themselves.

The failure modes it prevents

Address management problems rarely announce themselves as address management problems. They surface as:

• Assignment conflicts. Two services configured on the same address, discovered when the second one is deployed. The cost is an outage, not an inconvenience.
• Overlapping private space after a merger. Two networks both using 10.0.0.0/8 with no coordination, which turns an integration into a renumbering project.
• Unroutable allocations. A block subdivided so that no piece aggregates, leaving you announcing a dozen prefixes where one would have done, or unable to announce at all because the pieces are longer than /24.
• Failed registry audits. Records showing a block fully assigned to a customer who left two years ago. At best this delays your next allocation request; at worst it raises questions about how the space is actually used.
• Silent exhaustion. Discovering there is no space left for a new deployment during the deployment, when acquiring more takes weeks.

Each of these is cheap to prevent through recording and expensive to fix afterwards. That asymmetry is the entire argument for IPAM.

When a spreadsheet stops working

A spreadsheet is a legitimate IPAM system for a single operator with a couple of blocks. It stops being one at recognisable points:

• More than one person assigns addresses. Spreadsheets have no locking and no meaningful conflict resolution. Two people editing on the same afternoon is how conflicts enter the record.
• You need to know who changed what. Version history in a shared drive is not an audit trail.
• Allocation has structure worth enforcing. A spreadsheet will happily let you assign a /26 that straddles two /25 boundaries. A tool will not.
• Something else needs to read the data. Provisioning, monitoring, and firewall automation need an API, not a file.
• You hold leased space with return dates. Someone has to know what is deployed on a block before the lease ends, and that someone should not be a person recalling it from memory.

If none of these apply yet, a disciplined spreadsheet with a fixed column structure is genuinely fine. Migrate before the first conflict, not after.

Choosing where to go next

If you are setting up address management from scratch, design the plan before picking the tool — a tool imposed on an unstructured allocation history just records the mess faster. Start with address plan design, then compare options in the IPAM tools reference.

If you already know you want a self-hosted system, NetBox and phpIPAM are the two most common starting points and both have quickstarts here.

If you manage space you do not own, the record-keeping requirements differ enough to warrant their own page: see IPAM for leased space.

Running out of space rather than out of records? IPv4 services covers acquiring additional blocks.