Search the Catalog
DHCP for Windows 2000

DHCP for Windows 2000

Managing the Dynamic Host Configuration Protocol

By Neall Alcott
January 2001
1-56592-838-5, Order Number: 8385
288 pages, $34.95

Chapter 4
Designing a DHCP Infrastructure

DHCP can quickly become an essential piece of an organization's data network. Once set up, DHCP is usually hardly noticed, silently and faithfully performing its duties day in and day out. Unfortunately, the hardest thing with DHCP is getting it to that point.

This chapter discusses the reasons an organization would want to use DHCP, along with the many different issues that need to be considered when designing a DHCP infrastructure.

Some of these considerations include planning for IP address use. An organization needs to determine how their existing environment is used as well as what types of users and workstations exist, such as mobile users and network devices.

The needs of a DHCP client must be considered, including which DHCP options are supported by the client's operating system and which options and their values need to be assigned.

In large-scale DHCP implementations, the topology of the network becomes a very important factor. The network topology dictates where DHCP servers and/or relay agents must be placed.

A final consideration is planning for fault tolerance. Once DHCP is implemented, it quickly becomes a service that the entire network is dependent on. Steps can be taken to ensure that DHCP will be available at all times.

Who Needs DHCP?

The Internet Engineering Task Force (IETF) created this new protocol, DHCP, to dynamically distribute IP addresses and configurations to clients. But what types of organizations would benefit from using DHCP?

Some administrators believe that having to administer yet another network service and the additional traffic it creates is an unnecessary burden. Administrators with this philosophy believe that it is easier to set up workstations and servers with static configurations that do not need to be maintained or administered.

In reality, however, any organization that wants to save the time and aggravation of manually maintaining the allocation of IP addresses would want to use DHCP. DHCP allows an administrator to standardize the IP address configurations for the entire network while dynamically maintaining the address table in a database.

Small companies benefit from DHCP because of the lower administrative burden. Most small companies cannot afford a full time network administrator who knows the ins and outs of IP addressing. Typically they delegate network administration to the one person in the office who is the most computer-savvy, whether or not he or she has technical training or experience with networking. By utilizing DHCP, the day-to-day administration of IP addressing and associated configuration details is handled automatically without any intervention from office personnel.

The biggest problem for small companies is the initial implementation of DHCP. Small companies may have to use a consultant for the initial implementation, during which the designated administrator is trained in the administration of DHCP. Alternatively, the administrator can attempt the DHCP implementation through trial and error, although this is not recommended.

Larger enterprises benefit from DHCP on two fronts: lower administrative burden and standardized IP configurations throughout the organization.

The benefit of lower administrative burden is similar to the benefit reaped by a small company, with the addition of the time saved from administering an IP address table. The next section about static IP addressing discusses some of the problems with manually maintaining the IP address table.

Larger enterprises also benefit from standardized IP configurations. Using standardized configurations minimizes connectivity problems relating to incorrect IP addresses, subnet masks, and default gateways. It also diminishes name resolution errors resulting from incorrect DNS and WINS addresses.

DHCP can also benefit organizations with a mobile workforce. With valid IP addresses in short supply, assigning static addresses to users with laptops would be both inefficient and foolish. The very nature of mobile users dictates that they will be connecting to the corporate network intermittently. Thus they do not require the constant exclusive use of an IP address. By using DHCP, an administrator can configure the DHCP server to reclaim these IP addresses after a short period of time. For example, for a company with 500 mobile users and 200 valid IP addresses to allocate, the administrator can set up the DHCP server to allocate these 200 IP addresses to mobile users. The administrator configures the lease time for the mobile users scope to a short duration, say one day. When a mobile user connects to the network, the DHCP client on the user's laptop negotiates an IP address lease from the DHCP server. The mobile user then proceeds to access network resources, such as email and file services. When the user is finished, he disconnects from the network. The DHCP server then reclaims the IP address once the one-day lease period expires.

Another option for a mobile workforce is to utilize a DHCP User Class. This is a new feature found in the Windows 2000 DHCP server. It allows you to assign additional configuration data to a particular set of users. Let's continue the example above. Instead of configuring a separate scope for the 200 IP addresses, the administrator could create a DHCP User Class for the mobile users. The user class would specify a lease period that is shorter in duration than the rest of the scope. The administrator would then configure each laptop's DHCP client to specify that the laptop is a member of this user class.

Creating an IP Addressing Plan

Before deciding to implement DHCP, an administrator must first decide on an IP addressing plan. There are many different ways to create an IP addressing plan, and in some cases they may need to be combined. This is a critical step because it is the foundation of the entire DHCP infrastructure. This section looks into each of the different methods, describing their benefits, how they may be implemented, and some of their limitations.

Static IP Addressing

