This is a Canonical Question about Redundant DHCP Servers.

Is it possible to have more than one DHCP server on the same LAN? What are the implications of doing this?

  1. What happens if there is more than one DHCP server available? How do my clients know which one to use?
  2. How can I have DHCP servers supplying addresses to more than one subnet\network segment?
  3. How can I configure multiple DHCP servers to supply addresses for the same subnet.

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

  • 1
    The idea behind this question is to give a definitive answer for all the "How can I have more than one DHCP Server" questions that drive our more regular users crazy. This will hopefully become one of our canonical answers (…) – Rob Moir Mar 11 '12 at 11:02
  • 2
    RTFM? (and rfc 3074) already define this behavior, and linux dhcpd implements it… – Dani_l Aug 9 '14 at 20:55
  • 1
    @Dani_l perhaps you should follow the 'canonical question' link in the question and also maybe review the authors of the answers to my question here before telling me I need to RTFM. – Rob Moir Aug 10 '14 at 5:48
  • 2
    I'm not telling YOU to read the manual. I merely point out that there IS a manual. The question is canonical, but, when applicable, I believe it should include reference to "official" procedures, if such exist. In this case, an IETF/RFC exists, and that's as official as it gets. – Dani_l Aug 11 '14 at 7:54
up vote 88 down vote accepted

I’m assuming a basic knowledge of what DHCP does and how to configure your DHCP server of choice in this answer, but before we talk about multiple DHCP servers on the same network, let’s first of all quickly re-cap how clients receive IP addresses from DHCP at the most basic level.

DHCP on a simple network works using the DORA principle.

  • Discovery - the client broadcasts a message on the local network segment its connected to, to discover available DHCP servers.

  • Offer - a suitably configured DHCP server receives a request from a client, and offers it an address from its pool of available addresses.

  • Request - The client replies to the offer, requesting the address received in the Offer.

  • Acknowledgement - The server acknowledges the request, marking the address as used in its pool of addresses, and informs the client of how long the address lease is valid for, and any other information needed.

Any device on a network segment can be a DHCP server; it doesn't have to be the router or the domain controller or any other "special" device on the network.

When the devices on your network first request an IP address or reach the end of their leases (or you force them to check their lease is still valid) they will simply broadcast a request for a DHCP server, and will accept an offer from the first DHCP server to reply. This is important to remember as we look at the options for multiple DHCP servers below.

Multiple DHCP servers PT 1: Spanning multiple subnets.

If you have several VLANs or physical network segments that are separated into different subnets, and you want to provide a DHCP service to devices in all those subnets then there are two ways of doing this.

  1. If the router / layer 3 switch separating them can act as a BOOTP/DHCP relay agent, then you can continue to keep all your DHCP server(s) in one or two central parts of your network and configure your DHCP server(s) to support multiple ranges of addresses. In order to support this, your router or layer 3 switch must support the BOOTP relay agent specification covered in section 4 of RFC 1542.

  2. If your router does not support RFC 1542 BOOTP relay agents, or if some of your network segments are geographically dispersed over slow links, then you will need to place one or more DHCP server in each subnet. This ‘local’ DHCP server will only serve its own local segment’s requirements, and there is no interaction between it and other DHCP servers. If this is what you want then you can simply configure each DHCP server as a standalone server, with the details of the address pool for its own subnet, and not worry about any other DHCP servers on other parts of the network. This is the most basic example of having more than one DHCP server on the same network.

Multiple DHCP servers PT 2: DHCP servers that serve the same network segment.

When most people ask about “multiple DHCP Servers on the same network”, what they are usually asking for is this; they want more than one DHCP server issuing the same range of network addresses out to clients, either to split the load between multiple servers or to provide redundancy if one server is offline.

This is perfectly possible, though it requires some thought and planning.

From a “network traffic” point of view, the DORA process outlined at the start of this answer explains how more than one DHCP server can be present on a network segment; the client simply broadcasts a Discovery request and the first DHCP server to respond with an Offer is the ‘winner’.

From the server’s point of view, each server will have a pool of addresses that it can issue to clients, known its address scope. DHCP servers that are serving the same subnet should not have a single “shared” scope, but rather they should have a “split” scope.

In other words, if you have a range of DHCP addresses to issue to clients from to, then both servers should be configured to serve separate parts of that range, so the first server might use parts of that scope from to and the second server would then issue to

Split DHCP scope, showing exclusions

