IPAM as an operational source of truth

Inventory alone is not enough

A list of subnets is useful, but a source of truth must also explain intent. For every address block, operators should be able to determine its owner, purpose, environment, location, routing context, lifecycle state, and relationship to DNS and DHCP.

The goal is not to record every possible field. The goal is to make the decisions that matter explicit and reliable enough for both people and automation.

Model plan, assignment, and observation

Planned data describes what should exist: a reserved prefix, a DHCP pool, a static allocation, or a naming convention. Assignment data describes who or what owns an address. Observed data describes what the network currently sees. Mixing these without labels creates false confidence.

• Plan: approved networks, pools, reservations, and policy
• Assignment: owner, service, device, ticket, and lifecycle state
• Observation: leases, DNS records, discovery, and last-seen signals

Build a small lifecycle

A practical lifecycle can be simple: requested, approved, allocated, active, deprecated, and reclaimed. Each transition should identify who made the change and why. Reclamation is especially important; stale allocations make capacity planning inaccurate and can leave abandoned DNS records or access rules behind.

Use required metadata sparingly. Owner, purpose, environment, and lifecycle state usually provide more value than dozens of fields that nobody maintains.

Earn trust through reconciliation

IPAM becomes authoritative when teams routinely compare intended state with DHCP leases, DNS data, routing tables, cloud inventories, and discovery results. Differences should produce a reviewable exception, not an automatic overwrite with no context.

A source of truth is a maintained decision system, not a database that happens to contain addresses.

Worked example: allocate a /26 without overlap

A synthetic branch request needs 50 conventional host addresses in routing context corp-east. The approved parent is 10.40.8.0/24. Its .0/26 block is already allocated. A /26 provides 64 total addresses and 62 conventional host slots, so .64/26 is a candidate only after overlap and ownership checks.

Record the prefix, routing context, owner, purpose, ticket and lifecycle state before provisioning. For .64/26, .64 is the network and .127 the directed broadcast; .65 can be the gateway, .66–.79 static infrastructure, and .80–.126 a 47-address DHCP pool. If the request requires 50 dynamic clients, this pool is too small despite the subnet having 62 host slots.

$ python3 - <<'PY'
import ipaddress
parent = ipaddress.ip_network('10.40.8.0/24')
for child in parent.subnets(new_prefix=26):
    print(child, child.num_addresses - 2)
print(ipaddress.ip_network('10.40.8.64/26').overlaps(
    ipaddress.ip_network('10.40.8.96/27')))
PY
10.40.8.0/26 62
10.40.8.64/26 62
10.40.8.128/26 62
10.40.8.192/26 62
True

Practice: reconcile an apparent free address

Spend nine minutes reviewing three synthetic records: IPAM marks 10.40.8.90 reserved for a printer; DHCP reports a lease for a laptop at .90; discovery has not seen the printer for 14 days. DNS still maps printer.example. to .90.

• Separate the approved reservation from the observed lease and discovery time.
• Do not mark the address free because a ping fails. Confirm the printer owner, lease identity and pool exclusions.
• Open a conflict exception with owner and evidence. If the reservation is valid, correct the pool policy and plan a controlled client transition.
• Before reclamation, confirm decommission approval, remove dependent DNS/reservations and document the release.

Expected result: absence from discovery is weak evidence. A trustworthy reconciliation preserves approved intent while resolving the contradictory DHCP assignment.