The Spreadsheet That Finally Failed Us
Our IP address management was a 2,000-row spreadsheet with duplicate entries and outdated data — three engineers had write access and no audit trail. I knew it was ugly, but I kept telling myself it was manageable because our manufacturing network was stable, our VLANs were documented enough, and most address changes happened during planned maintenance windows.
Then a new server got assigned an IP that was already in use. The conflict caused intermittent connectivity issues for 6 hours before the root cause was found, and the symptoms looked like everything except IP conflict at first: random HMI disconnects, failed historian writes, and a switch port that appeared clean every time we checked counters.
I was wrong about the spreadsheet being manageable. My first assumption was that our FortiGate running FortiOS 7.4.3 had started dropping traffic between zones after a policy cleanup, so my team burned the first hour reviewing firewall logs instead of questioning the source data we trusted.
That stung.
The lesson I took from that night was blunt: IPAM earns its keep only when it reflects actual network state. A manually updated list of addresses is documentation. A real IPAM platform tracks intent, detects drift, links addresses to DNS and DHCP, and gives my team a way to prove who changed what. Anything less is theater, in my opinion.
Design IPAM Around DHCP, DNS, and Ownership
When I evaluate IPAM architecture now, I start with the systems that already know the truth. DHCP knows what leased an address. DNS knows what names resolve. Switches and firewalls know what traffic appeared. Asset inventory knows who owns the device. The IPAM tool has to sit in the middle of that, not beside it like a prettier spreadsheet.
In our environment, the core integration points were Windows DHCP, BIND DNS for a few OT segments, FortiGate address objects, VMware inventory, and our ticketing workflow. I cared less about colorful subnet diagrams and more about whether a reservation created in IPAM could become a DHCP reservation without a human copying values between screens.
- DHCP scope import and reservation synchronization
- Forward and reverse DNS record management
- Role-based access control with audit history
- API support for automation from Python 3.11 scripts
- Clear subnet hierarchy for sites, VLANs, and production cells
- Change workflow that matched maintenance-window discipline
Pretty maps do not fix bad data.
The architecture that worked for us treated IPAM as the source of intent and DHCP/DNS as systems that continuously proved or disproved that intent. If a lease showed up outside a planned pool, I wanted to see it. If a DNS record pointed to a retired host, I wanted that stale record flagged. My opinion is that IPAM selection should begin with reconciliation, not presentation.
Deploy NetBox With Synchronization First
We deployed NetBox on Ubuntu 22.04 with PostgreSQL 14, Redis 6, Gunicorn, and Nginx, then pinned our automation to Python 3.11 so the integration scripts behaved the same in test and production. I liked NetBox because its data model matched how network engineers think: sites, prefixes, VLANs, devices, interfaces, IP addresses, tenants, and custom fields without forcing everything into one flat address table.
The early deployment was intentionally boring. We imported prefixes first, then VLANs, then addresses, and only after that did we let synchronization touch DHCP. That sequence mattered because my team needed confidence that NetBox described the network before it started influencing the network.
python3.11 -m venv /opt/netbox-sync/venv
source /opt/netbox-sync/venv/bin/activate
pip install pynetbox==7.3.3 requests==2.31.0
export NETBOX_URL="https://ipam.example.local"
export NETBOX_TOKEN="redacted"
python sync_windows_dhcp_to_netbox.py --scope 10.40.12.0/24 --dry-run
python sync_windows_dhcp_to_netbox.py --scope 10.40.12.0/24 --applyWhat I didn’t expect was how much cleanup the dry run exposed. We found printer reservations with no owners, test PLC addresses still marked active, DNS names that referenced retired packaging lines, and two subnets where the spreadsheet mask did not match the configured gateway mask.
The dry run paid for itself.
After deploying NetBox with DHCP synchronization, IP conflict incidents dropped from 3-4 per month to zero, and IP allocation time dropped from 15 minutes to 30 seconds. That number changed the conversation with management because the platform was no longer an engineering preference; it was operational risk reduction with measurable time returned to the team. I will take a plain tool with a strong API over a polished tool with weak synchronization every time.
Compare Commercial and Open-Source IPAM on Operating Model
Commercial IPAM tools such as Infoblox bring real strengths, especially when DNS, DHCP, grid replication, high availability, and vendor support need to arrive as one supported package. In a manufacturing facility where downtime can stop production, that support model has value. I do not dismiss it, and I have seen commercial appliances reduce complexity for teams that do not want to own integration code.
Open-source IPAM, especially NetBox, fit us because we already had Linux skills, automation habits, and a security team comfortable maintaining Ubuntu 22.04 services. We wanted API-first behavior, custom fields for plant-specific ownership, and the ability to integrate with change tickets without waiting for a vendor roadmap.
You may also find this useful: Check out our guide on Python Network Config Backup: Automating Multi-Vendor Device Snapshots for more practical tips.
The decision criteria were not ideological. I weighed cost, support expectations, DNS/DHCP authority, API depth, audit controls, backup and restore process, authentication, upgrade cadence, and how easily we could model weird industrial networks where a VLAN might map to a production cell instead of a business department.
Licensing is only one line item.
If my team needed turnkey authoritative DHCP and DNS with vendor-backed appliances, I would lean commercial. If my team needed flexible source-of-truth modeling with automation around existing services, I would lean open-source. My opinion is that the wrong IPAM is usually chosen when teams compare feature checklists instead of the operating model they will actually live with at 2 a.m.
Migrate Without Breaking Production
Our migration plan started by treating the spreadsheet as evidence, not truth. We froze edits, exported the rows, normalized hostnames, mapped subnets to sites and VLANs, and marked confidence levels before importing anything. Addresses confirmed by DHCP or switch ARP tables got higher confidence than rows last touched by an engineer who had left the company three years earlier.
We also kept IPAM read-only for the first two weeks. That frustrated a few people, but it gave my team time to compare NetBox against DHCP leases, DNS zones, FortiOS 7.4.3 address objects, and live scan results. When mismatches appeared, we fixed the source system or the IPAM record based on evidence, not seniority or memory.
The safest migration step was also the least glamorous: naming owners. Every prefix needed a business owner, technical owner, site, VLAN, and purpose. Without that, IPAM becomes another place where abandoned infrastructure goes to hide.
Ownership beats decoration.
We cut over allocation only after the data stopped surprising us. New static assignments had to come from NetBox, DHCP reservations were synchronized from approved records, and DNS updates followed the same workflow. My team still reviews exceptions, but exceptions are visible now, and visibility changes behavior faster than policy documents ever did.
Choose the Tool That Can Prove the Network State
I now judge IPAM tools by one question: can the platform prove that the address plan matches what is actually happening on the network? If the answer is no, I do not care how clean the interface looks. Manufacturing networks already contain enough silent assumptions, and address management should not add another one.
Commercial and open-source tools can both work. NetBox worked for us because we had the engineering muscle to integrate it, run it, monitor it, and keep data quality high. Infoblox would have been a stronger choice if we wanted the IPAM, DNS, and DHCP control plane bundled into one supported commercial system.
The key insight has held up through audits, maintenance windows, and new line deployments: IPAM without DHCP and DNS integration is just a spreadsheet with a nicer login page. The value comes from a single source of truth that updates automatically from actual network state, and I think that is the only standard worth defending.