In an environment that uses static IP addressing, when an administrator installs a new workstation, she looks up an available IP address and the corresponding subnet mask in the IP address table. This table may be written in a notebook or saved on a computer in a spreadsheet. Once she finds the IP address, she needs to determine the correct DNS and WINS server addresses for the workstation to use. In addition, in a routed environment, the administrator needs to ascertain the correct default gateway address for the workstation's subnet. Then she manually configures the workstation with the proper TCP/IP information. For small networks or networks that do not experience many changes, this may be fine.

One of the downsides to this method of administering IP addresses is human error. If the administrator mistypes the IP address or subnet mask, the workstation may not have connectivity to the resources it requires. If the DNS or WINS server IP addresses are mistyped, the workstation will not be able to perform name resolution. If the default gateway is incorrect, the workstation will not be able to connect to remote subnets and resources.

Another downside is maintaining the IP address table. The administrator must continually spend time viewing and searching the address table for available addresses. Once she finds an available address, the administrator must note in the table that the IP address is now in use. Also, by storing the address table in a notebook, the table could easily be lost. Even storing the address table in a spreadsheet does not lessen the chance that it will become corrupted or lost.

Moreover, if the network is large and its users move about often, using static IP configurations can be frustrating and inefficient. Problems such as the ones described earlier are compounded with larger networks. Incorrect configurations have a much larger effect on connectivity, as the workstation routinely needs access to resources on different subnets. Maintaining the IP address table centrally becomes nearly impossible. In all likelihood, the address table would need to be divided along subnets and individually maintained by the local administrator.

Static IP addressing can also be a huge liability if the organization needs to redesign their entire addressing structure. Factors that cause organizations to change their addressing structure include mergers and acquisitions, changing Internet service providers (ISPs), or network growth. Changing IP address configurations enterprise-wide requires an administrator to visit each workstation, server, and network device. In the end, it costs the organization a lot of time and money.

In short, as the network's capacity and scope grows in size, static IP address administration becomes unwieldy and inefficient.

Dynamic IP Addressing

There are four methods of dynamically allocating IP addresses: automatic, dynamic, roaming, and manual. Three of these methods, dynamic, roaming, and manual, use DHCP to allocate the IP addresses.

Automatic allocation

Automatic IP addressing utilizes the client's operating system to allocate a private IP address. Microsoft's Windows 2000 and Windows 98, along with the Apple MacOS 8.5 and later, are operating systems that support Automatic Private IP Addressing (APIPA).

The theory behind APIPA is that small ad hoc networks will be able to achieve basic connectivity without the need for intervention by the administrator.

An example of an ad hoc network would be a dentist's office. The dentist has 5 separate computers. One night at a dinner party, a friend tells him of all the benefits she is reaping from her new computer network. The dentist decides that he too could benefit from a network. He buys the necessary cabling and hooks everything together. Typically at this point things start getting difficult. It is likely that he doesn't have a deep understanding of the Windows 2000 operating system or the TCP/IP protocol. However, with APIPA, the computers will be automatically configured. In the end, the dentist will have a functioning network.

APIPA allows a workstation to configure itself with an IP address in the absence of DHCP or any other IP addressing mechanism. Other networking protocols, such as IPX/SPX and Appletalk, already include this type of functionality.

Creating small ad hoc networks can be very useful in environments such as small businesses and homes that include only a few machines. In order for the machines to communicate, they must be configured with IP addresses.

Computers using APIPA must also be DHCP clients. This is because APIPA uses the DHCP client to determine whether a DHCP server is available.

Using the DHCP client, the computer requests an IP address by sending a DHCPDISCOVER message. After not receiving a response, the computer automatically configures itself with an IP address in the reserved Class B network 169.254.0.0 and a subnet mask of 255.255.0.0. The DHCP client then performs a duplicate address check by sending an ARP request for the IP address. If it receives a response, it determines that the address is in use. At this point it selects another address from the 169.254.0.0 subnet and again performs a duplicate address check. The client repeats this process for up to 10 addresses, after which the automatic addressing fails.

Automatic allocation is a quick and easy solution to the IP addressing problem, but is only useful in small networks that need basic connectivity without Internet access. Larger environments are typically subnetted to segment network traffic and increase performance. Since APIPA is limited to the 169.254/16 subnet, it cannot be utilized in those environments. The downside to using APIPA even in small networks is the difficulty it may cause in troubleshooting connectivity issues.

Internet Connection Sharing

Internet Connection Sharing (ICS) is a new feature found in Windows 2000 Professional and Windows 2000 Server that permits a single computer to host an Internet connection for a network.

For example, if you have a small network with 15 computers, only one of the computers (running Windows 2000 and ICS) requires a connection to the Internet. This computer, known as the ICS server, hosts the Internet connection via a dial-up line, cable modem, or xDSL. The remaining 14 computers are ICS clients that access the Internet via the ICS server.

ICS provides network address translation (NAT), IP address allocation via DHCP, and name resolution services via DNS for all ICS clients. Clients can use Internet applications (e.g., Internet Explorer and Outlook) just as though the computers themselves were connected to the Internet.

