Skip to content
Log in Sign up My account

IPAM and Source-of-Truth Tools

This article compares the main ways to track IP addresses and network inventory: NetBox, Nautobot, phpIPAM, Infoblox, BlueCat and the humble spreadsheet. You will get a clear idea of what each one is, where it is strong, where it is weak, and which kind of team it fits, plus a short guide to choosing between an address database and a full source of truth.

IPAM, DDI and source of truth are different things

The terms overlap, so pin them down first.

  • IPAM tracks prefixes, addresses, VLANs and VRFs. It answers "what is 10.20.0.0/16 used for and who owns 10.20.4.17".
  • DDI is DNS, DHCP and IPAM managed together, so a record in the database becomes a real DNS entry or DHCP reservation. The commercial appliance vendors sell this.
  • Source of truth (SoT) goes further: devices, interfaces, cables, racks, circuits, sites and intended configuration data, exposed over an API so automation can read the intended state of the network.

A tool can be good at one and weak at another. A DDI platform is strong at running DNS and DHCP, but it is not the place you model racks and cables. A SoT tool models the physical and logical network well, but it does not serve DNS.

graph LR
    SoT["Source of truth<br/>(NetBox / Nautobot)"] --> Auto["Automation<br/>(Ansible, Python, CI)"]
    Auto --> Dev["Network devices"]
    SoT --> DDI["DNS / DHCP"]
    Dev --> Mon["Monitoring"]
    SoT --> Mon
    Dev -- "discovered state" --> Diff["Drift report"]
    SoT -- "intended state" --> Diff

The valuable loop is the last one: compare what the source of truth says should exist with what discovery or monitoring says does exist, and treat differences as work items.

NetBox

What it is. An open source IPAM and DCIM (data center infrastructure management) application, written in Python on Django with a PostgreSQL database. It started as an internal tool for a network engineering team and is now maintained by NetBox Labs with a large community. It is licensed under Apache 2.0, and NetBox Labs sells commercial editions and hosted options on top.

Strengths.

  • A strict, opinionated data model: sites, racks, devices, interfaces, cables, prefixes, IP addresses, VLANs, VRFs, circuits, providers, virtual machines and more. The model forces consistency.
  • A mature REST API and a GraphQL API, with a well-known Python client, pynetbox.
  • Custom fields, tags, config contexts, webhooks, event rules and custom scripts to extend the model without a fork.
  • A plugin system and an active plugin ecosystem.
  • An official Ansible collection (netbox.netbox) with an inventory plugin, so playbooks can use NetBox as the inventory.

Weaknesses.

  • It is a database of record, not a discovery engine. Data stays correct only if something keeps it correct.
  • The data model is fixed to a degree. You extend it with custom fields and plugins, but you do not remodel it.
  • Some capabilities (for example certain enterprise features and support) sit in commercial editions. Check the current feature split.

Fits. Teams that want a source of truth with strong inventory and cabling and a good API, and are willing to run a Django application.

Nautobot

What it is. An open source network source of truth and automation platform from Network to Code, forked from NetBox at version 2.10 and developed independently since. It is also a Django and PostgreSQL (or MySQL) application under the Apache 2.0 licence, and it can serve as a platform for apps built on it.

Strengths.

  • Designed as an extensible platform. Apps (its plugin term) can add models, views, API endpoints and jobs, and a documented app framework makes it easy to build on.
  • Jobs run Python tasks from inside the platform, with logging and an approval path.
  • Native Git integration lets it pull data such as config contexts, export templates and job code from Git repositories.
  • GraphQL support, a Python client (pynautobot) and an Ansible collection from Network to Code.
  • A set of well-known apps for config compliance and golden configuration, device onboarding, and integrations with ServiceNow and other systems. Check the current app list and compatibility with your Nautobot version.

Weaknesses.

  • A smaller community than NetBox, with fewer third-party tutorials.
  • The extensibility is a strength and a cost: more moving parts to run and upgrade when you adopt several apps.
  • Because it forked, plugins written for one often do not work in the other.

Fits. Teams that want a source of truth that is also an automation platform, or teams with software engineering capacity who plan to build their own apps.

phpIPAM

What it is. A lightweight, open source IPAM written in PHP with a MySQL or MariaDB backend, released under GPLv3. It focuses on addresses, subnets, VLANs and VRFs.

Strengths.

  • Simple to install on a standard LAMP stack and easy to learn.
  • Subnet scanning and discovery agents can mark addresses as used or free.
  • Useful extras for small shops: a subnet calculator, a request module, a simple device list and import and export from spreadsheets.
  • An API for automation.

