Ensuring high availability of critical network services like DHCP figures high in the list of priorities for any enterprise. In an environment where clients get their IP addresses and network configuration automatically, uninterrupted network connectivity is dependent on the availability of DHCP service at all times. Let us consider for a moment what high availability of DHCP server is intended for:
- Any authorized computer which connects to the network should be able to obtain its IP address and network configuration from the enterprise DHCP service at all times.
- After obtaining an IP address, a computer shouldbe able to renew its lease and continue using the same IP address so that there is no glitch in connectivity.
Windows Server 2012 DHCP provides a new high availability mechanism addressing these critical aspects. Two DHCP servers can be set up to provide a highly available DHCP service by entering into a failover relationship. A failover relationship has a couple of parameters which govern the behavior of the DHCP servers as they orchestrate the failover. One of them is the mode of the failover operation – I will describe this shortly. The other is the set of scopes that are part of the failover relation. These scopes are set up identically between the two servers when failover is configured. Once set up in this fashion, the DHCP servers replicate the IP address leases and associated client information between them and thereby have up-to-date information of all the clients on the network. So even when one of the servers goes down – either in a planned or in an unplanned manner – the other DHCP server has the required IP address lease data to continue serving the clients.
There are two modes of configuring DHCP failover to cater to the various deployment topologies: Load Balance and Hot Standby. The Load Balance mode is essentially an Active-Active configuration wherein both DHCP servers serve client requests with a configured load distribution percentage. We will look at how the DHCP servers distribute client load in a later post.
The Hot Standby mode results in an Active-Passive configuration. You will be required to designate one of the two DHCP servers as the active server and the other as standby. The standby server is dormant with regard to serving client requests as long as the active server is up. However, the standby server receives all the inbound lease updates from the active DHCP server and keeps its database up to date.
The DHCP servers in a failover relationship can be in different subnets and can even be in different geographical sites.
The support of these two modes enables a wide range of deployment topologies. The most rudimentary one is where two servers in a Load Balance or Hot Standby mode serve a set of subnets which are in the same site.
A slightly more involved deployment where failover is being deployed across two different sites is illustrated in Figure 1. Here, the Hyderabad and the Redmond site each have a local DHCP server servicing clients in that site. To ensure high availability of the DHCP service at both the sites, one can setup two failover relationships in Hot Standby mode. One of the failover relationships will comprise all subnets/scopes at Hyderabad. It will have the local DHCP server as the active server with the DHCP server at Redmond as the standby. The second failover relationship will comprise all subnets/scopes at Redmond. It will have the local DHCP server as the active server and the DHCP server at Hyderabad as the standby.
Figure 1: DHCP Failover Deployed Across Two Sites
This deployment construct of two DHCP servers backing up each other for two different set of scopes via two failover relationships is extensible to more than two sites. One can visualize a ring topology involving multiple sites where a server at each site - in addition to being the active server for the local network – is the standby server for another site. The failover relationships can be set up to form a ring topology through the DHCP servers at different sites.
Hub-and-Spoke is another multi-site deployment topology which lends itself quite well to how organizations are looking to deploy failover. Here, a central DHCP server acts as the standby for multiple active DHCP servers each of which serves a different branch office.
Windows DHCP server has so far met the HA requirement by enabling hosting of the DHCP server on a Windows Failover Cluster or by split scope deployments. These mechanisms have their own disadvantages. The split scope mechanism relies on configuring identical scopes on two DHCP servers and setting up the exclusion ranges in such a fashion that 80% of a subnet’s IP range is used for leasing out IP addresses by one of the servers (primary) and remaining 20% by the other server (secondary). The secondary server is often configured to respond to clients with a slightly delayed response so that clients use IP addresses from the primary server whenever it is available. Split scope deployments suffer from two problems. IPv4 subnets often run at utilization rates above 80%. In such subnets, split scope deployment is not effective given the low free pool of IP addresses available. The other issue with split scope is the lack of IP address continuity for clients in case of an outage of the primary server. Since the IP address given out by the primary DHCP server would be in the exclusion range of the secondary server, the client will not be able to renew the lease on the current IP address and will need to obtain a new IP address lease from the secondary server. In the case of split scope, the two DHCP servers are oblivious to each other’s presence and do not synchronize the IP address lease information.
To host the DHCP server on a Windows Failover Cluster, the DHCP database needs to be hosted on a shared storage accessible to both nodes of a cluster in addition to the deployment of the cluster itself. DHCP servers running on each node of the cluster operate on the same DHCP database hosted on the shared storage. In order to avoid the shared storage being the single point of failure, a storage redundancy solution needs to be deployed. This increases the complexity as well as the TCO of the DHCP high availability deployment.
The Windows Server 2012 DHCP failover mechanism eliminates these shortcomings and provides a vastly simplified deployment experience. Moreover, DHCP failover is supported in all editions (Foundation, Standard, Data Center) of Windows Server 2012. As one of the server reviewers aptly put it, this is high availability of DHCP on a low budget!
DHCP failover can be configured using the DHCP MMC as well as the DHCP PowerShell cmdlets. Everything you can do via the MMC for DHCP failover is achievable via the DHCP PowerShell cmdlets as well. The DHCP MMC provides a Failover Setup wizard which greatly eases the setup of failover. There are two launch points in the DHCP MMC from which a user can start the wizard. The right click menu options on the IPv4 node now have a Configure failover… option. If launched from here, all the scopes on the server which are not yet setup for failover are selected for failover configuration. Alternatively, if you select one or more scopes and right click, you will see the same Configure Failover… option. If launched in this fashion, only the selected scopes are configured for failover. Please see the step by step guide to setup failover using DHCP MMC. You can download the “Understanding and Troubleshooting guide” here.
For the command line users, DHCP PowerShell provides the following PowerShell cmdlets for setting up and monitoring failover:
In addition to these, Get–DhcpServerv4ScopeStatistics cmdlet which returns scope statistics has a “-failover” switch. Specifying this switch causes the cmdlet to return failover specific statistics for scopes which are configured for failover.
In conclusion, DHCP failover in Windows Server 2012 provides a high availability mechanism for DHCP which is very easy to deploy and manage and caters to the critical requirements of continuous availability of DHCP service and IP address continuity for the clients. Early adopters of the feature have shared our enthusiasm for this critical DHCP functionality and feedback from them has been very positive.
Give it a spin on Windows Server 2012 Release Candidate and we hope that you will find it useful!
Great stuff. Been wanting something like this for quite some time...
@Stewart, Agreed it is SO nice to see code changes on bits of the OS that haven't seen an update like this since NT4!
There is an error in the text: There is no Enterpise Edition for Windows Server 2012.
Quote: "DHCP failover is supported in all editions (Foundation, Standard, Enterprise, Data Center) of Windows Server 2012. As one of the server reviewers aptly put it, this is high availability of DHCP on a low budget!"
Thanks Thorsten for noting that! The reference to enterprise edition has now been removed from the blog.
Also, if you change the lease duration for a scope in one server, it won't replicate to the other server. You have to micromanage that setting along with the other settings that I mentioned, on each server.
You can replicate any scope configuration including lease duration, options, reservations etc using the "Replicate scope" action provided in DHCP MMC. This will replicate the scope configuration to the partner DHCP server.
I have configured the two windows 2012 std server on two different site with DHCP fail-over service. i just want to know how the fail over works.. ? should i need to add the partner IP in my network switches (Ip helper address) so that in case of primary server fail host can reach up to partner server ??
Your urgent response in this regard will be highly appreciated..
You need to add IP addresses of both the DHCP servers in your network switches as IP helper addresses. This will ensure that DHCP client requests (broadcast messages) reach both the DHCP servers. If you have configured a load balanced failover, only one of the servers will respond to a given client when the failover relationship is in NORMAL state i.e. both servers are up and running and able to communicate with each other. The servers compute a hash of the MAC address of the client and have an a-priori understanding of which hash will be served by which server. When one of the servers goes down , the failover relation moves into COMMUNICATION INTERRUPTED state (Lost contact with partner). While in this state, the server will respond to all client requests.
Erm, replication of allow\deny MAC filter? I'm surprised this feature was completely missed out, we rely upon this in our organisation to prevent anyone from just plugging a device in, it seems this is the only aspect the Server 2012 replication doesnt handle, am I mistaken?
Hi Ross, DHCP failover does not provide for replication of server level/wide configuration. Allow/Deny MAC filter is a server level/wide configuration. The reason this is not provided for is because a DHCP serve can participate in more than one failover relationships with different partner DHCP servers. In such scenarios, replicating server level configuration can lead to undesirable resultant server level/wide configuration. If your server has a single failover relationship or a allow/deny MAC address filter list that applies to all servers, you can setup a regular sync between the DHCP servers by writing a simple PowerShell script and integrating it with Windows Task Scheduler so that it runs on a periodic basis.
Let us know if you have further questions.
I'm currently testing this new feature and It's a great improvement from clustering DHCP with 2008r2.
One issue though - I've configured a hot standby failover setup for my DHCP servers. For testing purposes I've set state switchover interval to 10mins, and MCLT to 5 minutes.
I see from the event logs the relationship status changes from:
NORMAL to COMMUNICATION_INT
then 10mins after:
COMMUNICATION_INT to PARTNER_DOWN.
Which is expected. However, 5mins after that I should expect my second DHCP server to take ownership of the scopes I've specified. However, the DHCP MMC snap in tells me that I only have 5% of address available in the secondary DHCP server's pool for both scopes. Am I right in assuming this should go to 100% after the MCLT time has expired?
The statistics are not updated to reflect the fact that second DHCP server has taken ownership of the entire address pool of a scope. So, you will not see address available on the second server go to 100% after MCLT expiry in PARTNER DOWN state.
I was wondering if the Active-Passive mode can be used on more than two servers. We currently have a centralized DHCP server. One of our schools had their fiber cut and could not log in to local resources. We would have 12 schools that fall in to this scenario. So, could we set up Active-Passive with that many servers? Thanks.
Yes - you can use active-passive (hot standby) mode or active-active (load balance) mode on more than 2 servers. But this will have to be for a different set of scopes. Here is how I see it getting deployed in your scenario. Lets say each of the 12 schools have few scopes/subnets e.g. School1_scope1 and School1_scope2 for school1. You will deploy one DHCP server at each of the 12 schools. The DHCP server at each school will have scopes of that school configured e.g. School 1 DHCP server will have School1_scope1 and School1_scope2. Likewise for each of the 12 schools. You will then configure a failover relation in hot standby mode from each of the school DHCP servers to the central DHCP server e.g you will create a failover relation - School1-Central which has School1_scope1 and School1_scope2 as part of that failover relation. Likewise for each of the 12 schools. The central DHCP server now will have 12 failover relations each of which is with a different school DHCP server. The central DHCP server will be standby server for each of the failover relation. The DHCP server at each school will have a single failover relation for which it will be the active server.
With this deployment, the DHCP server local to the school will lease IP addresses to the computers/devices at that school. If the DHCP server local to the school goes down, the clients at that school will get DHCP service from the central DHCP server which would have now turned "active" but only for the scopes of that specific school.
This deployment topology is referred to as hub-and-spoke. You can read a blog about it here - blogs.technet.com/.../multi-site-deployment-topologies-for-dhcp-failover.aspx.
You will need to ensure that the DHCP relays at each school are configured to relay DHCP client messages to both the DHCP servers - central server and local server.
Let us know if this deployment topology would work for you.
Thanks for this. One other question, can the setup be reversed? You describe the scenario for the schools being active and the central server being passive. Can we reverse that and have the central server be the active server and the school sites be passive and only become active if communication to the central server goes down?