The ICS server can also be configured to terminate the Internet connection when not needed. If one of the ICS clients attempts access when the Internet connection is down, ICS automatically dials the ISP and establishes a connection. The client is then able to access the requested resource.

The ICS server needs two network connections: one for the internal network (i.e., the connection for ICS clients in the office) and one for the connection to the Internet.

By enabling ICS, the computer automatically becomes a DHCP server for the office network. DHCP automatically assigns IP addresses to the hosts on the office network along with TCP/IP configuration information such as DNS servers.

When ICS is enabled, the computer acting as the ICS server is configured with a static IP address 192.168.0.1 and subnet mask 255.255.255.0. ICS's internal DHCP server is configured with a scope of 192.168.0.2 through 192.168.0.254.

Note that these default settings cannot be modified, nor can any particular service such as DHCP or DNS Proxy be disabled. If you are already running a DHCP server on your network, the ICS internal DHCP server and your network DHCP server will both attempt to honor DHCP client requests, resulting in NACKs (negative acknowledgments). In this case you cannot utilize ICS on your network. Consider using Windows 2000's Network Address Translating (NAT) instead.

Dynamic allocation

Dynamic allocation uses DHCP as the mechanism to allocate IP addresses. The administrator assigns a range of addresses to the DHCP server. The DHCP server, in turn, assigns an IP address in the range to DHCP clients upon request. This range is known as a scope. For example, if an administrator has workstations on a network and wants to assign these workstations addresses in the 192.168.1.0/24 subnet, he creates a DHCP scope that consists of the IP addresses 192.168.1.1 through 192.168.1.254. When a DHCP client requests an address from the DHCP server, the server assigns one of these addresses.

The administrator, when defining a scope, also specifies the lease duration for any IP address assignments from the scope. A lease duration is the amount of time that a DHCP client has exclusive use of an IP address. With DHCP, the client has two opportunities to extend the lease, first when the lease duration is 50% complete and then again when the lease duration is 87.5% complete. After the lease duration has expired, the DHCP client must request a new lease from a DHCP server.

The administrator, if needed, can also exempt certain addresses from the scope. These addresses may be network devices or hosts whose IP addresses should not change, for example, network printers, routers, and servers. The administrator can set aside a portion of the scope, say 192.168.1.1 through 192.168.1.25, for these devices. Now when a DHCP client requests an IP address, the DHCP server assigns an address between 192.168.1.26 through 192.168.1.254. Another option for network devices such as these would be to configure a DHCP reservation, where the DHCP server allocates the same IP address to the device's MAC address.

Roaming allocation

Roaming allocation can be used in situations where there are areas that users may visit temporarily with their laptops. Such areas may be libraries, classrooms, laboratories, or conference rooms where users will need a DHCP-allocated address for a brief period of time.

The basic configuration of the roaming allocation method is much like the dynamic allocation method, with the notable exception that the lease duration time is very short for the scopes that service these areas.

For example, a company may have a conference room where users want to utilize network resources via their laptops. For the roaming allocation method to work, the conference room LAN first needs to be segmented. This is required because a subnet can be serviced by only one scope at a time. The administrator then creates a scope for the conference room subnet. The scope is given a lease duration of about 45 minutes. When users connect to the conference room LAN, they receive an IP address from the conference room scope. Once they leave the conference room, the user can wait for the lease to expire, at which point the laptop will restart the DHCP conversation. They could also release the IP address and request a new one.

The roaming allocation method is useful in small, local implementations. Although it can be used on a larger scale, the short lease duration may cause excessive DHCP traffic and additional load on the DHCP servers.

DHCP and Remote Users

Any organization that employs a mobile workforce, such as salespeople or field technicians, needs to consider how their remote connectivity strategy and DHCP interact. This section discusses how Windows 2000 supports remote users. If your organization utilizes a third-party solution such as Shiva or Cisco for remote access, please refer to that vendor's documentation to implement DHCP for remote access.

Windows 2000 utilizes Routing and Remote Access Service (RRAS) to provide remote connectivity. RRAS includes a number of components that deal with routing and remote access issues, such as routing protocols (Open Shortest Path First [OSPF], Routing Information Protocol 1 [RIP1], and Routing Information Protocol 2 [RIP2] ), Lightweight Directory Access Protocol (LDAP), Remote Access Dial-up User Service (RADIUS), and Virtual Private Network (VPN).

When a remote access client connects to the RRAS server, the RRAS server assigns the client an IP address along with the IP addresses of DNS and WINS servers.

There are a couple of items that need to be considered when designing a remote access infrastructure using RRAS. The RRAS server can be configured to utilize DHCP to obtain IP addresses for remote clients. You can also configure the RRAS server to assign IP addresses from a static IP address pool.

If the RRAS server is configured to use DHCP, the DHCP client on the RRAS server allocates 10 IP addresses from a DHCP server. The first allocated IP address is assigned to the RRAS server interface. The remaining IP addresses are assigned to the remote clients as they connect. When the initial pool of 10 IP addresses is depleted, the RRAS server's DHCP client allocates an additional 10 IP addresses from a DHCP server.

