DHCP Server on Two Subnets in a Single Shared Network

I’ll keep this post about your situation specifically.

First and foremost, managing over 3,000 devices with static IP addresses is just plain foolish. DHCP is a well-known and established protocol that solves the tedious task of manually assigning and fixing manual IP addresses. If they are that concerned about making sure they have control over every IP address on their network, set them as DHCP reservations. Even from a security standpoint, you don’t stand to benefit that much from eliminating DHCP servers.

By sticking with this route, you will lose:

• Change management capabilities
• Customer insight

The big hitter on this list is change management capabilities. If you need to swap IPs around, you really don’t have a good way to do this; and that makes (or will make) your life arduous. If your teammates aren't on board with it and want to stick with their old ways, try to rope in your management and inform them of what a colossal waste of time it is.

Regarding your nifty IP scheme; you will still be able to maintain that; If anything, to a greater degree. IPAM gives you the capability to drill down into smaller and smaller subnet ranges, making it seemingly easy to implement in your case. This will allow you to cascade further and further down into the building/device class you desire.

According to the DHCP RFC (2131) it is the responsibility of both the server and client to detect duplicate addresses. The server should check using ICMP or similar and the client should check using ARP or similar:

In some environments it will be necessary to reassign network addresses due to exhaustion of available addresses. In such environments, the allocation mechanism will reuse addresses whose lease has expired. The server should use whatever information is available in the configuration information repository to choose an address to reuse. For example, the server may choose the least recently assigned address. As a consistency check, the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP.

In the case where the client detects it has received a duplicate address, it must reject the address with DHCPDECLINE and then attempt to obtain another address after a backoff period.

The client receives the DHCPACK message with configuration parameters. The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured. If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process. The client SHOULD wait a minimum of ten seconds before restarting the configuration process to avoid excessive network traffic in case of looping.

Note: all of these statements use the SHOULD key word, so although they are recommended, they are not mandatory (apart from the address rejection which is mandatory)

RFC 5227 provides more details on how clients can carry out IPv4 Address Conflict Detection