The Simplicity and Serenity of DHCP Fault Tolerance: Page 3
Configuring Redundant DHCP Servers
Having established that DHCP servers need not be on the same subnet as the clients they serve, we can now look more closely at exactly how to configure multiple DHCP servers to service a single subnet. This issue boils down simply to the use of scopes.
Multiple DHCP servers cannot serve addresses from the same scope. If you do configure two DHCP servers with the same scope, it won’t be long before duplicate IP addresses start to appear on the network. The solution is simply to distribute the range of available addresses across the DHCP servers. The generally accepted principle for doing this is referred to as the 80:20 rule.
As the name implies, the rule dictates that 80% of the available scope is defined on one of the DHCP servers, with 20% being defined in a scope on the other. For example, if you were using a scope of 192.168.1.1 to 192.168.1.100, you would configure a scope of 192.168.1.1 to 192.168.1.80 on one server (Server1), and a scope of 192.168.1.81- 192.168.1.100 on the other server (Server2).
Now, if one of the DHCP servers is down, there are addresses available in the scope on the other server to service clients from the 192.168.1 subnet. If you had another subnet, let’s say 192.168.2.1 to 192.168.2.100, you could reverse the 80:20 rule, by placing 20% of the scope on Server1, and 80% of the scope on Server2. You would then have DHCP fault tolerance for both subnets.
The obvious rationale behind the 80:20 rule is that during the period in which the failed server is down, the other server can service requests for addresses from that range. Only new address requests will be serviced, though, as the way that the DHCP leasing process works, a system that has been leased an address by one DHCP server will always attempt to renew the address with that server before giving up and contacting another DHCP server for a new address.
While configuring the 80:20 rule on the servers does not make up for a shortage of IP addresses, it will not make the situation any worse, either. If a server has no addresses left in its scope, it will simply ignore requests from clients for an address. When both servers are up and running, they can both reply to requests if they have available addresses. Likewise, when the servers run out of addresses, they run out. It is no different than how a single DHCP server would operate in this respect.
Given the simplicity of creating a fault tolerance DHCP implementation, if you do not already have it implemented, you should certainly consider doing so. Unlike so many other fault tolerant measures, there is no additional software or hardware to purchase. It’s simply a case of planning your implementation and putting it into place.
Feature courtesy of CrossNodes.com.