You can change the size of the initial address pool by modifying the value of the InitialAddressPoolSize entry in the registry. This entry can be found at HKLM\System\CurrentControlSet\Services\RemoteAccess\Parameters\Ip.

If a DHCP server is not available when the RRAS server is started, the DHCP client will allocate the IP address pool using APIPA. In other words, it will allocate 10 IP addresses from the range 169.254.0.1 through 169.254.255.254 with a subnet 255.255.255.0. Note that remote clients receiving an APIPA-based address will only be able to connect to the RRAS server, unless of course the APIPA is in use throughout the rest of the network.

The remote access server found in Windows NT 4.0 recorded the IP addresses obtained via DHCP. It reused them when the RRAS server was restarted. Windows 2000, however, releases the entire IP address pool whenever it is restarted.

You can also configure the RRAS server to assign IP addresses for DNS and WINS servers to remote clients. You can implement one of the following ways to assign DNS and WINS addresses:

  • Prohibit the RRAS server from assigning DNS and WINS addresses.

  • Globally assign DNS and WINS addresses from values stored in RRAS server's registry.

  • Utilize the IP configuration on the RRAS server's interface.

If you want to prohibit the RRAS server from assigning the DNS and WINS addresses, you must set the values of SuppressDNSNameServers and SuppressWINSNameServers entries to 1. These entries can be found at HKLM\System\CurrentControlSet\Services\RemoteAccess\Parameters\Ip.

If you want to globally assign DNS and WINS addresses, you must enter the IP addresses as values of the DNSNameServers and WINSNameServers entries. Again, these entries can be found at HKLM\System\CurrentControlSet\Services\RemoteAccess\Parameters\Ip.

If the DNS and WINS address assignments are not prohibited or globally configured, the RRAS server will determine their assignments via the IP configuration of its LAN interface. If the IP configuration is static, the interface's statically assigned DNS and WINS addresses will be assigned to remote clients. If the IP configuration was obtained via DHCP, the interface's DHCP-assigned DNS and WINS addresses will be assigned to remote clients.

If the RRAS server contains more than one LAN interface, by default it will choose the LAN interface randomly. You can override this action by unselecting the "Allow RAS to select adapter" checkbox under IP properties and selecting the desired interface. This setting can be found in the Routing and Remote Access Microsoft Management Console (MMC).

Manual allocation

Manual allocation is another method that can be used in situations where an administrator wants to know the MAC address of the DHCP client before assigning an IP address. An administrator may want to do this for security reasons, or may simply want to know who is utilizing network resources for billing purposes. Manual allocation is typically used in academic settings.

The manual allocation process begins when a user wants to install a new computer or device on the network. The user must submit a request to the administrator that includes his computer's MAC address and its physical location (i.e., building and room number). Once the administrator receives the request, she configures an IP address reservation on the DHCP server. This reservation is placed in the appropriate subnet scope (i.e., the user's physical location) using the user's MAC address (i.e., the user's computer). Once notified that everything has been set up, the user can then boot the workstation. The workstation then obtains the IP address from the DHCP server.

Manual allocation can also be used for network devices such as servers and network printers. In this case, the MAC address of the server is used to create a reservation. With reservations, changes can be made to the IP configurations of all servers in a particular scope or even the entire enterprise. For example, if an administrator wants all servers to point to another DNS server, she could simply change the Name Server option for the scope where the servers were located. When a server renews its address lease, it will receive the updated Name Server option.

As you can see, manual allocation is very time consuming and labor intensive. In essence, manual allocation is very similar to using BOOTP. It should only be used in environments that require knowledge of what devices are connecting to the network.

Combining dynamic addressing methods

Some of these methods can be combined and intertwined to create the DHCP solution an organization requires. The only one that cannot be combined is the automatic allocation method (unless your network is going to use the 169.254.0.0 subnet, of course).

For example, an organization may want to use static IP addressing for some network devices, such as network printers and file servers, while using the dynamic allocation method for the rest of their network. They can also create some subnets for conference rooms and libraries using the roaming allocation method.

Network Topology

When designing a DHCP infrastructure, it is important to take into account the topology of the network being serviced. By determining the topology, the designer will be able to anticipate where the load on the DHCP servers may be high and identify single points of failure that may cause DHCP services to be disrupted.

There are two different areas that need to be examined:

By determining the physical layout of the network, the designer will be able to create a list of subnets that need to be serviced by DHCP. This information will be needed when scopes are created later.

Another important factor is the placement of DHCP relay agents. The physical layout of the network establishes which routers and subnets will need to be serviced by relay agents.

The number of users in each location helps determine the placement of DHCP servers. If there are a small number of users located in a single location, the DHCP server may be placed in a remote subnet with a DHCP Relay Agent set up on the router to listen for DHCP requests. This eliminates the need to place a server physically on the LAN where the users reside. If the WAN link goes down, the number of users disrupted is minimized.

WARNING:  

