The DHCP Database
Guarding and maintaining the DHCP database is important for system administrators not only to provide consistent performance, but also to minimize unscheduled downtime due to unexpected server or network snags.
The DHCP database is a dynamic database that stores the DHCP configuration information and the lease data for clients that have leased an IP address from the DHCP server; this includes DHCP options, scope configuration, address leases, exclusion, and reservations. By default, the following DHCP database files are stored in the %systemroot%\System32\Dhcp folder.
* Dhcp.mdb – This is the DHCP server database file.
* Dhcp.tmp – A temporary file that the DHCP database uses as a swap file during database index maintenance operations.
* J50.log and J50#####.log – These are logs of all database transactions. These logs may be used by the DHCP server for data recovery.
* J50.chk – A checkpoint file that is updated every time data is written to the DHCP.mdb database file. This checkpoint file can be used during recovery to indicate where the recovery or replaying of data should begin.
Backup and Restore
By default, the DHCP database and associated registry entries are backed up automatically at 60-minute intervals. There is no GUI to change the backup interval; however if you want to change the default settings, you can do so in the following registry key:
You can also back up a DHCP database manually at any time. There is no need to stop the DHCP service to perform a backup of the database. The default path for the DHCP backup is systemroot\System32\Dhcp\Backup. It is possible to modify this path in the server properties to point to another hard drive. Backing up the DHCP database over the network is not possible.
You can use the “restore” function in the DHCP server console to restore the database. When performing a restore, after you select the location, the DHCP service stops and the database is restored. You must be a member of the administrators group or the DHCP administrators group to perform a DHCP database restore.
Reconciling scopes helps to resolve inconsistencies on the DHCP database. The DHCP Server service stores detailed IP address lease information in the DHCP database and summary IP address lease information in the Windows Server registry. When you reconcile the DHCP scopes, the detail and summary entries are compared to verify inconsistencies. During this process, the DHCP service may restore those inconsistent IP addresses to the original clients, or it may set aside those IP addresses in the form of temporary reservations with duration equal to the lease time assigned to the scope.
Using DHCP Relay Agents to provide DHCP service across multiple subnets.
DHCPv4 uses IP broadcasts and DHCPv6 uses multicasts; in both cases, DHCP servers are limited to communication within their IP subnet. If your organization has a large number of subnets, you have to either deploy a DHCP server on each subnet or provide DHCP service across multiple subnets by configuring DHCP relay.
Using DHCP relay means that you configure a DHCP relay agent on each subnet where a DHCP server is not present. A DHCP relay agent is a computer or router that listens for DHCPv4 broadcasts from DHCPv4 or DHCPv6 multicast from DHCPv6 clients and then relays them to DHCP servers in different subnets. DHCPv4 and DHCPv6 need separate DHCP relay configurations. In either case however, you cannot deploy the DHCP relay agent component on a Windows Server that is running the DHCP service; the network address translation (NAT) routing protocol component with automatic addressing enabled, or Internet connection sharing (ICS).
DHCP Service Availability
Even though you may be able to service thousands of clients from a single DHCP server, it is a best practice to implement at least two DHCP servers to improve reliability and fault tolerance with the additional benefit in some cases of configuring load balancing to distribute the workload across multiple DHCP servers.
One possible approach is to configure the DHCP service using the Windows Server 2012 cluster feature or a third-party clustering solution. If one DHCP server fails, the DHCP service can fail over to another DHCP server in the cluster. In this implementation, the DHCP servers have access to a storage area network (SAN) where the DHCP database and related files are stored.
To improve availability and load balancing, there are two other Windows Server 2012 DHCP native solutions that are less complicated than deploying Windows Server clusters; they are split scopes and DHCP Failover.
DHCP Split Scopes
Split scope allows you to improve the load balancing and fault tolerance of the DHCP service by configuring two DHCP servers that serve the same subnet without IP address overlapping. This feature is only available for IPv4 and cannot be configured on IPv6 scopes.
Using a wizard-based configuration, you use two stand-alone DHCP servers to make a certain percentage of a scope’s IP addresses available on one DHCP server while the remaining IP addresses are assigned to the second DHCP server. For this to work, each DHCP server is configured with the same scope range but with different exclusions within that range. The exclusions are necessary because the DHCP servers do not share their lease database information. Each server must be configured to assign only a subset of the available IP address from a given scope.
Let’s say that you have a scope of 192.168.1.0 /24 and you want to configure a split scope using two DHCP servers: DHCP1 and DHCP2. You want to assign 70% of the IP addresses in the subnet to DHCP1 and the other 30% to DHCP2.
The DHCP scope may be configured as follows:
DHCP1 Scope configuration:
Range: 192.168.1.1 to 192.168.1.254
Exclusion: 192.168.1.178 to 192.168.1.254
DHCP2 Scope configuration:
Range: 192.168.1.1 to 192.168.1.254
Exclusion: 192.168.1.1 to 192.168.1.177
As part of the split-scope implementation, you need to specify the second DHCP server involved in the process. Running the Split-scope Configuration wizard on DHCP1 allows you to allocate the IP address pool in the right proportion; the wizard automatically creates the scope and the corresponding exclusions on DHCP2. You still need to activate the scope on DHCP2 before its IP addresses become available to DHCP clients in the network. The figure below show the DHCP split-scope configuration wizard being run from DHCP1.
It is possible to configure a time delay on the DHCP2 server (see figure below). The delay in DHCP Offer allows DHCP2 to wait before responding to DHCP DISCOVER requests from DHCP clients, permitting the DHCP1 server to respond to and accept the DHCPOFFER first. In the event that DHCP1 becomes unavailable, DHCP2 can continue distributing addresses until DHCP1 is available to service clients again.
In our example, DHCP1 manages 70% of the IP addresses in the 192.168.1.0 /24 subnet. This may be a problem if DHCP1 fails and stays out of service for a prolonged period of time, because DHCP2 is responsible only for 30% of the IP addresses within the scope and it could run out of assignable IP addresses quickly.
Wouldn’t it be great if DHCP2 could also manage the other 70% of the address space? How about if both DHCP1 and DHCP2 could manage 100% of the IP address range within the scope in coordination with each other? This is now possible by configuring DHCP failover on Windows Server 2012.
DHCP failover allows two Windows Server 2012 DHCP servers to share a common pool of IP addresses in which both servers can have access to 100% of the IP address range in a given scope and either one of them may assign IP addresses to network clients. As the lease information is replicated between the servers, there is no risk of duplicate IP address distribution. Because both DHCP servers are enabled to provide IP addresses and option configuration to the same subnet or scope, the availability and redundancy of the DHCP service is greatly improved.
There are some caveats worth mentioning before you get too excited about DHCP failover and try to implement it in your network. Windows Server 2012 permits only two DHCP servers for failover; this feature applies to IPv4 scopes and subnets and there is no way to configure it on IPv6 scopes. A single DHCP server can have multiple failover relationships with other DHCP servers, but each configuration must be assigned a unique name for the partnerships to work. DHCP failover is time-sensitive so time synchronization is critically important; a time difference between the partners greater than one minute will result in a critical error and the failover process will stop.
DHCP failover can be configured in two different modes: load sharing or hot standby.
In Load Sharing mode (default) both DHCP servers provide IP settings to clients concurrently. By configuring the load distribution ratio you determine your priorities on how the servers respond to IP configuration requests.
In Hot Standby mode you specify a primary DHCP server that actively dispenses IP settings for the scope or subnet and a secondary DHCP server that will only distribute IP settings if the primary server becomes unavailable. You must configure a percentage of the IP address range to be assigned to the standby server. These addresses are delivered during the maximum client lead time (MCLT) interval if the primary server is down. The secondary server takes control of the entire IP range after the MCLT interval expires.
It is important to remind you that whether you are configuring load sharing or hot standby mode, the configured scope is still shared between the two servers. In either case, if one server fails, the other DHCP server will be able to manage the whole pool of IP addresses because the lease information has been replicated all along.
Here are the steps to configure DHCP failover:
- In the DHCP console, right-click the IPv4 node, and then click Configure Failover.
- In the Configure Failover Wizard, click Next. Any scope that you are configuring for failover must not exist on the partner DHCP server.
- On the Specify a partner server to use for failover page, in the Partner Server box, enter the other DHCP server host name or IP Address.
- On the Create a new failover relationship page, in the Relationship Name box, enter a unique name and review and/or configure these settings before clicking Next.
- Maximum Client Lead Time (MCLT): This parameter determines the amount of time a DHCP server should wait when a partner is unavailable, before assuming control of the address range. It also specifies the amount of time for which a DHCP lease may be renewed by either failover peer without previously contacting the other.
- Mode: Load balance or standby. Load balance gives the option to assign the load balance percentage for each server. Hot standby allows you to set the role of the partner as active or standby and to allocate a percentage of addresses to the standby server.
- State switchover interval: This option specifies the time interval before a DHCP server is automatically transitioned to a “partner down” state when network communication is interrupted and the DHCP partner is no longer available. By default you must manually switch the status of a DHCP Server to a “partner down” state using the DHCP Management console or PowerShell.
- Enable Message Authentication: Use to enable or disable authentication of failover replication traffic between servers.
- Shared Secret: Enter a password to authenticate the failover connection between servers.
- Click Finish, and then click Close.
- After the wizard runs on DHCP1, we can verify that the failover scope has been created and activated on the DHCP2 server. (See figure below.)
Here we have used the DHCP management console to configure DHCP failover; it is possible to complete the same configuration using Windows PowerShell.
In this article we focused on the Windows Server 2012 DHCP service performance and accessibility issues. We reviewed the DHCP database maintenance, using DHCP relay agents, and the configuration alternatives to improve availability, load balancing and fault tolerance.