Best Practices
Before you install Microsoft DHCP servers on your network, consider these best practices:
Use the 80/20 design rule Using more than one DHCP server on the same subnet provides increased fault tolerance for servicing DHCP clients located on the subnet. With two DHCP servers, if one server goes down, the other server can be made to take its place and continue to lease new addresses or renew existing clients. This also helps balance server usage.
Use superscopes for multiple DHCP server environments On each subnet in a LAN environment, with different scopes on each server, it is recommended that you use superscopes. Using superscopes as a way to share information about all scopes in the subnets on each of the DHCP servers resolves problems, such as a negative acknowledgment being sent to a client erroneously.
When started, each DHCP client sends a limited broadcast of the DHCPDiscover message to its local subnet to try to find a DHCP server. Because DHCP clients use broadcasts during their initial startup, you cannot predict which server will respond to a client's DHCP discover request if more than one DHCP server is active on the same subnet.
For example, if two DHCP servers—Server1 and Server2—are configured with different scope ranges of available addresses, a DHCP client can be leased by either server depending on which server responds first to the client's initial broadcast request to find a server at startup. Later, the DHCP server originally used by the client to obtain its lease may be temporarily unavailable during the client renewal state (by default, the client attempts renewal after 50 percent of its lease has elapsed).
If renewal fails, the client delays any attempt to renew its lease until it enters the Rebinding state (by default, the client enters the Rebinding state after 87.5 percent of its lease has elapsed). In the Rebinding state, the client broadcasts to the subnet to obtain a valid IP configuration for its continued use on the network. At this point, if a different DHCP server (that is, a DHCP server other than the one that first leased the client) responds to the client broadcast first, it sends a DHCPNak (a negative acknowledgment) message in reply. This happens because the client's current address is not known to the other server and recognized as a valid IP address for the subnet. This DHCPNak situation for the client can occur even if the original DHCP server that leased the client is available on the network.
To avoid these problems when using more than one DHCP server on the same subnet, use a new superscope configured similarly at all DHCP servers. The superscope should include all valid scopes for the subnet as member scopes. For configuring member scopes at each server, addresses must only be made available at a single DHCP server on the subnet. For all other DHCP servers on the subnet, use exclusion ranges when configuring the corresponding scope.
When a superscope is created, all DHCP servers are configured with member scopes that exclude addresses they do not service. When a server receives a renewal request, it checks to see if the client's IP address belongs to one of the scopes it is aware of:
If it belongs to one of these scopes, and the address falls in a range that has been excluded on that server, the server ignores the renewal request.
If the server cannot find any scopes that include this IP address, the server sends a DHCPNack in response to the request, indicating this address should not be used on that subnet.
If the server is unavailable, the client times out and waits until the rebinding time (T2) interval occurs, usually when 87.5 percent of the lease time has expired. If the server is still unavailable at that time, the client keeps using its current IP address until the lease expires. The client then begins broadcasting a DHCPDiscover message to obtain a new lease. If the client's original DHCP server (the server from which it obtained its lease) is still unavailable, another DHCP server on the subnet handles the client request, and allocates an IP address and lease to the client.
Deactivate scopes only when removing a scope permanently from service. Once you activate a scope and place it into service, it should not be deactivated until you are ready to retire the scope and its included range of addresses from use on your network. This is because once a scope is deactivated, the DHCP server no longer accepts those scope addresses as valid addresses. This can be useful when your intention is to permanently retire a scope from use. Otherwise, deactivating a scope can cause undesired DHCPNak messages to be sent to clients leased in the scope.
If your intent is only to effect temporary deactivation of scope addresses, edit or modify exclusion ranges in an active scope so you don't cause undesired DHCPNak problems that appear after a scope is deactivated.
Use conflict detection on DHCP servers only under unusual circumstances. For Windows 2000, DHCP client computers that obtain an IP address use a gratuitous ARP request to perform client-based conflict detection before completing configuration and use of an offered IP address. If a client running Windows 2000 is configured to use DHCP and detects a conflict, it sends a DHCPDecline message to the DHCP server. Windows 95-based Microsoft TCP/IP clients typically do not perform conflict detection in this way.
If your network includes Windows 95-based DHCP clients, you should only use server-side conflict detection provided by the DHCP service. To enable conflict detection, increase the number of ping attempts that the DHCP service performs for each address before leasing that address to a client.
Note that for each additional conflict detection attempt the DHCP service performs, additional seconds are added to the time needed to negotiate leases for DHCP clients.
Reservations should be created on all DHCP servers that can potentially service the reserved client. You can use a client reservation to assure that a DHCP client computer always receives lease of the same IP address at its startup. If you have more than one DHCP server reachable by a reserved client, add the reservation on each of your other DHCP servers. This allows other servers to honor the address reservation made for the client.
In this situation, all reachable DHCP servers for the reserved client should be configured as described earlier, using a superscope with similar scope ranges of addresses. Although the client reservation will be acted upon only by the DHCP server where the reserved address is available, you can create the same reservation on other DHCP servers that exclude this address.
For server performance, consider that DHCP is disk-intensive and purchase hardware with optimal disk performance characteristics. DHCP causes frequent and intensive activity on server hard disks. To provide for the best performance, consider RAID solutions when purchasing hardware for your server computer to improve disk access time.
When evaluating performance of your DHCP servers, you should view DHCP as part of making a full performance evaluation of the server as a whole. By monitoring system hardware performance in the most demanding areas of utilization (that is, CPU, memory, disk input/output) you will obtain the best assessment of when a DHCP server is overloaded or in need of upgrades.
Note that for Windows 2000 Server, the DHCP service includes several new System Monitor counters that can be used to monitor service. For more information, see "Overview of Performance Monitoring" in the Microsoft Windows 2000 Server Resource Kit Server Operations Guide.
Keep audit logging enabled for use in troubleshooting. By default, the DHCP service enables audit logging of service-related events. With Windows 2000 Server, audit logging provides for a long-term service monitoring tool that makes limited and safe use of server disk resources.
Reduce lease times for DHCP clients that use Routing and Remote Access for dial-up networking. If the Routing and Remote Access service is used on your network to support dial-up clients, you can adjust the lease time on scopes that service these clients to use a lease time reduced from the default for a scope of eight days. For Windows 2000, one recommended way to support remote access clients in your scopes is to add and configure the built-in Microsoft user class provided for identifying remote access clients.
Increase the lease duration of scope leases for large, stable, fixed networks if available address space is plentiful. For small networks (for example, one physical LAN not using routers), the default lease duration of eight days is a typical period. For larger routed networks, consider increasing the length of scope leases to a longer period of time, such as 7 to 21 days. This can reduce DHCP-related network broadcast traffic, particularly if client computers generally remain in fixed locations and scope addresses are plentiful (at least 20 percent or more of the addresses are still available).
Integrate DHCP with other services, such as WINS and DNS. Either WINS or DNS (or possibly both) are used for registering dynamic name-to-address mappings on your network. To provide name resolution services, you must plan for interoperability of DHCP with these services. Most network administrators implementing DHCP also plan a strategy for implementing DNS and WINS servers.
Use either routers which are capable of relaying BOOTP and DHCP message traffic, or use relay agents and set appropriate timers to prevent undesired forwarding and relay of BOOTP and DHCP message traffic. If you have multiple physical networks connected through routers, the routers must be capable of relaying BOOTP and DHCP traffic. In routed networks that use subnets to divide network segments, planning options for DHCP services must observe some specific requirements for a full implementation of DHCP services to function. These requirements include the following:
One DHCP server must be located on at least one subnet in the routed network.
For a DHCP server to support clients on other remote subnets separated by routers, a router or remote computer must be used as a DHCP and BOOTP relay agent to support forwarding of DHCP traffic between subnets.
If you do not have such routers, you can set up the DHCP Relay Agent component on at least one computer running Windows 2000 Server (or Windows NT Server) in each routed subnet. The relay agent relays DHCP- and BOOTP-type message traffic between the DHCP-enabled clients on a local physical network and a remote DHCP server located on another physical network. When using relay agents, be sure to set and increase the initial time that relay agents wait before relaying DHCP messages to servers. For more information, see the section titled "Relay Agent Deployment" later in this chapter.
For DNS with dynamic updates performed by the DHCP server, use the default client preference settings. For Windows 2000 Server, the DHCP service performs dynamic updates for DHCP clients based on how clients request updates be done. This setting provides the best use of the DHCP service to perform dynamic updates on behalf of its clients as follows:
Client computers running Windows 2000 explicitly request that the DHCP service only update pointer (PTR) resource records used in DNS for the reverse lookup and resolution of the client's IP address to its name. These clients update their address (A) resource records for themselves.
Clients running earlier Windows versions cannot make an explicit request for dynamic update preference. For these clients, the DHCP service can be configured to update both the PTR and the A resource records for the client.
Follow the recommended process for moving a DHCP service database from old server computer hardware to new hardware. For information on moving DHCP service data to another server computer, such as in the case of hardware failure or disaster recovery, see the Microsoft Knowledge Base.