If some of your DHCP clients at remote sites are Windows 2000 or Windows 98 systems and the WAN link goes down, they will not be able to contact a DHCP server. As mentioned earlier in this chapter, when these operating systems fail to contact a DHCP server, they resort to using APIPA to obtain an IP address. As a result, once the WAN link is restored, they will not be able to achieve network connectivity with the rest of the production network until the APIPA address is released. Connectivity is restored once a new address lease is obtained from the DHCP server. See Chapter 7, Advanced DHCP, for information about disabling APIPA in Windows 2000 and Windows 98.

In situations where the number of users is high, the DHCP server should be placed locally. In this case the loss of the WAN link will not disrupt DHCP service.

DHCP Client Needs

Before creating any scopes, an administrator must first determine the needs of the DHCP clients the scope will be servicing.

Besides receiving an IP address, subnet mask, and default gateway from a DHCP server, DHCP clients can receive DHCP options that supply many different configuration parameters. Deciding which DHCP options to include can be determined by asking the following questions:

Determining which options are required is relatively simple, unless there are applications in use that have special needs. Besides determining which options to use, an administrator must determine the values of those options as well. For example, an administrator wants the DHCP clients to receive DNS server addresses. For load balancing, each subnet has a different secondary DNS server to service client requests. In this case, the administrator must supply the correct IP address for each subnet's DNS server.

Next, an administrator must determine which DHCP clients are in use on the network. Since Microsoft operating systems are the most prevalent on most corporate desktops and laptops, it can pretty much be said that almost every network includes some Microsoft DHCP clients.

But there may be other types of DHCP clients as well, such as Unix, Linux, or Macintosh. Although these operating systems can all be DHCP clients, their implementations of DHCP vary. For example, they may not support certain DHCP options, such as WINS servers. The DHCP server in Windows 2000 supports all DHCP options defined in RFC2132. If you have a non-Microsoft DHCP client, you can configure the Windows 2000 DHCP Server to supply any DHCP option that the client can support. Refer to your non-Microsoft DHCP client's documentation for a complete list of supported DHCP options.

There may also be network devices that support DHCP, such as network printers. Deciding whether or not to use DHCP for network printers is a matter of choice; most administrators prefer to assign static addresses to the printers. This way IP addresses for the printers are always known, thus simplifying management and troubleshooting. However, DHCP can be used with network printers by using the manual allocation addressing method. By creating an address reservation using the printer's MAC address, the printer can receive other configuration information that may change from time to time, such as name server addresses.

Determining the DHCP options that the DHCP clients support can be a bit trickier. I will briefly describe which options are supported by most of the major operating systems. An administrator should always refer to the operating system's documentation to ascertain which options are supported.

Microsoft-based clients request the following DHCP options, described in Chapter 3, Making Life Easier: DHCP, and defined as properties of the scope:

Microsoft-based clients will also request the following DHCP options:

It is important to remember that these are the only options supported by Microsoft DHCP clients. Any other DHCP options specified by the DHCP server will be ignored.

TIP:  

The appendix, DHCP Options, lists all currently available DHCP options. Third-party clients such as Unix, Linux, and MacOS may also support these DHCP options.

Defining Scopes

Now that the IP addressing plan, network topology, and DHCP client needs have been defined, it is time to start defining the various scopes.

Address Ranges

When defining a scope, the most important information to define is the address range of the scope. The address range will be used by the DHCP server to determine which IP address to assign to a DHCP client. The address range is defined by the subnet the scope will be servicing. For example, if the subnet is 10.64.0.0/11, the valid range of IP addresses for this scope is 10.64.0.1 through 10.95.255.254. For any statically configured network devices on that subnet, exemptions have to be created. An exemption designates an IP address not to be assigned to a DHCP client. If a static IP address was not exempted, the DHCP server may assign the IP address to a DHCP client. As a result, an IP address conflict could occur and cause connectivity problems for the two computers involved.

If the IP addressing plan calls for using dynamic address allocation for this subnet, simply assign the address range to the scope. If the IP addressing plan calls for using manual address allocation, reservations need to be created for each network device.

Lease Durations

Lease durations determine when the DHCP server can reclaim the allocated IP address. Usually the default time period, 8 days, is more than sufficient for most scopes. Setting the lease duration too long will cause IP addresses to be shown as allocated, thus unable to be reclaimed. Setting the lease duration too short may cause excessive DHCP traffic on the network as DHCP clients attempt to renew their address leases.

One situation that does call for a shorter lease duration is when the roaming address allocation method is being used on a scope. By specifying a short lease duration, the DHCP server will be able to reclaim IP addresses that are only in use for a short period of time, such as a conference room or library.

Options

Any options required by the DHCP clients being serviced by the scope need to be configured at this point. Options such as the Router Option (3) need to specify the IP address for the default gateway on the subnet. Other options should be specified as well, such as the IP addresses of the DNS servers that will be servicing the subnet.

Fault Tolerance

