I have a network having two servers that are occasionally booted. I wish to maintain DHCP services even during a boot of one server.

One of the servers currently has a DHCP server that gives static IP addresses. It gives addresses only to users with an allowed MAC address, and each user has a fixed IP. No dynamic IPs are there.

Is it possible in this setup to run two DHCP servers in the same network in different servers for redundancy? I'm not looking for a solution where the IP address sets of two servers are disjoint; I'm looking for a solution where the IP addresses both servers give are static and the same.

I am mostly interested about the general concept: can DHCP as a protocol support two DHCP servers giving same static IP addresses? Do clients get confused if they get a response from two servers with the same lease IP address? This is why I didn't specify what DHCP server I am using. I am specifically not requesting instructions for host / server configuration.

I originally asked this in Network Engineering, but they seem to have a habit of closing perfectly valid non host / server configuration related network engineering related questions using some unknown random algorithm, saying that the question is about host / server configuration (which it isn't; it's about the protocol) and the question is about a protocol above OSI layer 4 (which it is, but then again they have numerous DHCP questions there and not all get closed).

  • Have you tried it out? My gut tells me that you might trigger network protections in smarter network gear, and the hosts may prefer to seek out an IP from their previous DHCP server, but the worst case I see is that one of the DHCP servers is ineffective, meaning no redundancy. I suspect it will work okay. Ensuring the DHCP servers stay in sync may be the hard part. – Slartibartfast Jul 28 '18 at 5:24
  • No, I haven't tried it yet. Not sure if production network is the proper location for such a trial... On a trial network, such as Linux containers / network namespaces, it could be tried with little difficulty. Perhaps I'll do that. – juhist Jul 28 '18 at 5:27
  • 2
    kb.isc.org/article/AA-00502/0/… – yoonix Jul 28 '18 at 7:01
  • DHCP can handle this. ISC DHCPD, for example, has documentation describing how this could be set up. I've not tried it, though, so I don't class this as a proper "answer". (Ah. Just noticed yoonix has referenced the same document.) – roaima Jul 28 '18 at 9:30
  • Related: paulroberts69.wordpress.com/2011/10/27/… and tools.ietf.org/html/draft-ietf-dhc-failover-12 -- it seems it's not an RFC but rather an Internet draft. – juhist Jul 28 '18 at 10:01

A couple of things:

To say that these reserved ip addresses are not dynamically assigned is inaccurate. They are dynamically assigned. The point is that they are reserved ip addresses so that the DHCP client is always dynamically assigned the same ip address. These are not statically assigned ip addresses. They are dynamically assigned, reserved ip addresses.

There's nothing stopping you from creating the same reservations on both DHCP servers. This doesn't require any special configuration of DHCP (at least in Windows DHCP server). A DHCP client that has a reservation will acquire it's ip address from one of the two DHCP servers. It doesn't matter which. During the client renewal phase (T1) the client will attempt to renew the ip address from the DHCP server that assigned the ip address to the client. If the client is unable to renew the ip address from the DHCP server that assigned the ip address to the client (because the DHCP server is down) then the client will release the ip address and attempt to acquire an ip address from any DHCP server. The second DHCP server will then service the client, and because it has the same reservation for the client, will assign the client the same ip address that the first DHCP server assigned. This process will operate the same way during the rebinding phase (T2).


I do this myself. I use two VMs running FreeBSD. Each VM runs the FreeBSD port of ISC's DHCP server (https://www.isc.org/downloads/dhcp/). That software can have two (and no more) servers in a high availability pairing. Each one communicates with the other. If they're both running, they provide load balancing. If only one is running, it realizes it and immediately takes over all services.

I have to keep some configurations in sync between the servers myself. To do this, I use an rsync command and have carefully put some configurations (e.g. static IP mappings, DHCP dynamic pools, etc.) in one set of files while placing anything specific to each host in a different file which I don't rsync.

Any time I need to make a change, I just edit the files on one server, restart the DHCP server process, watch the logs until I'm sure it is running correctly (5 - 120 seconds), and then rsync the files over. I use an SSH key on root on the other server, to make the rsync a tiny bit easier, but that isn't necessary. Then I SSH over to the other host and restart it's DHCP server process, watch the logs, and so on.

Thanks to writing documentation with a checklist, this whole process can take me as little as 3 - 5 minutes.

Lastly, and perhaps most easily overlooked, I have an extra ip helper-address command in my network's core switch. The first command points to the first DHCP server's IP address and the second command points to the second DHCP server's IP address. Individual network clients will get an answer from one or the other DHCP server, since both servers are in contact with each other and coordinate things between themselves.

I can post some more details and examples, if you're interested. There is some decent documentation from ISC themselves, too. Really, the big "tricks" are synchronizing the configuration between the two ISC-DHCP instances and using two DHCP forwarding commands in your topology, e.g. "ip helper-address" in Cisco's iOS products.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.