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.
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
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.
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?
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 10.10.1.1-100 and Server 2 handles DHCP for 10.10.1.101-200. 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 10.10.1.0/24.