DHCP administrators who
recognize the need to provide redundancy for DHCP have been challenged
for many years and have had to implement manual configurations to
provide any level of redundancy. Many of these implementations lacked
certain functionality and required network resources that were not
always readily available, such as a suitable second server to deploy
DHCP services on. DHCP services redundancy can be achieved by either
deploying multiple DHCP servers running overlapping or split scopes or
by deploying clustered DHCP services. Many organizations do not have the
administrative support or
budget to deploy clustered DHCP services, so the more common approach
to providing DHCP redundancy is to deploy multiple DHCP servers running
split scopes.
DHCP Split Scope
A DHCP scope is
primarily defined by an address pool that contains the IP addresses that
will be made available to DHCP clients. Within a scope, there is
usually an included and excluded IP address list as well as DHCP scope
options, such as default gateway and DNS server options, which will be
delivered to clients receiving a DHCP IP address lease. A scope also
contains IP address reservations and other general scope properties that
enable administrators to define how the DHCP server will deal with
Dynamic DNS registration for DHCP leases, audit log path settings, Name
Protection settings, and much more. When redundancy is required for DHCP
services, and deploying DHCP services on a cluster is not a viable
option, DHCP administrators will deploy multiple DHCP servers set up in a
split-scope configuration.
A DHCP split scope is a range of
IP addresses available for DHCP IP address leases that are logically
split between two or more DHCP servers. The IP address pool is the same
on both servers, and the defining configuration for a split scope is the
excluded IP range. For example, suppose a DHCP administrator was given
an address pool of 192.168.1.1 to 192.168.1.254. On a split-scope
configuration, both DHCP servers would have this range defined in the
scope, but on the first DHCP server, there would be an excluded address
range of 192.168.1.1 to 192.168.1.100; this means that the first DHCP
server would lease addresses 192.168.1.101 to 192.168.1.254. The second
DHCP server would also have 192.168.1.1 to 192.168.1.254 defined in the
included address pool, but the excluded address range would be
192.168.1.101 to 192.168.1.254. With this configuration, the second DHCP
server would lease addresses from 192.168.1.1 to 192.168.1.100. With a
split-scope configuration, if a single DHCP server becomes unavailable,
the secondary DHCP server can still provide DHCP leases on the network
to which the split scope applies.
Historically, a
split-scope configuration needed to be manually created by DHCP
administrators, but starting with Windows Server 2008 R2, Microsoft now
includes a DHCP Split-Scope Configuration Wizard. This wizard allows a
DHCP administrator to take an existing scope on the primary DHCP server
and run the wizard to duplicate the scope on a designated secondary DHCP
server and define how the addresses will be split among the two
servers. This wizard will make the necessary changes to both of the DHCP
servers, leaving less room for user error. But before the DHCP
Split-Scope Configuration Wizard can be run, a DHCP administrator must
consider how the scope will be split, and the following section
describes three common split-scope configurations that should be
considered. The process of splitting an existing DHCP scope is detailed
later in this chapter.
Examining the 50/50 Split-Scope Configuration
The 50/50 split-scope
configuration includes two DHCP servers, in which each DHCP server is
configured with the same address range for the address pool, but each
must have a different excluded IP address and the total number of
addresses is split in half or 50/50. Figure 1
illustrates the 50/50 split-scope configuration. As indicated in the
diagram, the network has 200 clients defined by 192.168.1.0/24. Each
DHCP server contains a scope to cover the entire specific client subnet.
Server1’s scope is configured with exclusions for all IP addresses
except for the range of 192.168.1.1–192.168.1.125. Server2’s scope is
configured with exclusions for the first half and a client lease range
of 192.168.1.126–192.168.1.254.
Upon requesting a client IP
address, the first server to respond to a request will be accepted, thus
roughly balancing the load between the two servers, except for one
thing: There is no way to determine which DHCP server will respond first
and serve the client requests, so there is a chance that one DHCP
server will run out of IP addresses before all IP addresses are used.
Also, another issue with this configuration is that both DHCP servers
would respond to lease requests and a DHCP administrator would need to
review both servers to troubleshoot and determine what the true number
of available IP addresses are, when clients are having issues getting an
IP address lease.
Exploring the 80/20 Failover Approach to DHCP Fault Tolerance
The 80/20 failover approach
is similar to the 50/50 approach, except that the effective scope range
on the server designated as the backup DHCP server contains only 20% of
the available client IP range. The server with 80% of the range would
be considered the primary DHCP server, and the 20% server would be
considered the secondary. In the event of primary server failure, the
secondary server would have enough IP addresses to provide leases until
the primary server could be fixed and returned to operation. This is the
best-practice split-scope configuration, but until Windows Server 2008
R2, this configuration frequently resulted in the secondary server
running out of IP addresses during regular operation because it can
respond to client requests as fast as the primary server—and the first
server to respond wins!
Understanding the 100/100 Failover Approach to DHCP Fault Tolerance
The 100/100 split-scope
configuration in Windows Server 2008 R2 DHCP can be the most effective
means of achieving high availability out of a DHCP environment. The
100/100 split-scope configuration, in its simplest form, is the same as
the 50/50 except that the total scope range contains at least twice the
number of total DHCP clients.
In Figure 2,
the 10.2.0.0/16 subnet has a total of 750 clients. This subnet is
serviced by two DHCP servers, each of which has a scope for the subnet.
Each server has a scope with addresses from 10.2.1.1 through 10.2.8.254.
The scope on Server1 excludes all IP addresses except those in the
range of 10.2.1.1 through 10.2.4.254. The scope on Server2 excludes all
IP addresses except those in the range from 10.2.5.1 through 10.2.8.254.
Each effective range is subsequently large enough to handle 1,000
clients, which is more than enough for every machine on the network.
If one of the DHCP servers
experiences an interruption in service, and it no longer responds, the
second server will take over, responding to clients and enabling them to
change their IP addresses to the IP addresses available in the separate
range. With this configuration, extended downtime of a single DHCP
server can be tolerated without much loss of functionality.
The main caveat to this
approach is that a large number of IP addresses must be available for
clients, more than twice the number than would normally be available.
This might prove to be difficult, if not impossible, in many networks
that have a limited IP range to work with, and is especially true when
deploying new DHCP services on existing or established networks.
However, in organizations with a larger IP range, such as those offered
by private Class A network configurations (10.x.x.x and so on), this
type of configuration might be ideal.
As you can see in Figure 11.9,
both servers are configured with the same IP address range but even
with the exclusion range, each server individually contains enough IP
addresses to serve the entire DHCP client base.
Windows Server 2008 R2 Delay Configuration Setting
Starting with Windows
Server 2008 R2, the DHCP Server service now includes an IPv4 scope
setting named Delay Configuration. The Delay Configuration setting is
configured on the Advanced Scope Properties page and allows a DHCP
administrator to delay the response from a DHCP server, to ensure that
the desired primary DHCP server answers all DHCP lease requests, unless
it is out of service. With this new setting alone, DHCP administrators
can simplify the management of a split-scope DHCP configuration; as
during normal operation, all leases should be only on the primary
server. The Delay Configuration setting should be set up on secondary
DHCP server scope properties. With this setting, the 80/20 best-practice
split scope can be used confidently. To enable the Delay Configuration
setting on a secondary DHCP server scope, simply open the scope
properties from the DHCP server console, select the Advanced tab, and
near the bottom of the window, type in the number of milliseconds the
DHCP server should wait before responding to a client lease request, as
shown in Figure 3.
DHCP Split-Scope Configuration Wizard
When deploying multiple DHCP
servers in a split-scope configuration is desired, it is recommended to
use the new DHCP Split-Scope Configuration Wizard. The DHCP Split-Scope
Configuration Wizard will create the new scope on the secondary DHCP
server and will even copy client scope reservations that are already
defined. Link Layer Filter Allow and Deny lists, however, will not be
copied over. As a best practice, before running the DHCP Split-Scope
Configuration Wizard, create all the necessary reservations on the
primary DHCP server scope and manually copy over any Link Layer Filter
lists. Ensure that if Link Layer Filtering for either Allow or Deny or
both is enabled on the primary server, that the Link Layer Filtering
configuration on the secondary DHCP server matches this configuration.
To deploy a split-scope configuration—for this example, in an 80/20
split—follow these steps:
1. | Install the DHCP service on two servers. For this example, we will use Server10 as the primary and Server60 as the secondary.
|
2. | On the primary server, create a new DHCP scope that contains the entire scope range and DHCP options for that scope.
|
3. | On the secondary server, do not create any scopes.
|
4. | Open
the DHCP server console on the primary server, and expand the server
node in the tree pane to reveal the IPv4 and IPv6 nodes.
|
5. | Add the secondary server to the console by right-clicking on the DHCP node at the top of the tree pane and selecting Add Server.
|
6. | In
the Add Server window, type in the secondary server name or choose it
from the managed authorized server list and click OK to complete this
task.
|
7. | After
both servers are listed in the console, select and expand the primary
server IPv4 node to display the desired IPv4 scope that will be split
for this example.
|
8. | Select
and right-click the desired IPv4 scope on the primary DHCP server,
select Advanced, and then click on Split-Scope, as shown in Figure 4.
|
9. | In the DHCP Split-Scope Configuration Wizard, click Next on the Introduction to DHCP Split-Scope page to continue.
|
10. | On
the Additional DHCP Server page, type in the name of the secondary DHCP
server (for this example, Server60), and click Next to continue.
|
11. | On
the Percentage of Split page, the wizard will default to the 80/20
split, which will configure the primary server with 80% of the addresses
for lease and exclude the remaining 20%. The secondary server will be
configured with 20% of the addresses available for lease and the other
80% will be excluded. Accept the defaults or move the slider to the
desired percentage split, and click Next to continue, as shown in Figure 5.
|
12. | On
the Delay in DHCP Offer page, define the delay in milliseconds on the
secondary server to ensure that the bulk of clients will be serviced by
the primary server, and click Next to continue.
Note
Determining how long to
delay the secondary DHCP server must be concluded by performing tests on
the actual network that will serve the DHCP clients. It is key that the
primary server is given ample time to respond and the delay on the
secondary is short enough that when the primary server is down, DHCP
clients will be acknowledged and serviced by the secondary DHCP server.
For our test network, 100 milliseconds was suitable, but on some larger
networks, this number might need to be increased.
|
13. | On
the Summary of Split-Scope Configuration page, review the chosen
settings and click Finish to configure both of the DHCP servers.
|
14. | Once
the process completes, the status of the configuration changes on both
servers is displayed in the window. Review the results and click Close
to close the wizard.
|
15. | Once the wizard is closed, in the tree pane, select and expand the secondary server to expose the IPv4 node.
|
16. | Expand
the IPv4 node to reveal the new scope. Review the scope settings, and
if things look good, right-click the scope and click Activate to
finalize the split-scope configuration, as shown in Figure 6.
|
Both the primary and
secondary DHCP servers configured in a split-scope configuration will
honor client scope address reservations, even if the reservation IP
address falls within the excluded IP address range. For this to be 100%
effective, the reservation will need to be defined on both servers, and
the wizard will copy any existing reservations defined on the primary
server. Link Layer Filter lists will not be copied over, and any new
reservations created on the primary server will need to be manually
created on the secondary server scope.
Clustering DHCP Servers
The final redundancy
option, and frankly the easiest to configure and maintain, if resources
allow, is to deploy a clustered DHCP service. In this configuration, if a
single server goes down, the second server in a cluster will take over
DHCP operations. This option requires a greater investment in hardware
and should be considered only in specific cases in which it is
necessary. The biggest benefit for this configuration is that all leases,
Link Layer Filter lists, and reservations will be contained with the
configuration of the single clustered DHCP server.