Since DHCP is a critical network service, it is important for the designer to take steps that will make it fault tolerant. DHCP does not have a built-in method of fault tolerance. DHCP servers do not communicate with each other, letting the other know which addresses are allocated and whether or not it is still in operation. To create a fault tolerant DHCP service, the designer needs to manually create a fault tolerant design using scopes and/or clustering.

Splitting Scopes

Splitting scopes is a method to create DHCP fault tolerance. It is the process of creating two scopes, one on each DHCP server. The two scopes both service the same subnet, but the range of addresses is divided. If one DHCP server becomes unavailable, the remaining DHCP server continues to service DHCP client requests using its portion of the address range. So where is the address range split? That is determined by the needs of the network implementation.

The 50/50 method

The 50/50 method of splitting scopes provides both fault tolerance and load balancing for DHCP servers. In this method, 50% of the available address range is given to one scope, and the remaining 50% is given to the other scope. Typically this method is used when both DHCP servers are centrally located on the same subnet. When a DHCP client requests an IP address, the request is received by both servers and both respond with an offer. The client then accepts one of the offers (i.e., the first offer received). The selected DHCP server allocates the address and sends the acknowledgement to the client.

The 50/50 method of splitting scopes can only be implemented where the number of available IP addresses is plentiful. This allows each scope to fully service the number of DHCP clients requesting addresses in the event that one of the DHCP servers fails.

The 80/20 method

The 80/20 method of splitting scopes provides fault tolerance in a subnetted environment. In the 80/20 method, two DHCP servers are configured. One DHCP server resides on the subnet the scope is servicing. The other DHCP server is on another remote subnet.

80% of the available address range is allocated to the local DHCP server. The remaining 20% is allocated to the remote DHCP server. The router connecting the subnets is configured with a DHCP relay agent that will forward DHCP requests to the remote DHCP server. When a DHCP client on the local subnet sends out a DHCP request, the local DHCP server responds first with an offer. The remote DHCP server's request arrives later since it needs to traverse the WAN. The DHCP client then accepts the offer from the local DHCP server. In the event that the local DHCP server fails, the client eventually receives a response from the remote DHCP server.

The downside of the 80/20 method is that the remote DHCP server, with only 20% of the available address space, will not be able to handle all DHCP requests from the subnet.

Clustering

In Windows 2000, Microsoft added a new capability to the DHCP service, called clustering. A cluster is a group of servers (typically two nodes) that work in unison. By working together, the nodes provide load balancing and fault tolerance for the services the cluster provides. To the rest of the network, the cluster looks like a single server. By combining the DHCP service and clustering, a type of DHCP failover can be achieved.

The DHCP Server included in Windows 2000 is a cluster-aware application. This means that in the event that one node in the cluster fails, the DHCP service can be restarted on the surviving node. This is accomplished because the DHCP database, which houses all current address leases, is shared between the nodes. When the second node takes over, it is completely aware of all outstanding IP address leases and will not give out duplicate IP addresses.

Since the cluster itself appears as a single entity to the network, DHCP clients continue to communicate with the cluster's IP address. They are completely unaware that the second node in the cluster is responding to their requests.

Clustering is Microsoft's recommended strategy for DHCP fault tolerance in Windows 2000.

Putting It All Together: DHCP Strategies

DHCP can be used in many different networking environments. Regardless of the networking environment, DHCP in itself operates fundamentally the same. In other words, the server is installed, scopes are created, options are configured, and DHCP clients start receiving address leases. However, depending on the network infrastructure, more planning and configuration may need to take place before DHCP can function efficiently and acceptably. Fortunately, DHCP is very flexible, and a designer can take many different design ideas to create the solution best suited for the environment.

Non-Routed Environment (Single Subnet)

DHCP operating on a single subnet is the simplest DHCP configuration. A single subnet does not include any routers or DHCP relay agents. By simply installing and configuring the DHCP server, DHCP clients can begin allocating dynamic IP addresses.

Designing a DHCP strategy for a non-routed environment consists of determining the hardware requirements of the DHCP server and then deciding which clients will be assigned dynamic addresses and which will be configured with static addresses (typically servers and network printers). Finally, the designer determines which DHCP options need to be used, such as the IP addresses for the DNS and WINS servers on the network.

The network shown in Figure 4-1 consists of a single subnet that includes a DHCP server and several DHCP clients. To begin servicing the clients, the DHCP server needs a single scope whose addresses fall within the range of the subnet. Usually, in this scenario, the default lease duration of 8 days is sufficient.

Figure 4-1. DHCP in a single subnet environment

 

Routed Environments (Multiple Subnets)

In a routed environment, more planning must be done in the design phase to create the appropriate DHCP infrastructure. The first step includes the layout of the subnets and deciding the placement of the DHCP servers. This step also includes deciding which fault tolerant strategies should be incorporated into the plan.

The layout of the subnets typically follows the physical layout of the network, such as remote sites or buildings in a campus. The subnet layout can also be determined by function or lines of business, e.g., the sales department and engineering department may be located on separate subnets, although they are both in the same building.

The placement of the DHCP servers can be a little bit trickier. In general, the placement of the DHCP servers should not be determined by the administrative structure of the network (i.e., domains or Active Directory), but by the number of users that need DHCP services. Placement of DHCP servers must also consider fault tolerance strategies so a particular subnet can continuously be serviced by DHCP.

Figure 4-2 shows one possible network topology. By using the data obtained from the network topology, the designer can create a table (see Table 4-1) listing the different sites, the number of users in each site, the subnets that service the site, and the number of addresses available in each subnet.

Figure 4-2. Routed network topology example

 

Table 4-1: Network Topology Requirements

Site

Number of Users

Subnet Address

Number of Hosts

Corp HQ

10,000

168.3.4.0

1022

 

 

168.3.8.0

1022

 

 

168.3.12.0

1022

 

 

168.3.16.0

1022

 

 

168.3.20.0

1022

 

 

168.3.24.0

1022

 

 

168.3.28.0

1022

 

 

168.3.32.0

1022

 

 

168.3.36.0

1022

 

 

168.3.40.0

1022

Northeast

5,000

168.3.44.0

1022

 

 

168.3.48.0

1022

 

 

168.3.52.0

1022

 

 

168.3.56.0

1022

 

 

168.3.60.0

1022

West

1,500

168.3.64.0

1022

 

 

168.3.68.0

1022

R & D

50

168.3.72.0

1022

Support

25

168.3.76.0

1022

First, review the number of users that require DHCP in each site. The Corp HQ site, with 10,000 users, definitely needs local DHCP servers. The Northeast site and the West site also require local DHCP servers. The two smaller sites, R & D and Support, have few users. Therefore they can be serviced by one of the DHCP servers back in Corp HQ.

How many DHCP servers are needed? Well, according to Microsoft, the DHCP server in Windows 2000 can handle as many as 100,000 users. So in this case a single DHCP server could handle all user requests from Corp HQ as well as the two small remote sites. However, one reason to have more than one DHCP server is to create a fault tolerant design.

To create fault tolerance, two DHCP servers can be placed in the Corp HQ site and split using the 50/50 scope splitting method. The scopes for the R & D and Support remote sites can also be split 50/50. To complete the fault tolerance plan, the routers connecting the remote sites to Corp HQ need DHCP relay agents configured to point to the DHCP servers.

The remaining two sites, Northeast and West, need one local DHCP server each. The scopes servicing these sites can be split using the 80/20 scope splitting method, with 80% of the addresses assigned to scopes on the local DHCP server and the remaining 20% assigned to scopes located on the Corp HQ DHCP servers. In the event that the DHCP server goes down on either of these sites, the DHCP servers at Corp HQ will service the client requests.

Another option for fault tolerance is the use of DHCP clusters. By replacing all the DHCP servers with DHCP clusters, the design benefits from virtually guaranteed uptime, short of a major disaster such as a power failure or fire.

To take fault tolerance even further, the designer can combine clusters with scope splitting. This ensures that the DHCP service will be available at all times.

A major factor in designing a fault tolerant plan is cost. Each of the scope splitting situations calls for an additional DHCP server. Using clusters drives the costs up further still, since a cluster must contain a minimum of two nodes.

Once server placement and fault tolerance is completed, the designer must begin creating the scopes.

In this scenario, there are a total of 19 subnets. Through scope splitting, there are a total of 38 scopes. Table 4-2 lists the scopes that need to be created.

Table 4-2: Scope Table

Site Served

DHCP Server

Scope

Address Range

Number of Addresses

Corp HQ

DHCP-HQ1 (Cluster)

168.3.4.0 (50% Scope)

168.3.4.1 through
168.3.5.255

511

 

 

168.3.8.0 (50% Scope)

168.3.8.1 through
168.3.9.255

511

 

 

168.3.12.0 (50% Scope)

168.3.12.1 through
168.3.13.255

511

 

 

168.3.16.0 (50% Scope)

168.3.16.1 through
168.3.17.255

511

 

 

168.3.20.0 (50% Scope)

168.3.20.1 through
168.3.21.255

511

 

 

168.3.24.0 (50% Scope)

168.3.24.1 through
168.3.25.255

511

 

 

168.3.28.0 (50% Scope)

168.3.28.1 through
168.3.28.255

511

 

 

168.3.32.0 (50% Scope)

168.3.32.1 through
168.3.33.255

511

 

 

168.3.36.0 (50% Scope)

168.3.36.1 through
168.3.37.255

511

 

 

168.3.40.0 (50% Scope)

168.3.40.1 through
168.3.41.255

511

 

DHCP-HQ2 (Cluster)

168.3.4.0 (50% Scope)

168.3.6.0 through
168.3.7.254

511

 

 

168.3.8.0 (50% Scope)

168.3.10.0 through
168.3.11.254

511

 

 

168.3.12.0 (50% Scope)

