Best way to create DHCP scopes when using MS IPAM?

Question

In DHCP there seems to be two approaches to configuring scopes and I have seen both, often on the same server.

One is to set the start and end addresses to the extremes e.g. 10.1.15.1-10.1.15.254 and then exclude blocks that are used as static ranges e.g. 10.1.15.1-10.1.15.50 & 10.1.15.200-10.1.15.254, giving 150 or so DHCP addresses and approx. 100 for static addresses.

The other method is to set the start and end addresses of the DHCP scope to purely the 'DHCP' part of the subnet. e.g. 10.1.15.51-10.1.15.200

Both work the same from a DHCP standpoint until you incorporate them into IPAM, where you get different results.

If I used the first approach and then 'find the next available address' the address it returns is the first available DCHP address.

If I use the latter approach, I obviously have to add another IP range to cover the 'static' range(s), but I can then 'Find the next available address' in the static (NON-DHCP) address.

Perhaps my confusion, Is which way is correct/better. Many examples I have seen seem to imply that static allocations could/should just be reservations within the DHCP scope, which to my old brain just seems wrong?

Does anybody have any thoughts on this or pointers to Best Practice?

Answer 1

Hi ,

Generally, we create DHCP reservations within the DHCP scope.

Here is an article talking about IPAM with DHCP, you could have a look:

https://rdr-it.com/en/ipam-installing-and-configuring-ip-address-management-on-windows/4/

Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

Best Regards,

Candy

Answer 2

Thanks for the link - a clear and well written article.

Your answer is perhaps what I expected. I can certainly see the advantage of using reservations as this causes less work and from an admin perspective is probably easier.

But with 25 years of IP address spreadsheets behind me I can also see the culture shock this approach may cause. I think the answer is to understand the current setup and recognise the benefits or problems each approach will bring.

Right now we have clients on the same subnets as servers on numerous networks and until that can be addresses having servers randomly spotted between clients in the DHCP range doesn't seem ideal, though I see there is no technical reason for this not to work (ignoring the security aspect of such shared subnets in the fist place).

Thanks & regards.