DHCP is a vital service on an enterprise network. Without it, clients can’t obtain IP addresses and information such as DNS servers. For this reason, DHCP is frequently deployed in a highly available manner so that if one server becomes unavailable, another can take over. This section examines the considerations involved in designing a high availability solution for DHCP.
-----------------
Note: TERMINOLOGY AND BASIC DHCP DESIGN
This section concentrates on DHCP design at the enterprise level and assumes that you have requisite knowledge of DHCP itself, along with basic deployment and management of DHCP.
------------------
The two goals for highly available DHCP are as follows:
- Provide DHCP service at all times.
- When one DHCP server is no longer available, enable clients to extend their lease by
contacting a different DHCP server.
When designing a highly available DHCP solution, you should consider whether to provide split-scope DHCP or failover clustering.
Split scope
With split-scope DHCP, two servers provide address and network information using a portion of the address space or DHCP scope. For example, if an organization assigns addresses from the 192.168.100.0/24 subnet, a split-scope DHCP scenario might call for 80 percent of the addresses to be assigned by one server and the other 20 percent by another server. This is known as the “80/20” rule for DHCP scope assignment, and organizations sometimes place the server with 80 percent of the scope nearest to the clients. However, you don’t need to
figure out the 80/20 split; the Dhcp Split-Scope Configuration Wizard includes a step to help configure the split (see Figure 2-1).
FIGURE 2-1 Configuring a split-scope percentage in the Dhcp Split-Scope Configuration Wizard.
Split scope enables traffic to be split among participating servers while also providing redundancy for clients should one of the two servers fail. However, clients accept the first DHCP response they receive, so you can’t guarantee from which server clients will receive a DHCP response. If the servers are split across a network boundary, you need to configure a DHCP relay agent on a router and introduce a delay at that point so as to prevent the secondary server from responding before the primary server. The Dhcp Split-Scope Configuration
Wizard also includes an opportunity to add a delay to one of the servers involved in the split scope, as shown in Figure 2-2.
FIGURE 2-2 Adding a delay in a split scope can help ensure that network information comes from the correct server.
Alternatively, a delay can be configured into the scope itself through the Advanced tab in the Scope Properties sheet, as shown in Figure 2-3.
FIGURE 2-3 Configuring a delay for the DHCP server response can help in a split-scope scenario.
----------------
NOTE: SPLIT SCOPE
Split scope is available only for IPv4 scopes.
-----------------
DHCP failover
A new feature of Windows Server 2012, DHCP failover means that two servers are configured with the same DHCP configuration. Windows Server 2012 has two modes for failover: hot standby and load sharing. These modes of DHCP failover are different from failover clustering, which is discussed later.
------------------
NOTE: TWO NODES
DHCP failover is limited to two nodes.
-------------------
With DHCP failover, each server has a replicated version of the entire scope, including lease information. This means that either server can offer addresses for the entire scope. The practical implication of scope and lease replication is to enable both modes of operation.
With a hot standby operation, one server provides DHCP information while the other server maintains a replicated version of the DHCP lease information, ready to take over if the primary server fails. In a load-sharing mode, each server assigns DHCP information and updates the shared lease information database.
Hot standby mode is useful for organizations that have a remote location with DHCP clients, sometimes called a hub-and-spoke topology. The remote location acts as the primary server; a server at the central data center acts as a backup. If the remote server goes offline, the secondary server at the data center can take over. The primary and secondary assignment is done at the subnet level, rather than the scope level. This means that a server can be primary for one subnet and secondary for another subnet.
Load-sharing mode is helpful for data center or centralized DHCP scenarios in which two servers operate within a single site. In load-sharing mode, each server assigns DHCP information to clients based on a load ratio. You set the load balance percentage at configuration time, as shown in Figure 2-4.
FIGURE 2-4 Configuring the load balance percentage in a DHCP failover architecture.
You can edit the load balance percentage after initial configuration from the partner server.
--------------------------
NOTE: LIMITATIONS
DHCP failover is limited to IPv4 scopes and configuration.
---------------------------
DHCP failover clustering
A redundant architecture available prior to Windows Server 2012 is failover clustering. With failover clustering, the primary DHCP server offers DHCP information, and the secondary server takes over if the first server fails. In this scenario, the DHCP servers share the same storage, thus making a single point of failure at the storage level.
DHCP Interoperability
The term interoperability refers to the relationship between DHCP and other Microsoft technologies such as Routing and Remote Access, Network Access Protection (NAP), Active Directory Domain Services (AD DS), and other related technologies, rather than interoperability between the Microsoft DHCP implementation and the DHCP implementation from other vendors.
DHCP clients can register dynamic DNS entries upon address assignment. To do so, the DHCP server depends on a directory services domain controller to be available, and the DHCP server must be authorized to make such entries into the DNS. This can be configured on the DNS tab of the Scope Properties sheet (see Figure 2-5).
FIGURE 2-5 Configuring dynamic DNS settings related to a DHCP scope.
The DHCP server can update both the pointer (PTR) and host address (A) record for the client. The Client FQDN option (DHCP option 81) is used for this purpose. Option 81 includes the Fully Qualified Domain Name (FQDN) and other information from the client. As Figure 2-5 shows, the server can be configured to update the DNS at all times or only if requested by the client. Older clients are also supported (ones that can’t or don’t send DHCP option 81) by selecting the Dynamically Update DNS A And PTR Records For DHCP Clients That Do Not Request Updates check box within this Properties sheet.
DHCP interoperability with AD DS is typically used to detect and authorize additional DHCP servers on the network. DHCP servers running Windows can be authorized into the AD DS schema and if not authorized, can be prevented from leasing IP addresses to clients.
However, this authorization scheme works only for DHCP servers running Windows 2000 and above and doesn’t work for a DHCP server running on Linux or a network device.
DHCP can work with NAP to limit client access unless the client is in a compliant state.
Figure 2-6 shows the NAP-related configuration in a scope’s Properties sheet.
FIGURE 2-6 Network Access Protection settings related to DHCP.
You can configure NAP at the individual scope level or for all scopes on a server.
DHCPv6 considerations
DHCP for IPv6 operates in stateless and stateful modes. In stateful mode, clients obtain both an address and information such as DNS servers from the DHCP server. In stateless mode, clients obtain ancillary information such as DNS servers but receive their addressing through IPv6 auto-configuration or as a static IP address.
