Deploying DHCP failover translates into deploying more DHCP servers working in an Active-Active or Active-Passive mode for a set of scopes/subnets. Given the limitations in certain older switches/routers on the number of IP helpers that can be configured, configuring additional IP helpers to reach these new servers can become a problem.
This problem can however be overcome by using a Windows server RRAS IPv4 DHCP relay agent to reach to the DHCP servers. By using a RRAS relay agent, the IP helpers still need to reach to only one IP address, that of the RRS relay agent. The RRAS relay agent in turn relays the DHCP packets from the IP helpers to the DHCP failover pair and vice versa. This new relay agent in the proposed solution puts a formation of cascaded DHCP relay agents (including the existing IP helper) in the network. The blog post describes how this cascading can be achieved.
Consider a normal DHCP server-client setup shown below:
There is a DHCP server, a DHCP client and an IP helper/relay agent which forwards the broadcast DHCP client messages from the DHCP client to the DHCP server as a unicast message and vice versa. Notice that the DHCP server and the client belong to different subnets.
Now the hardware on which the IP helper or the relay agent has been configured may connect clients from different subnets to the DHCP server. A switch, for example, may have 8 IP helpers connecting 8 different subnets to the DHCP server.
Now consider deploying DHCP failover in such a scenario. Failover for your DHCP server translates to deploying one more DHCP server. You will need to configure eight more IP helpers on the switch to point to the new DHCP failover server. But then you realize that the old switch that you have been using poses the constraint with a max limit of less than 16 IP helpers.
So what’s the solution? Deploying a Windows RRAS relay agent can help you out here.
Here’s what you can do. Introduce a Windows Server RRAS relay agent in the equation. Your altered setup with DHCP failover and the additional relay agent will then look something like the setup shown below.
DHCP Server 1 and DHCP Server 2 are the two DHCP servers which have been configured for failover. They could be in either of the two failover modes: Hot Standby or Load Balance. A Windows Server RRAS relay agent, Relay Agent 2, has also been put into place.
More on installing the RRAS role and configuring the IPv4 relay agent: http://technet.microsoft.com/en-us/library/dd458979.aspx
The IP helper configured on the switch, like before, needs to point to only one IP address, that of Relay Agent 2 (188.8.131.52). The IP addresses of DHCP Server 1 (192.168.1.1) and DHCP Server 2 (192.168.1.3) have been configured on Relay Agent 2 (RRAS relay agent can be configured to relay packets to the IP addresses of more than one DHCP servers). Also the default gateway on the DHCP failover pair for the subnets being served has been set to Relay Agent 2’s IP address (192.168.1.254). Relay Agent 2 forwards any DHCP message received from the IP helper to both members of the DHCP failover pair and one of the servers then responds to the packet.
The default gateway of Relay Agent 2 (at the adapter with address 184.108.40.206) will have to be set to send to that of the switch (220.127.116.11). This is to enable Relay Agent 2 to forward any packets received from the failover pair back to the switch, which would in turn send it to the DHCP client.
It should be noted that the extra RRAS relay agent deployed adds a single point of failure for the DHCP failover pair. This solution hence has its own disadvantages. But, it may be used as an interim solution till you retire the older switch/router for a newer one which allows for configuring large number of IP helpers.
So when being constrained by the hardware limitations on the number of IP helpers that can be configured; you can use a Windows Server RRAS relay agents to establish a communication channel between the IP helpers and the DHCP failover pair. The IP helpers which, in non-failover DHCP server deployments, would have pointed to the DHCP servers will now point to the RRAS relay agent. While this article talks about using Windows DHCP relay agent, the same deployment can be configured with any third party DHCP relay agents as well as long as they support at least 2 DHCP server IP addresses.
We hope that this post was of help. Do let us know your questions, comments and feedback.
Step-by-Step: Configure DHCP for Failover
Configure the IPv4 DHCP Relay Agent
Hi DHCP team,
a little off-topic, but so far I found no answer to this issue: I noticed that a node in Communication_Interrupted mode does not purge expired DHCP leases from its database. I've waited several days (test environment) but it just says '0 leases expired and 0 leases deleted' in the DHCP log although the scope was full of expired leases (leasetime and MCLT were both pretty short ~ 1h)
When the second node rejoined the failover cluster and the communication state switched back to Normal the expired leases were deleted in the next garbage collection cycle.
Is this by design? Did I miss the point of doing so?
Nils, Yes - this is by design. Expired leases are not purged during COMMUNICATION INTERRUPTED state. This is to prevent a duplicate IP address situation which can be caused in some rare (but possible) scenarios. However, once the DHCP server moves (or is moved) into PARTNER DOWN state, the expired leases will be purged.
If your scenario requires that expired leases be purged/reclaimed in COMMUNICATION INTERRUPTED state, you can add a registry value DhcpFailoverEnableCommInt (DWORD) under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters with a value of 1. This will enable purging of expired leases even in COMMUNICATION INTERRUPTED state.
I have been using another setup for the last 17 years for handling more DHCP server and PXE/WINPE boots with only using one helper address. All DHCP/PXE/WINPE devices are isolated to one subnet. My helper address then points to the broadcast adresse off the DHCP subnet. This way you can have alle the servers you need, and you can add/remove them as you wish, without any changes to the network.
Thanks Peter for sharing the information. Yes - this should work as well. Peter also shared that "In some network equipment, you might have to enable “directed broadcast” on the receiving DHCP server subnet for this to work."