IP Address Management Software Problems: The 7 That Produce Outages and Wasted Space, and How to Avoid Them

Why does the spreadsheet import get treated as the data migration?

Because it is the only complete looking dataset in the building, and importing it produces immediate visible progress. Twelve thousand rows go in, screens populate, and the project feels a third done in a week.

The problem is specific to address management in a way it is not to most inventories. A customer record that is wrong is annoying. An address record that is wrong is a future outage with a delay fuse on it, and the delay is what makes it so expensive: the cost is not paid when the mistake is made, it is paid much later by someone with no way to trace it back. Networks that grew by acquisition carry several generations of this, since each acquired estate arrived with its own conventions, its own spreadsheet and its own quiet errors, and the merge was done by a person under time pressure.

The fix is to invert the order. The record is wrong, and the project is proving how wrong. Run discovery first as a short, separately scoped engagement: pull configured interfaces and addresses from device configurations, ARP and neighbour tables to see what is live, routing tables to see what is announced, DHCP lease data, cloud provider assignments and the DNS zones themselves. Compare that against the spreadsheet. The output is a reclaim list, a conflict list and a stale DNS list, all of which are actionable before any allocation engine exists, and all of which tell you how large the real project is. Sizing the reconciliation problem is the single largest unknown, and no vendor can quote it accurately without this.

What goes wrong when discovery and the record are reconciled?

Two mistakes, and they are opposites.

The first is letting discovery win automatically. A block genuinely reserved for a project starting next quarter has nothing live in it, so discovery sees empty space and the system reclaims it. Somebody then allocates it, and the project that reserved it discovers the collision at turn up. Discovery tells you what is live, not what is intended, and those are different facts.

The second is letting the record win, which is the same failure as the spreadsheet import wearing a better interface. Shadow allocations, meaning space live in the network with no record at all, are the most urgent finding in any first pass, and a system that treats the record as authoritative will never surface them.

The escape is to name the disagreement types and give each an owner. Space recorded as allocated with nothing live in it, which is a reclaim candidate rather than a reclaim. Space live in the network with no record, which is shadow allocation and needs an owner found. The same block recorded twice, which is the conflict that causes outages. DNS resolving to addresses assigned to nothing. Reverse zones that disagree with forward records. Build a queue per type with a named owner and a target, and work it down.

The system must never silently overwrite either side, because both are sometimes right. That is a design rule worth putting in the statement of work verbatim, because it is the one every generic inventory tool breaks.

Why do device and DNS integrations break after launch?

Because discovery talks to equipment that changes underneath it, and nobody owns the consequence.

Device access is the fragile part. Collection typically runs over an interface that requires credentials, and credential rotation, a hardening change, an access control list update or an operating system upgrade will each stop a collector. A vendor's newer platform returns a structured response where the older one returned text, so a parser that worked across the estate now covers most of it. Nothing errors loudly, because a device that returns nothing looks like a device with nothing to report.

DNS breaks differently. After acquisitions most estates run more than one DNS platform, and a zone transfer permission or an API credential on the one nobody talks about will lapse. Reverse zone delegation is where this quietly hurts, because delegated reverse zones frequently live with a different team or an upstream provider, and that is the single most common place DNS automation breaks in practice.

Three defences. Every collector reports last successful collection per device and per zone, and staleness alarms rather than being inferred from empty results. Unknown device platforms and unparsed responses land in a queue instead of being skipped. And collector maintenance is a priced line in support, because a network refresh cycle guarantees new platforms.

What happens when registry records and DNS lifecycle are not covered?

Two exposures that are treated as tidiness and are not.

The registry side first. The IANA free pool of IPv4 addresses ran out in 2011 and the regional registries followed, with ARIN reaching exhaustion in 2015, so space is now bought and sold through registry approved transfers and the blocks you hold are a balance sheet item. Meanwhile your allocations to customers or internal organisations are supposed to be reflected in registry records, and route origin authorisations under RPKI let other networks validate your announcements. When the internal record is a spreadsheet, registry data drifts from reality, and the drift shows up as a routing security question you cannot answer confidently. A build that stops at internal allocation leaves that gap open.

