This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning for DHCP
Unless you want to go back to manually assigning and tracking IP addresses for all clients on your network, DHCP is going to be a very important network service for you. As such, it requires some time spent evaluating the needs of the current and future environment you support. When properly planned and implemented up front, DHCP typically continues to function as intended for many years into the future.
Planning a DHCP Infrastructure Type
Before you can get down to the task of planning how many DHCP servers you'll need, where you'll put them, or how you'll configure the scopes and options, you need to first understand what type of network infrastructure you have and how DHCP will fit into it. In general, organizations make use of three basic types of network infrastructures: centralized, distributed, and mixed. Your DHCP design also typically makes use of one of these three models.
Centralized Infrastructures
The most common model used today is the centralized infrastructure model. In this model, your DHCP servers (along with most other network services) are located in a central location. Clients at remote locations or on other subnets (or other broadcast domains) need to use a DHCP relay agent to contact a DHCP server. Almost all modern routers in use today can be configured as a DHCP relay agent, thus passing the DHCP broadcast traffic from the remote subnet to the subnet where the DHCP servers are located.
As an example, an organization I've had experience with has multiple subnets configured for their campus, one for each building where clients are located. These subnets were implemented through VLANs, and all of the VLANs were trunked together to form a single broadcast domain. Because no routers are required to pass traffic from one subnet (VLAN) to another, no DHCP relay agents are required anywhere on the network. In this example, the organization has two DHCP servers configured in their data centers to provide DHCP for the entire network.
Distributed Infrastructures
In the distribution infrastructure model, each subnet (or VLAN) has its own DHCP server located locally. This model does have the advantage of keeping DHCP traffic off WAN links, which are almost always slower and less reliable than a LAN. Of course, the disadvantage to this distributed infrastructure is that you must have many more DHCP servers on your network, so you have more areas of concern to manage and monitor.
As an example, another organization I've had experience with also has multiple subnets configured on their network through VLANs, but their network is very distributed and each VLAN maps directly to a single remote location. Each remote site has a WAN link for access to the main location, and each location has a router and switch (or multiple switches) at that location to support local and remote traffic. In this scenario, the local core switches themselves provide DHCP service to the site instead of using Windows Server 2003 DHCP servers, so the extra cost of using this model is fairly low. Your experiences with distributed infrastructures might be very different, however.
Mixed Infrastructures
As you might have guessed, a mixed infrastructure combines features of the centralized and distributed infrastructure models. Using the mixed infrastructure model, you can plan for DHCP server placement on a location-by-location basis that makes the most sense for each location. When using the mixed infrastructure model, you will likely still have two or more DHCP servers in your central data center, but you'll also have one or more DHCP servers locally in remote locations where you have large client populations, for example.
Planning a DHCP Server Placement Strategy
You've probably heard before that you should use either the 70/30 or the 80/20 rule when planning and implementing DHCP on your network. But what exactly do these rules mean? Is it even correct to assume that using one of these rules is always the correct answer? As you no doubt know by now, there are no absolutes in network design—only best practices that have typically been proven to yield consistently high quality results when implemented properly. As such, you cannot just blindly follow either the 70/30 or the 80/20 rule in your DHCP design. In this section, we examine some items you'll want to consider when planning the placement of DHCP servers on your network.
The DHCP Rules
The real question you have to answer before deciding on a DHCP server rule is whether you will have multiple DHCP servers on multiple subnets. If so, you should consider using either the 70/30 or the 80/20 rule. These rules break up your DHCP scope ranges so that 70% (or 80%) of the available IP addresses in a scope range are configured on the DHCP server on the local subnet, with the remaining 30% (or 20%) of the available IP addresses in a scope range configured on a DHCP server located on a different subnet. Different subnets are typically broken up by switches or routers, and each subnet is a single broadcast domain, so this design strategy works well. DHCP is a broadcast-based system; by default, clients will find the DHCP server on their local subnet and obtain a lease, if available, from that local DHCP server.
On the other hand, if you will be placing your DHCP servers on the same subnet, you will want to follow the 50/50 rule, with each DHCP server containing half of the available IP addresses in the scope range. This model also works well in large organizations that have multiple VLANs and use VLAN trunking and a subnet mask that creates a single large broadcast domain. Although this is not a common design on the network side, when it is done properly, it can work well. When using the 50/50 rule for DHCP servers, you typically have more IP addresses available within your organization than are needed; either DHCP server will be capable of servicing the entire organization if the other fails.
The rules we've discussed here seem to imply using only two DHCP servers, which, in most organizations is adequate, but you can extend this logic to four, six, eight, or more DHCP servers. It's obviously easier to work with DHCP servers in pairs of two, but you should use the number that is best for your organization.
Creating Standby Servers
If you choose to follow one of the rules we discussed previously—80/20, 70/30 or 50/50—you might not need to worry about having a standby server configured. If you use a single DHCP server for your organization, you should seriously consider configuring and implementing a hot standby DHCP server. This standby DHCP server should be installed and configured identically to your production DHCP server, including all scopes and options, but will not provide DHCP leases until you manually configure it to do so.
You can either configure and enable all scopes and options but not authorize the DHCP server in Active Directory, or authorize the DHCP server in Active Directory but not enable any scopes to stage the standby server for when it is needed. As a practical matter, it is simpler (and quicker) to have all the scopes configured and enabled, but have the server itself not authorized in Active Directory. Note that although a standby server ensures that you can continue to provide DHCP if the primary DHCP server becomes unavailable, this is a manual method that requires an administrator to enable the standby DHCP server to function and provide leases to clients. For that reason, you should consider the standby server model as a nonpreferred one and instead use multiple DHCP servers to provide services, as discussed previously.
Clustering DHCP Servers
DHCP in Windows Server 2003 is a clustering-aware application; therefore, you can implement and configure DHCP servers in a cluster arrangement for maximum fault tolerance and failover. When you implement DHCP in a cluster, you do not need to use the 70/30 or 80/20 rules. In this implementation, you can opt to use the 50/50 rule for maximum fault tolerance or just place the entire scope range on a single DHCP virtual server. Clustering, which is discussed in more detail in Chapter 10, "Planning, Implementing, and Maintaining Highly Available Servers," does have some very high hardware and software resource requirements, however, so it is not the right or best solution for every organization.
Planning for DHCP Reservations
Although it is perfectly acceptable—and preferred—for most client workstations to use DHCP and get a randomly assigned IP address, sometimes you will want to use DHCP to assign the same IP address to a specific network object every time. Enter the DHCP reservation. A DHCP reservation is configured in a specific DHCP zone by entering the MAC address of network adapter installed in the client (printer, workstation, network hardware) that you want to have the same DHCP assigned IP address every time. Using reservations allows the client to be configured for DHCP, but still get a static IP address and other information being passed by the DHCP server as part of that scope where the reservation was configured.
Although it sounds like you might want to use DHCP reservations for every client on your network that requires a static IP address, this is not always the case. It's still best practice to always assign a static IP address to any Windows server that will be providing a network service such as DNS, WINS, DHCP, Exchange, SQL or Active Directory. In fact, services such as DNS and DHCP will actually "complain" about the network adapters installed in the server being configured for DHCP and not having a static network address. Most organizations that actually make use of DHCP reservations tend to use them for workstations that need the same IP address all the time or for printers on the network. In reality, most organizations still configure networked printers with a static IP address.
Planning for DHCP Options
A DHCP scope is not just a range of IP addresses that can be handed out to requesting clients—it's also a full suite of TCP/IP configuration information that the clients need to communicate effectively on the network. When you create your DHCP scopes, you can configure common DHCP scope options—be sure that you do, or your clients will likely not be able to communicate effectively.
Table 3.1 presents some of the most commonly used DHCP scope options configured.
Table 3.1. Common DHCP Scope Options
|
Code |
Option Name |
Option Description |
|
3 |
Router |
Specifies a list of IP addresses for routers on the client's subnet |
|
4 |
Time Server |
Specifies a list of RFC 868 time servers available to the client |
|
6 |
DNS Servers |
Specifies a list of DNS servers available to the client |
|
15 |
DNS Domain Name |
Specifies the domain name that the client should use when resolving host names via DNS |
|
27 |
All Subnets Are Local |
Specifies whether the client can assume that all subnets of the IP network to which the client is connected use the same MTU as the subnet of the network to which the client is directly connected |
|
28 |
Broadcast Address |
Specifies the broadcast address in use on the client's subnet |
|
44 |
WINS/NBNS Servers |
Specifies a list of RFC 1001/1002 NBNS servers, listed in order of preference |
|
46 |
WINS/NBT Node Type |
Allows NetBT clients, which can be configured as described in RFC 1001/1002 |
DHCP has a provision for configuring manufacturer-specific DHCP options. You can select these options by opening the DHCP management console and selecting the scope for which to configure options, as described later in Step by Step 3.3. Selecting the Advanced tab enables you to select Microsoft Options from the drop-down list in the Vendor Class window. Table 3.2 shows the manufacturer options that Microsoft defines.
Table 3.2. Microsoft-Specific DHCP Options
|
Code |
Option Name |
Description |
|
1 |
Microsoft Disable NetBIOS |
This option can be used to selectively enable or disable NetBT for DHCP-enabled computers running Windows. |
|
2 |
Microsoft Release DHCP |
This option can be used to control whether DHCP-enabled Lease on Shutdown computers running Windows send a release for their current DHCP lease to the DHCP server when shutdown occurs. |
|
3 |
Microsoft Default Router Metric Base |
This value is a specified router metric base to be used for all default gateway routes. |
You can configure DHCP options at four different levels for each DHCP server:
- Server options—These are DHCP options that are applied, by default, to all scopes on the DHCP server.
- Scope options—These are DHCP options that are applied only to the specific scope on the DHCP server. When a scope option conflicts with a server option, the scope option wins and that value is made a part of the scope. If the conflicting scope option is later removed, the server option once again becomes effective in the scope.
- Class options—These are DHCP options that are applied only to clients identified as members of specified user or vendor classes.
- Reservation options—These are DHCP options that are applied only to a single specific computer.
Now that we've done some initial planning for an implementation of the DHCP service in Windows Server 2003, we can talk about installing and implementing it on the network. After DHCP is installed and configured, we'll take some time to examine how it can be secured and also how you'll go about troubleshooting it.