Microsoft Windows DHCP Team Blog

The world's most deployed DHCP Server! Deploy and discuss about your fav. server, here!

Multi-Site deployment topologies for DHCP Failover

Multi-Site deployment topologies for DHCP Failover

  • Comments 25
  • Likes

The two modes of configuring DHCP Failover Load Balance and Hot Standby enables a wide range of deployment topologies involving failover deployment between the DHCP servers present in the same site or spread across multiple sites.

The most rudimentary one is the single-site deployment, where both the servers in a failover relationship are located at the same physical site. The two servers can be either in a Load Balance or Hot Standby mode and serve a set of subnets which are in the same site. Load balance mode is more suited for this kind of deployment because both servers can respond to DHCP client requests without any network latency. The clients remain agnostic of which server is serving the IP Addresses and the other DHCP options. 

There are a lot of variations possible in the multi-site deployment scenarios. The deployment can be done involving 2 or more sites. Below are some of the standard topologies.

Symmetric Relationship

The 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. In the scenario shown below, the site 1 and the site 2 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 site 1. It will have the DHCP server at site 1 as the active server with the DHCP server at site 2 as the standby. The second failover relationship will comprise all subnets/scopes at site 2. It will have the DHCP server at site 2 as the active server and the DHCP server at site 1 as the standby.

Figure 1: Symmetric Model

Ring Topology

The symmetric model can still be enhanced and visualized as 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 (as shown in the illustration below) through the DHCP servers at different sites.

For example, in the illustration in Figure below, in the event of DHCP server 1 being down, the computers and devices on site 1 will be provided DHCP service by DHCP server 4 located at site 4 and likewise for all the other sites. In such a deployment each DHCP server will have 2 failover relationships - one for which it is active (this will have the subnets/scopes of the local site) and the other for which it is standby (this will have the subnets/scopes of the remote site)


Figure 2: Ring Topology


Hub and Spoke Model

The other variation in case of a multi-site deployment is where each remote site has a local server which is configured to provide the DHCP service to the computers and devices on the local network. That is it acts as a primary active server for the local network.  Another DHCP server at a central office or data center acts as a secondary for all the remote sites.

In a normal mode of operation, computers and devices on a given site receive IP addresses and other network configuration (options) from the DHCP server located at the same site. However, in the event of the local DHCP server being down, the DHCP server from the central site would provide the service. When deployed in this fashion, each of the remote site DHCP servers will have single failover relationship with the hub DHCP server. The hub DHCP server will have as many failover relationships as the number of remote sites (spokes) - for each of which its a secondary/standby server.

Hot standby mode of operation is best suited to such kind of deployments where a central office or data center server acts as a standby backup server to a server at a remote site, which is local to the DHCP clients. In such deployments, it is undesirable to have computers and devices on a site being served by the DHCP server at the remote site unless the local DHCP server becomes unavailable because of delays associated with communication over the inter-site link and unwarranted traffic on the inter-site link.


Figure 3: Hub-and-Spoke Model

Besides these deployment topologies, DHCP failover can be deployed in several other variations of aforementioned deployment topologies.

You can also have a DHCP server be part of a load balance and a hot standby failover relationship (each for a different set of scopes of course) at the same time.

Other Links



  • Are you considered a super-nerd when you get excited about DHCP? This is truly awesome and at the same time soooo overdue! Good Work!

  • In a symmetric model (or any multi-site model really), how does the network know where to send DHCP requests?

  • Steven,

    You need to configure the DHCP relay agent/IP helpers on switch/router to forward the traffic to IP addresses of both the DHCP servers in the failover relation.

  • Any idea if is possible to have a hub site active / active pair also server as stand by for a spoke site active / passive configuration?

  • Ian, a failover relationship can be only between 2 DHCP servers and is associated with a set of scopes.
    lets say you hub site has scopes 1 thru 5 and are setup for DHCP failover on server1 and server 2 at the hub. You can have a server3 at a spoke site with a failover relationship (with scopes 6 thru 10) to server 1 or server 2 serving as standby. But if you already have server 3 and server 4 in a failover relationship (with scopes 6 thru 10), you cannot have another failover relationship with server1 or server 2 for the same scopes.
    If you need more than one level of redundancy, you can combine DHCP Failover with Windows clustering.
    For example, server 1 and server 2 are on a Windows clustered and the clustered DHCP server has a failover relationship with server 3 which is standalone or again on a Windows cluster.

  • If we split scopes, for example Server 1 handles DHCP for and Server 2 handles DHCP for Can we still have a failover relationship for these two servers with 2 backup servers?

  • Chris, with DHCP failover you _do_ _not_ need to use split scope. You should configure server 1 and server 2 with a failover relationship for scope

  • if I want to have 2 DHCP servers in HO site and highly resilient on DR site. what is the best way to do that ? instead of using DHCP cluster can I have 50/50 scopes across 2 DHCP server in HO site, and 2 standby servers on DR site ???

  • Salah, there are 2 options
    - Deploy DHCP on a 2 node Windows Failover cluster at HO site. Separately, deploy DHCP on another 2 node windows failover cluster at DR site. Now, create a Hot standby DHCP failover relationship between the two.
    - Configure 80/20 split scope between the DHCP server at HO and DHCP server at DR site. Then configure DHCP failover at HO with another DHCP server. In this configuration, be aware that your DR site has only 20% of the IP address pool.

  • Salah, you can look at which talks about the first option that I mentioned above.

  • I currently have 2 consolidated DHCP server at my HQ serving all the regions across the country. its on a DHCP failover load balancer. But I need to create another DHCP server {just one} on a DR site, & I want it to be on a Hot standby mode so date I can always use it when the main site goes down. Any help as regards to this.

  • Victor, DHCP failover does not support more than 2 servers hosting the same set of scopes. This as per the IETF DHCP failover spec. You will need to use a combination of DHCP failover and Windows clustering to achieve what you want. See

  • thanks for the response, please how do I go about the Clustering since am currently using two Virtual machines has my DHCP servers. Any documentation I can use please?

  • Victor, see this link for setting up DHCP server on a Windows failover cluster -

  • hi, the example in the link above for the clustering is for Windows server 2008 R2. its not going to work in my environment because am using virtual machines running windows server 2012 R2. Can I have a scenario that works for 2012 R2 or a documentation on how to go about it.


Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment