Sysadmin

Hi all. I'm not ready to die on this hill, but I am willing to suffer some serious injuries.

Here's the question: Should an IPAM product hand out static IPs when called upon by API for next available address?

Say I setup a machine on vRA using API calls to an enterprisey-IPAM solution using their documented API to poll, and perhaps subsequently pull, the next available IP address.

The API assigns an IP, but the IP assigned is the next IP available in a static range, not an IP address in an established and advertised DHCP range. Thus, any of a number of reserved static IPs will be dynamically assigned via API. The API is not using the IPAM product's built-in DHCP server to dynamically assign addresses. The IPAM product's DHCP and DNS are authoritative.

Bug, or feature?

As an engineer, my take is that the API calls should always pull from DHCP. Static IPs must be considered to be reserved, even if marked unused in IPAM, and should never be assigned whereas DHCP keeps records of IPs assigned and can be trusted to hand out an IP not being used. The idea is, when a new machine is brought online and gets an IP, that machine can either retain the DHCP-assigned addresses or I can assign it a static IP if necessary. Never, ever should my IPAM product think it is OK to hand out a ~~private~~ static IP address.

I can see how some people flip this and want their DHCP pools to be untouched by IPAM, but that's just backwards in my eyes.