168.3.14.0 through
168.3.15.254

511

 

 

168.3.16.0 (50% Scope)

168.3.18.0 through
168.3.19.254

511

 

 

168.3.20.0 (50% Scope)

168.3.22.0 through
168.3.23.254

511

 

 

168.3.24.0 (50% Scope)

168.3.26.0 through
168.3.27.254

511

 

 

168.3.28.0 (50% Scope)

168.3.30.0 through
168.3.31.254

511

 

 

168.3.32.0 (50% Scope)

168.3.34.0 through
168.3.35.254

511

 

 

168.3.36.0 (50% Scope)

168.3.38.0 through
168.3.39.254

511

 

 

168.3.40.0 (50% Scope)

168.3.42.0 through
168.3.43.254

511

Northeast

DHCP-NE1 (Cluster)

168.3.44.0 (80% Scope)

168.3.44.1 through
168.3.47.49

818

 

 

168.3.48.0 (80% Scope)

168.3.48.1 through
168.3.51.49

818

 

 

168.3.52.0 (80% Scope)

168.3.52.1 through
168.3.55.49

818

 

 

168.3.56.0 (80% Scope)

168.3.56.1 through
168.3.59.49

818

 

 

168.3.60.0 (80% Scope)

168.3.60.1 through
168.3.63.49

818

 

DHCP-HQ1 (Cluster)

168.3.44.0 (20% Scope)

168.3.47.50 through
168.3.47.254

204

 

 

168.3.48.0 (20% Scope)

168.3.51.50 through
168.3.51.254

204

 

DHCP-HQ2 (Cluster)

168.3.52.0 (20% Scope)

168.3.55.50 through
168.3.55.254

204

 

 

168.3.56.0 (20% Scope)

168.3.59.50 through
168.3.59.254

204

 

 

168.3.60.0 (20% Scope)

168.3.63.50 through
168.3.63.254

204

West

DHCP-W1 (Cluster)

168.3.64.0 (80% Scope)

168.3.64.1 through
168.3.67.49

818

 

 

168.3.68.0 (80% Scope)

168.3.68.1 through
168.3.71.49

818

 

DHCP-HQ1 (Cluster)

168.3.64.0 (20% Scope)

168.3.67.50 through
168.3.67.254

204

 

 

168.3.68.0 (20% Scope)

168.3.71.50 through
168.3.71.254

204

R & D

DHCP-HQ1 (Cluster)

168.3.72.0 (50% Scope)

168.3.72.1 through
168.3.73.255

511

 

DHCP-HQ2 (Cluster)

168.3.72.0 (50% Scope)

168.3.74.0 through
168.3.75.254

511

Support

DHCP-HQ1 (Cluster)

168.3.76.0 (50% Scope)

168.3.76.1 through
168.3.77.255

511

 

DHCP-HQ2 (Cluster)

168.3.76.0 (50% Scope)

168.3.78.0 through
168.3.79.254

511

While creating the scope, the designer needs to calculate appropriate lease durations. For most of the scopes, the default lease duration of 8 days is appropriate. However, the lease durations for the two remote sites without local DHCP servers, R & D and Support, should be extended. By extending the lease duration, the designer guarantees that DHCP clients in those sites will continue to have valid IP address leases in the event of a WAN link failure. Double the default lease duration for these scopes to 16 days.

Lease durations may also need to be modified if the subnet utilizes the roaming allocation method. For example, if there is a group of conference rooms in the Corp HQ site, the designer can designate one subnet for these rooms. The scope servicing the subnet could have its lease duration set to 1 hour. This allows a user with a laptop in the conference room to obtain an IP address. When the user moves to another location, he can either release the IP address or wait for the address lease to expire. At that point the laptop restarts the DHCP conversation to obtain an IP address for the new location.

Finally, the designer must determine which DHCP options need to be specified, along with their correct values. This includes items such as the router address for each subnet, as well as DNS and WINS server addresses. The router address option needs to be defined as a scope level option. The DNS and WINS server options can be defined at the scope or global levels, depending on the DNS and WINS infrastructure. In other words, if there is a single DNS server for the entire network, the DNS server option should be specified at the global level, since all DHCP clients need to utilize the same DNS server address. If there are multiple DNS servers, the option can be specified at the scope level. This allows load balancing to take place, since each scope will point to a different DNS server.

Summary

There are many different components that need to come together to create a sound DHCP design. DHCP can be designed cafeteria-style, implementing certain components while disregarding others. Designing DHCP in this way assures that the needs of the organization are met.

This chapter discussed what types of organizations benefit from DHCP and some of the alternative methods that can be utilized. It also described the different components that are part of a DHCP solution, including IP addressing strategies, network topology, and client needs. Finally, the chapter concluded with two different scenarios and how DHCP could be implemented in each.

Back to: DHCP for Windows 2000

O'Reilly Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
 International | About O'Reilly | Affiliated Companies

© 2001, O'Reilly & Associates, Inc.
webmaster@oreilly.com