Every IP. Every number. One resource inventory, structurally enforced
XonIPAM manages IP addresses and telephone numbers as one carrier-grade resource inventory — from the /8 supernet to the individual host, from number allocation through portability, quarantine, and regulator-ready audit. Companion product: Number Inventory Management.
The data model is the differentiator.
Every IP is a materialised row — not a record derived at query time from a CIDR computation. That single decision unlocks audit lineage, structural isolation, and accurate capacity forecasting that legacy stacks cannot deliver.
Hierarchical model
Block, subnet, pool, address. Splits and merges preserve lineage across every reassignment.
Domain isolation
RAN, transport, core, access — typed pools. Cross-domain assignment blocked at the data layer.
Capacity forecasting
30/60/90-day exhaustion projection per pool. Multi-channel alerts before pools run out.
Approval governance
Sensitive operations gated by configurable approval workflows. Optional dual-authorisation.
From a /8 supernet to a single host.
Every level is materialised in the database, not derived at query time. Recursion is structural: split, merge and reassign without losing audit lineage.
Domains are walls, not labels.
Each technology domain — RAN, transport, core, access, IP/MPLS — gets its own typed allocation pool. Cross-domain assignments are structurally blocked at the data layer, not enforced by operator convention.
This eliminates the single most common source of address conflicts in carrier networks: the operator who copy-pastes an address from the wrong domain.
See it liveSee exhaustion before it lands.
Continuous utilisation tracking projects the exhaustion date for every pool. Configurable thresholds (default 80%) fire across email, Slack, webhook, and SNMP — with enough lead time to commission new blocks.
The forecast is per-pool, per-domain. You see which specific RAN pool runs out first, not just an aggregate “IP space getting full” warning.
See it liveMap IPAM to your existing IP plan.
Eight workflows. One inventory.
Hierarchical split, merge and overlap detection across IPv4 and IPv6. Every reassignment preserves audit lineage to the parent block, the originating allocation, and the operator who performed the operation.
Common operations — subnet a /16 into eight /19s, merge two underutilised /24s, reallocate a block from one domain to another — complete without manual reconciliation against DNS or DHCP.
Static, dynamic, RAN, transport, core, access, IP/MPLS, SDN/NFV, infrastructure, and APN pool types are first-class entities. Each pool carries its own allocation policy: assignment strategy, reservation rules, capacity threshold, approval requirements.
Every IP is a real database row with hostname, MAC, customer association, service tag, and full operational history. This is what enables fast queries at carrier scale — the platform routinely manages tenants with 1.8M+ materialised address rows.
Static IP-to-MAC bindings are stored centrally and exported to upstream DHCP servers (ISC, Kea, Microsoft) on every change. No more reservation drift between IPAM intent and DHCP reality.
Prefix delegation pools with configurable lifetimes. Parallel IPv4/IPv6 allocation tracked together on a single address record. Migration playbooks for greenfield IPv6 rollout alongside legacy IPv4 retention.
30/60/90-day projection per pool. Multi-channel alerts: email, Slack, webhook, SNMP. Custom thresholds per pool. The platform tracks acquisition lead time so commissioning new blocks completes before the network actually runs out.
Every change is captured: who, what, when, from where, with what justification, gated by which approval. The audit history is immutable and queryable. Conflict detection blocks structural overlap at write time, not after the fact.
Sensitive operations — static IP assignment, range changes, large-block reassignment — can be gated by configurable approval workflows. Optional dual-authorisation requires two operators to confirm.
What operators say about running it.
Direct quotes from network architects and operations leads at our deployed carriers. Names and brand identities are protected by NDA.
Replacing four separate inventory systems with one unified resource graph removed three full-time positions worth of reconciliation work. The drift problems we used to chase weekly simply stopped occurring.
The TMF Open API surface meant we could integrate with our existing OSS catalogue without any custom adapter work. Cutover was a six-week project, not the eighteen-month migration we had budgeted.
Capacity exhaustion alerts caught a /20 block we were about to run out of with 47 days of lead time. That single incident paid for the entire deployment.
Everything you need to evaluate.
Migrating from legacy DDI / NIM
Shadow-mode reconciliation strategy. Zero-downtime cutover playbook.
TMF Open API integration patterns
Mapping XonIPAM to TMF 633, 638, 645, 656 — with example payloads.
Multi-tenant deployment for MVNOs
Hierarchical isolation. Tenant onboarding playbook. Operational handoff model.
Tell us about your stack. We’ll map the fit.
A 30–45 minute technical walkthrough of XonIPAM — mapped to your existing OSS/BSS environment. You’ll hear back from a solutions engineer within one business day.
- Architecture review against your current inventory stack
- Live demonstration of the workflows that matter to your team
- Sizing, deployment model, and migration playbook
- TMF API surface walkthrough with example payloads