In this article, we’ll take a look
at the new DHCP features that are available in Server 2012 R2.
Introduction
Although
DHCP has been around since I can remember, there has always been limited
communication between DHCP servers, in fact, mostly none. If you were going to
have two DHCP servers serving the same subnet, you would have had to configure
the same scope on both and each server would need to exclude the range of the
other server so that they wouldn’t give out the same IPs and cause IP
conflicts. This is the classic 80/20 scopes that you would have read about from
pretty much when DHCP was released. It does require some planning because you
would need to ensure that should a single server fail, you are able to get the
other server up and running before you run out of available leases. DHCP
failover sorts this out.
The other
option you would use would be DHCP running on a windows failover cluster. This
provides high availability for the DHCP role but isn’t commonly used.
Anyways,
when Server 2012 was released, Microsoft introduced DHCP failover.
Overview
DHCP failover allows two Server 2012 or later
DHCP servers to replicate lease information between them. This means that both
servers are able to lease IPs to the entire scope without causing IP conflicts.
In reality, each server manages its own clients but in the event of a DHCP
server failure the other server can take over management of its clients but
more on this later.
Each DHCP server has a failover relationship
with another DHCP server. You can have one DHCP server have a failover
relationships with many servers but each relationship can only include two
servers.
Each DHCP scope is then associated with a
failover relationship and this means that each of those DHCP servers in the failover
relationship provide IPs for this scope.
Limitations and
requirements
As with all things, there are limitations but I
don’t expect these to be very restrictive. See below:
Each DHCP server can only have a maximum of 31
failover relationships as in, if you wanted, you could have a single DHCP
server with a relationship with 31 other DHCP servers. I suppose if you hit
this limit, you just need to deploy the DHCP role a few more times and with
remote PowerShell now enabled by default, this makes life much easier but more
on that another time.
Each DHCP failover relationship can only
include 2 DHCP servers. This means that you can only have N+1 for your failover
scopes if using DHCP failover alone. There are ways around this – a clustered
DHCP server is counted as a single DHCP server so if you really wanted, you
could have a failover relationship between these two clusters.
IPv6 is not supported for DHCP failover.
Requires TCP port 647 open in the firewall for
both servers in the DHCP failover relationship. The firewall rules are: Microsoft-Windows-DHCP-Failover-TCP-In,
Microsoft-Windows-DHCP-Failover-TCP-Out.
If using DHCP servers in different sites or
subnets, ensure that the clients can reach both servers. You will need two IP
helpers configured on your switches or two DHCP relays configured if using
Windows server.
AD is not required. The DHCP servers
authenticate each other using shared secrets.
How does it work?
There are two modes – load balance mode and hot
standby. Load balance is the default however it’s sometimes a good idea to
choose hot standby such as when you have the active server in a small branch
office and have a standby server in a more central location.
Load Balance
Mode:
·
Maximum Client Lead
Time: When
a new client requests a lease, one of the DHCP servers provides a lease with a
length equal to what is configured for the Maximum Client Lead Time (MCTL).
This is 1hr by default. As you know, the client renews its lease at 50% of the
lease so this will be 30mins later by default. At this time, it will get a
lease equal to what is configured on the scope
·
Load balancing: The two DHCP servers
compute hashes of the client MAC addresses and distribute the clients between
them so that the DHCP servers only respond to the MAC addresses of their
clients or what is known as that DHCP server’s MAC address hash bucket. The
default is for each DHCP server to manage 50% of the load.
·
Failure of the partner
server (state switching): the remaining server will go into a state called
COMMUNICATIONS INTERRUPTED which is a state before it has confirmed that its
partner is down. Here the administrator needs to confirm the partner is down
and put the remaining server into PARTNER DOWN state (manual failover). If you
want the server to enter this state automatically then you need to configure
the state switchover interval which is a default of 1hr. Once in PARTNER DOWN
state, the server will respond to all MAC addresses.
·
Failure of the partner
server (temporary fix): These steps take place if MCTL has not yet expired. If it is a client with a MAC address
from its partner’s MAC hash bucket renews or requests a lease, it’ll provide a temporary
lease for the time specified by the MCTL setting which is 1hr by default. If it
gets a request from a new client then it’ll provide a full lease from its pool.
This temporary fix is only for the duration of the MCTL.
·
Failure of the partner
server (longer term fix): When the MCTL expires and the partner server is still not
up then it’s likely that it won’t come up any time soon. In this case, the
remaining server takes over management of the entire IP range
Hot
Standby Mode:
·
Standby server: This server is for
standby only in that it won’t respond to any client requests but it does
however hold 5% of the leases.
·
Maximum Client Lead
Time:
As with the load balance mode, the active server will provide an initial lease
time equal to the MCTL.
·
Failure of the partner server
(state switching):
This is the same as for the load balance mode – the server will enter a
COMMUNICATIONS INTERRUPTED state before either being manually put into PARTNER
DOWN state or waiting for the state switchover interval before automatically
entering the PARTNER DOWN state.
·
Failure of the partner
server (temporary fix): This is when the MCTL hasn’t yet expired. The standby
server can respond to new leases and provides leases of the length of the MCTL but
can only provide leases from the 5% of scope IPs that it had reserved. Once
depleted, it no longer provides leases.
·
Failure of the partner server
(longer term fix):
After the MCTL expires, the standby server can then take ownership of the entire
scope and provides new leases or renews leases for any IP in the scope.
Conclusion
In this first article, we discussed the need
for DHCP failover, the modes available, namely load balance and hot standby and
how failover works.
In part 2, we will look at how
to configure failover relationships and scopes.