The DHCP Server supports the split scope redundancy
Split scope means that you simply run two DHCP servers each with a different IP range. A client asking for an IP address by broadcasting a DHCPDISCOVER message gets two answers. This adds network traffic but is otherwise not creating any trouble. The client will choose one of the answers (mostly the first it got). Once an IP address is assigned then the client will extend the lease by sending the DHCP message by unicast anyway and is therefore only talking to the chosen DHCP server. The client will reinitiate the complete process in case that server is down and does not reply to requests. The beauty of split scope redundancy is, that it only relies on standard DHCP protocol mechanisms. The client will simply get a new IP address from the other DHCP server and will be happy to talk to that server from now on. Another big benefit is that since the two DHCP servers never sync up, they don‘t need to be the same software or software version.
Configuration of server 1:
[Settings] IPPOOL_1=10.0.0.2-200 IPBIND_1=10.0.0.1 AssociateBindsToPools=1 Trace=1 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.254.0
Configuration of server 2:
[Settings] IPPOOL_1=10.0.1.2-200 IPBIND_1=10.0.1.1 AssociateBindsToPools=1 Trace=1 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.254.0
Please note that I have chosen a subnet mask of 255.255.254.0 which allows me to have twice as many IP addresses. The two servers are running on two different computers with the IP addresses 10.0.0.1 and 10.0.1.1, respectively. Each serve different IP ranges: 10.0.0.2-200 and 10.0.1.2-200.
The clients can talk to each other and to both servers with no problem, because they are all on the same subnet 10.0.0.1/23 but get IP addresses assigned depending on which server was chosen.
The only thing that needs to be taken care of is to set DNS_0 and ROUTER_0 dependent on your network infrastructure.
In case DHCP server acts as DNS server as well, then one problem exists. A DNS request reaching server 0 can not be fulfilled with data stored at server 1, and vice versa. Therefore, since V2.9 the SyncServer feature has been introduced. Here is the same example as above with the SyncServer feature enabled:
Configuration of server 1:
[Settings] IPPOOL_1=10.0.0.2-200 IPBIND_1=10.0.0.1 AssociateBindsToPools=1 Trace=1 SyncServer=10.0.1.1:80 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.254.0 [HTTP-SETTINGS] EnableHTTP=1
Configuration of server 2:
[Settings] IPPOOL_1=10.0.1.2-200 IPBIND_1=10.0.1.1 AssociateBindsToPools=1 Trace=1 SyncServer=10.0.0.1:80 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.254.0 [HTTP-SETTINGS] EnableHTTP=1
Please note that enabling the HTTP function is essential for this to work, because the sync mechanism simply utilizes the same communication as the status web page.