The DNS side is sharper. A record pointing at an address since reassigned sends traffic to the wrong service, and a dangling record aimed at a released cloud address is a subdomain takeover risk that your security team will treat seriously.

Both fixes are lifecycle rather than feature. When an allocation is created, forward and reverse records are created with it. When it is released, records are removed, or flagged if something still resolves. Registry and RPKI records synchronise from the same allocation event rather than being maintained by hand in a separate portal. Continuous validation compares zone contents against assignments and against what actually answers, and queues mismatches. That last piece is a couple of weeks of work once the inventory exists and almost nobody builds it.

Should you build custom or configure what you already own?

A single site enterprise with a few dozen subnets and one network team should not build. NetBox or phpIPAM plus one enforced process will hold, and the discipline matters more than the tool.

A conventional multi site enterprise with broadly accurate records and a need for integrated DNS and DHCP should evaluate Infoblox, BlueCat or EfficientIP properly, and SolarWinds IP Address Manager is a lighter option in the same space. Running the services as well as recording them is real value a custom build does not give you unless you also want to run DNS yourself, which you probably do not.

NetBox in particular deserves a serious look before anyone writes code. It has become the default source of truth for a lot of networks, it has a good data model and a usable API, and a large share of what people commission is achievable by configuring it and building only the discovery and reconciliation layer around it.

Build when the record and the network genuinely disagree and reconciling them is the actual project, when allocation has to happen inside automated service activation, when registry and RPKI obligations must stay synchronised with internal allocations, or when you have acquired networks whose conventions you have to absorb rather than replace. The tell is simple: if your last three addressing incidents were caused by the record rather than by a configuration error, the record is your problem.

How do hidden costs get into the quote?

A first release covering discovery from devices and DNS, reconciliation queues by conflict type, the allocation engine with your addressing policy encoded, and an API runs $60,000 to $130,000 across 10 to 14 weeks in Digital Heroes delivery experience. The full build adding DNS lifecycle automation, provisioning integration, registry and RPKI synchronisation, IPv6 hierarchy management and utilisation reporting runs $150,000 to $350,000 phased over 6 to 12 months.

Four things hide inside those. The number of device vendors and generations discovery must speak to, because collecting from a current platform and from a fifteen year old switch are different exercises and a quote that has not seen your inventory has guessed. Multiple DNS platforms, which is normal after acquisitions and is rarely mentioned until integration week. Provisioning integration, which depends entirely on how tidy your activation system is and should be priced only after somebody has looked at it. And the volume of historic mess, which is genuinely the biggest variable and is exactly why discovery belongs in front of the quote rather than behind it.

Registry integration is a fifth: each registry has its own interfaces and rules, so name the ones in scope.

What separates a build that works from one that fails here?

Allocation is a request, not an edit. Engineers state a purpose, a site, a service type and a size, and the system allocates from the correct pool according to your policy, records requester and purpose, creates the DNS entries and sets a review date. If people can still edit the inventory directly, the record will drift again within a year and you will have paid to arrive back where you started.

The addressing policy lives in the system as data. Real networks have conventions with meaning: a site gets a defined prefix size, management is always the first block within it, point to point links come from a specific range, customer allocations by service tier come from separate supernets to keep aggregation clean. Those conventions currently sit in an engineer's head or a design document nobody has opened in years. Writing them into the allocation engine is how they survive that engineer.

IPv6 is designed for, not bolted on. The logic is different because the constraint is structure and aggregation rather than packing scarce space, and retrofitting is worse than planning. Ask any prospective developer how they model it and be sceptical of anyone treating it as IPv4 with longer strings.

Review dates are the mechanism that stops hoarding, so unreviewed space eventually surfaces in a reclaim queue rather than living forever. Ask how reclaim is proposed, who approves it and what evidence accompanies the proposal.

And get code and infrastructure ownership in writing at kickoff. Your address inventory is the map of your network, and renting the map from a supplier you cannot replace is a poor trade.