Microsoft's more recent implementations of DHCP have a wizard to make splitting your scope like this easy to do, described in a Technet article that might be worth looking at even if you're not using the Microsoft DHCP implementation, as it illustrates the principles talked about here quite nicely and this answer is already long enough.

Splitting the scope – best practice

One thing you’ll hear mentioned as best practice is the 80/20 rule for splitting a DHCP scope, which means that one server will serve 80% of the addresses in that scope and the other DHCP server, which is effectively ‘in reserve’ will serve 20% of the addresses.

The idea behind splitting the addresses 80/20 is because 80% of the addresses available should hopefully be adequate for all the addresses needed on a subnet, and DHCP leases are typically issued for several days; so if your main DHCP server goes down for a few hours then it's unlikely that more than 20% of the machines on that subnet will need to renew their addresses during the downtime, making the 20% pool of addresses sufficient.

This is still reasonable advice, but it assumes two things:

  1. That you can solve any problem with your “main” DHCP server quickly enough to avoid exhausting the small pool of addresses on your reserve DHCP server.
  2. That you’re not interested in load balancing.

These days (as you can see from my examples) I tend to prefer 50/50 splits, which I think are a more realistic answer to the above points.

Another thing to consider when creating your scopes on the DHCP servers is configuring the full scope into each server and excluding the range given out by the other DHCP server. This has the benefit of “self-documenting” the DHCP info for the full subnet on each DHCP server which will improve clarity for anyone else trying to understand what is going on, and also in the event of one of your DHCP servers being offline for some time, you can temporarily reconfigure the exclusion range on the other server to allow it to pick up the slack.

Combining these ideas

Lastly, its worth remembering that you can combine the principles discussed above - you can place all your DHCP servers into one or more "central server" VLANs and use BOOTP relay agents on all your routers to send all DHCP requests from a very large and segmented network to a centralised DHCP service (which is what I do, see below). Or you can have DHCP servers distributed throughout your network, with a "main" DHCP server in its local subnet and a "reserve" DHCP server on a "nearby" network segment providing a small amount of addresses as a backup - you could even have two DHCP servers in their own network segments configured to provide an 80/20 range of addresses for each other. The most sensible choice will depend on how your physical and logical networks map to each other.

DHCP servers serving split scopes to multiple subnets

  • 2
    In case of splitting scopes: Please bear in mind that DHCP reservations should be set up on both halves. Keeping them synced can be quite a hassle if you need to make frequent updates. – Tonny Jul 26 '12 at 10:36
  • 2
    Can you elaborate on techniques to ensure that the reserve DHCP server is not hit as long as the main DHCP server is running? From what I can read, if there is an equal probability of getting a response from either server, the reserve server would statistically run out of adresses, as soon as the total number of leases exceeds twice the size of the reserve pool. This presumably renders the reserve server worthless for new clients, when the main DHCP server is down... right? – Niels B. Feb 2 '14 at 3:25
  • 3
    @NielsB. if you're doing something like an 80/20 split then you can set a delay in the response of the reserve server (… ). I don't bother with this as I use a 50/50 split myself, but it will work. – Rob Moir Feb 2 '14 at 9:07

I adopted this approach some years ago for a small-to-medium size (500 user) network with considerable benefits. DHCP ceased to be a single point of failure. By permanently associating MAC and IP addresses, we ensured that both DHCP servers gave the same response to each DHCP request. Knowing the IP address of every network asset also simplified network administration, and DNS could run off the same database. The system used Internet Software Corporation BIND and DNS, and the associated scripts can be downloaded at As the script is currently offline, an Alternative would be to use true ISC DHCPD failover:

  • 2
    The OP specifically asked for an explanative answer for this question. You may want to revise your answer to expand upon it. – Brent Pabst Jun 5 '12 at 12:07
  • 3
    fwiw, while this answer is short and I'll never turn down more detail in a canonical question and answer set, I thought it was quite good as it mentions a slightly different method of doing DHCP redundancy. – Rob Moir Jun 5 '12 at 15:34
  • 1
    @DJ Pon3 I agree: I run a similar setup as your big multi-site DHCP (less VLANs though) and I use the same approach as Peter Talbot for 3/4 of those VLANs. – Tonny Jul 26 '12 at 10:39
  • 1
    The link is broken now :( – Sergey Vlasov May 1 '13 at 15:25

protected by Chris S Jul 31 '12 at 17:58

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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