Weaknesses.

  • It is IPAM, not DCIM. There is no rich model of racks, interfaces and cables.
  • The API and automation ecosystem are smaller than NetBox's or Nautobot's.
  • Less suited to large, many-team deployments with strict data models.

Fits. Small to mid-sized organizations that need to retire a spreadsheet and want something simple and free.

Infoblox

What it is. A commercial DDI vendor. The traditional product is NIOS, which runs on physical or virtual appliances grouped in a Grid with a central management interface and an API called WAPI. The vendor also sells cloud-delivered DDI services. IPAM, DNS and DHCP are integrated, with features such as DNS security and DHCP fingerprinting available as extras.

Strengths.

  • DNS, DHCP and IPAM in one managed platform, with high-availability pairs, Grid-wide replication and role-based access control.
  • IPAM data is directly connected to the services that use it, so records and reservations are created in one step.
  • Strong enterprise and service-provider track record, and integrations with cloud providers, ServiceNow, Ansible and Terraform.
  • Vendor support and a professional services ecosystem.

Weaknesses.

  • Commercial licensing that scales with the deployment, and it is usually a larger purchase than the open source tools. Ask for current terms.
  • Not a DCIM. Cabling and racks live elsewhere.
  • Operating the Grid takes some specialist knowledge.

Fits. Larger enterprises and service providers for which DNS and DHCP are critical services that need vendor support.

BlueCat

What it is. A commercial DDI vendor with a long enterprise history. Its core product, Address Manager, handles IPAM and drives separate DNS/DHCP servers, with an API and a gateway component for automation workflows. It also has cloud-oriented offerings.

Strengths.

  • DDI with a strong emphasis on workflow, role-based access and integration with enterprise systems.
  • The management server and the DNS and DHCP servers are separate roles, which suits teams that want that separation.
  • Commonly deployed in large enterprises and government organizations.

Weaknesses.

  • Commercial licensing, with the same caveats as Infoblox.
  • Not a source of truth for devices and cabling.
  • Community resources are smaller than for open source tools.

Fits. Enterprises that want a DDI platform with vendor support and workflow integration, often as a comparison point against Infoblox.

Spreadsheets

A spreadsheet is a legitimate starting point, not a joke. For a few dozen subnets and one or two engineers, a well-structured sheet is faster than standing up a server.

Strengths. No infrastructure, universal familiarity, easy to share and review.

Weaknesses.

  • No validation: two people can allocate the same prefix.
  • No API, so automation cannot rely on it without exporting to CSV.
  • Version control is poor, history is hard to audit, and one stale copy on a laptop causes a conflict.
  • It does not scale to many engineers or to modeling relationships.

Tip

If you stay on a spreadsheet, keep it in Git as CSV, use one row per prefix or address with fixed columns, and add a check script that rejects overlapping prefixes. That gets you review history and a basic safety net.

Comparison table

Tool Type Licence Scope API Best fit
NetBox SoT, IPAM and DCIM Open source (Apache 2.0), commercial editions Sites, racks, devices, cables, IPAM, VLAN, circuits REST, GraphQL Inventory-centred automation with a fixed data model
Nautobot SoT and automation platform Open source (Apache 2.0), commercial support Similar to NetBox, plus apps, jobs and Git sync REST, GraphQL Teams building automation on the SoT
phpIPAM IPAM Open source (GPLv3) Subnets, addresses, VLANs, VRFs REST Small teams replacing a spreadsheet
Infoblox DDI Commercial DNS, DHCP, IPAM WAPI (REST) Large enterprise and provider DNS/DHCP
BlueCat DDI Commercial DNS, DHCP, IPAM REST Large enterprise DDI with workflow
Spreadsheet Manual list Whatever you already have Anything you type None Very small networks, short term

Choosing

  1. Do you need to run DNS and DHCP from the tool? If yes and the services are business critical, look at the DDI vendors. If the services already exist, a SoT can drive them through integrations.
  2. Do you want automation to read intended state? Choose NetBox or Nautobot. Pick NetBox for a stable, widely documented model, and Nautobot if you want to build apps and jobs inside the platform.
  3. Is it just addresses? phpIPAM, or a version-controlled spreadsheet if you are tiny.
  4. Who will run it? Any Django application needs a database, backups, upgrades and an owner. Count that cost.

A common pattern is NetBox or Nautobot for devices, interfaces and prefixes, with a DDI product receiving the addresses it needs for DNS and DHCP. Whatever you pick, define the rule for who may change data and how discovered state is reconciled, or the database will drift from the network.

For automation that consumes the inventory, see the CCNP course study plan for the underlying addressing and routing knowledge that the data model represents.

References