phpIPAM IP Address Management Deployment

IP address management fails in a spreadsheet the moment two people need an address at the same time, and it fails silently in a CMDB that nobody updates. phpIPAM occupies the useful middle: a web application with subnet tree, VLAN domain mapping, address status tracking, automatic discovery against live network data, and a REST API that lets provisioning scripts allocate addresses without a human. This guide covers a production deployment, the data model decisions that determine whether it stays accurate, discovery and scanning configuration, and API automation for zero-touch provisioning.

Install

sudo apt install -y apache2 mariadb-server php php-cli php-mysql php-gmp php-curl \
  php-mbstring php-xml php-snmp php-bcmath php-gd php-ldap
sudo mysql -e "CREATE DATABASE phpipam CHARACTER SET utf8mb4;
  CREATE USER 'phpipam'@'localhost' IDENTIFIED BY '<db-password>';
  GRANT ALL ON phpipam.* TO 'phpipam'@'localhost'; FLUSH PRIVILEGES;"

cd /var/www/html
sudo git clone https://github.com/phpipam/phpipam.git
sudo chown -R www-data:www-data phpipam
# configure config.php with the DB credentials, then run the installer in the browser
# http://ipam.example.com/install/  -> creates tables and the admin account

Run the installer once, then delete the install/ directory and pin the application behind HTTPS. phpIPAM stores device credentials for scanning — treating the install directory as disposable is part of keeping them contained.

The data model: sections, subnets, VLAN domains

Section  (business unit / security zone)
 └── Subnet        10.20.0.0/24      VLAN 20, gateway 10.20.0.1
      ├── Address 10.20.0.15/32      hostname, MAC, owner, description
      └── Address 10.20.0.16/32
 └── Subnet        10.20.1.0/24      nested /25s allowed
VLAN domain → VLAN 20 → subnet 10.20.0.0/24
Device types: router, switch, server, printer, firewall

• One section per operational boundary. Sections can have different permissions, so separating production from lab from customer networks is a security decision made once.
• Use VLAN domains to tie VLAN IDs to subnets. The same VLAN number in two domains is legal and common in multi-tenant designs; without domains the mapping becomes ambiguous.
• Reserve the first addresses for gateway, HSRP/VRRP virtual IP and broadcast before you start allocating — the scanner will happily mark them as free otherwise.

Address states that make the tool trustworthy

Offline  - allocated but not yet in use
Used     - confirmed in use (manual or discovered)
Reserved - held back for future growth or a role
DHCP     - handed out by a DHCP server
Nat      - public address mapped to a private one

Operational rule: an address transitions to Used only with evidence — a ping response, an ARP entry, or a discovery match. Everything else stays Offline with an owner and an expiry date. Marking addresses used "to be safe" destroys the one question IPAM exists to answer: which addresses are actually free.

Discovery: reconcile the database with reality

# Administration -> Scan agents -> create an agent on a host with reachability
# then per subnet: Subnet -> Scan -> enable ICMP, ARP and DNS resolution

# manual check from the shell, matching what the scanner does
fping -a -g 10.20.0.1 10.20.0.254 2>/dev/null
ip neigh show | grep 10.20.0.
snmpget -v3 -l authPriv -u ipam -a SHA -A '<auth>' -x AES -X '<priv>' \
  10.20.0.1 1.3.6.1.2.1.4.22.1.2

# via the API
curl -s -H "token: <app-token>" https://ipam.example.com/api/my_app/addresses/10.20.0.15/

ARP scanning is the highest-value discovery method on a flat L2 segment because it sees silent hosts that drop ICMP; ICMP is faster but misses hosts that block pings. Run both, and schedule scanning outside change windows — a scan that marks an address free and then has it allocated by a script creates a duplicate address, which is the exact failure IPAM should prevent.

API automation for provisioning

# create an application and get a token
curl -s -X POST https://ipam.example.com/api/my_app/user/ \
  -H "Content-Type: application/json" \
  -d '{"username":"api-user","password":"<password>"}' | jq -r '.data.token'

# find the first free address in a subnet and mark it used
curl -s -H "token: <app-token>" \
  "https://ipam.example.com/api/my_app/subnets/12/first_free/" | jq '.data'

# allocate it with a hostname and description
curl -s -X POST -H "token: <app-token>" -H "Content-Type: application/json" \
  https://ipam.example.com/api/my_app/addresses/ \
  -d '{"subnetId":"12","ip":"10.20.0.57","hostname":"web-07","description":"provisioned by ansible"}'

# register a new subnet in the tree
curl -s -X POST -H "token: <app-token>" -H "Content-Type: application/json" \
  https://ipam.example.com/api/my_app/subnets/ \
  -d '{"subnet":"10.20.8.0","mask":"24","sectionId":"2","description":"rack 8 servers"}'

Wire this into whatever creates the workload. A virtualisation platform that allocates an address from phpIPAM at build time removes the manual step entirely; the same pattern is used by zero-touch switch provisioning, described in the ZTP deployment guide. Keep the API token scoped to the minimum section it needs, and rotate it on the same schedule as other service credentials.

Verification and ongoing accuracy

curl -s -H "token: <app-token>" https://ipam.example.com/api/my_app/subnets/12/ | jq '.data | {subnet, mask, used, free}'
curl -s -H "token: <app-token>" "https://ipam.example.com/api/my_app/subnets/12/addresses/" | jq '.data | length'
mysql -e "SELECT COUNT(*) FROM subnets WHERE isFolder=0" phpipam

1. Every production subnet exists with the correct mask and gateway.
2. Address counts reconcile: allocated plus free equals the usable host count (minus reserved infrastructure).
3. A discovery run finds the same hosts your monitoring system knows about — discrepancies are either monitoring gaps or IPAM gaps, and both matter.
4. The API can allocate and release an address idempotently when a build retries.
5. Users exist in groups matching your role model; nobody allocates addresses as an administrator by habit.

Operations

• Back up the database nightly and test a restore — an IPAM database is small and its loss is expensive.
• Enable the change log and review a weekly report of who allocated what; unattributed allocations are how accuracy decays.
• Add custom fields for the things you actually need during an incident: asset owner, ticket reference, and whether the address is inside a NAT pool.
• Feed allocation data to the network automation pipeline instead of typing addresses into templates. The same inventory discipline is what makes template-driven configuration safe to run unattended.
• Reconcile against DHCP leases monthly; duplicated addresses between the static and dynamic pools are silent until a customer complains.

原文链接：https://phpipam.net/documents/