Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

Tuning Your DHCP Service

   

< Back Contents Next >

Tuning Your DHCP Service

  

16.1. -

Network Device Configuration and Address Assignment Strategies

  

16.2. -

Configuring Lease Lengths

  

16.3. -

Monitoring the Server

  

 

Summary

Save to MyCKS

 
The DHCP Handbook

From: The DHCP Handbook
Author: Ralph Droms; Ted Lemon
Publisher: MTP
More Information

16. Tuning Your DHCP Service

Tom Hickman, Cisco Systems

Ralph Droms, Ph.D

Ted Lemon

If you already read the preceding six chapters, you should have a very good idea of the mechanics of installing and configuring a DHCP server. This chapter describes how to tune your DHCP service to provide the best assistance for your DHCP clients, and it explains some of the tradeoffs you may have to make to get the smoothest possible service, given the needs at your site. It also describes some ways to monitor your DHCP server's activities so that you know when it is in trouble and whether you tuned it correctly.

16.1. Network Device Configuration and Address Assignment Strategies

Although you no doubt prefer to use DHCP to configure your network devices automatically wherever possible, you will need to (or choose to) configure some computers in some other way. In practice, you can manually configure some legacy devices with an IP address (and a static Domain Name System [DNS] hostname). Your network also includes well-known servers (such as the DHCP server, the DNS servers, Web servers, mail servers, and so on) that you should(or must) configure manually to avoid dependence on other services (such as DHCP) and to improve reliability. Additionally, network infrastructure, such as router interfaces, must be configured manually. Other legacy devices that use BOOTP for configuration, such as printers and some network hubs, may require manual configuration or provision of BOOTP service.

As you deploy and refine your DHCP service, keep in mind how to handle devices that aren't configured using DHCP and how to ensure that those devices don't interfere with your DHCP service.

16.1.1. Manual Configuration

You may have legacy devices in your network that you must manually configure with a IP address and other information, such as a default router and a DNS server. UNIX systems include these configuration parameters in an initialization script. Windows systems are configured through the Network control panel. In the long run, you should try to identify these manually configured devices and transition them to use DHCP service.

However, you may want to use manual configuration for well-known server and network infrastructure devices, and, of course, you must use manual configuration for any devices that don't have an implementation of DHCP available. To summarize, consider manual configuration for:

  • Mission-critical protocol servers (for example, DNS, DHCP, Simple Mail Transfer Protocol [SMTP], the Web, and so on)

  • Mainframe and multi-user computers (for example, IBM 3090s, VAX/Alpha clusters, and high-end UNIX workstations)

  • Any server hosting an application that is accessed via the computer's IP address (for example, some database applications)

  • Router and switch interfaces

  • Any computer that cannot operate as a DHCP (or BOOTP) client

Problems with Manual Configuration

Clearly, manual IP address configuration has some problems; otherwise, the BOOTP and DHCP protocols wouldn't have been developed. Any manually configured host ceases to function correctly if:

  • The user changes the IP address or TCP/IP configuration parameters.

  • The computer is moved to a different subnet.

  • The computer remains stationary, but the subnet is renumbered.

  • The TCP/IP parameters (such as DNS server addresses or router addresses) are changed, without a corresponding change to the computer's TCP/IP configuration.

NOTE

You can also handle one of the major drawbacks of static allocation through the DHCPINFORM message, which enables a host with a manually configured IP address to request other configuration parameters, such as router addresses, DNS servers, and printer servers.

16.1.2. Reclamation of Manually Assigned IP Addresses

In many networks, thousands of legacy manual IP address allocations are scattered through the address range. Because most networks employ manual methods of tracking these static allocations, you cannot ensure that a computer is still using its manually assigned IP address. Some manually configured computers may still be in use, some may have been converted to use DHCP, and some may no longer be in use.

One frequently used method of reclaiming manually assigned IP addresses is to write a script that periodically pings IP addresses that are suspected of being in use by manually configured hosts. You can run this script until you are confident that the devices using any of the addresses you are trying to check are turned on. If your program receives a reply to its ping messages, that IP address is still in use. However, this method is not totally reliable, and it can possibly lead to address conflicts.

When it is determined that a manually assigned IP address is no longer in use, it can be reclaimed. You can add the IP address to the DHCP pool of addresses, and you can delete the DNS resource records.

16.1.3. Strategies for Supporting BOOTP Devices

As mentioned previously, BOOTP is the predecessor of the DHCP protocol. Your intranet will likely include computers and devices that can use BOOTP and not DHCP to acquire their network configuration. For example, … older printers support BOOTP but not DHCP, such as Macintosh computers using MacTCP instead of OpenTransport, and many older diskless workstations may be capable of using BOOTP but not DHCP. This doesn't represent a significant problem because BOOTP and DHCP can inter-operate on the same network.

Prior to any discussion of how to deal with legacy BOOTP devices, it's worth noting that you can configure DHCP servers to respond to BOOTP messages so that your DHCP server provides both DHCP and BOOTP service. That said, you can handle legacy BOOTP devices in one of several ways:

  • Eliminate all BOOTP devices and only use DHCP.

  • Provide static IP address assignments for BOOTP clients.

  • Automatically allocate permanent IP addresses for BOOTP clients.

  • Keep BOOTP and DHCP services separate.

Elimination of All BOOTP Devices

One method of dealing with legacy BOOTP devices is to turn them all into DHCP devices. Where possible, this is an attractive method of dealing with the issue because it leaves the administrator with only onemethodof allocating addresses automatically/dynamically. Many computers and network devices that use BOOTP can also use DHCP. In some cases (as with many network printers), converting devices from BOOTP to DHCP is as simple as selecting DHCP from a network configuration screen. Firmware upgrades for BOOTP-only devices may be available that support DHCP. A large number of different kinds of BOOTP devices exist, so it is difficult to provide details on the method of converting any specific device from BOOTP to DHCP.

A certain amount of work is involved in identifying all BOOTP clients on your network and upgrading them to use the DHCP protocol instead. Likewise, if you decide to continue supporting BOOTP, you must do some extra work because the BOOTP protocol does not provide for any way of automating the maintenance of BOOTP address assignments. Even if you choose to have the DHCP server automatically allocate these addresses, you cannot have it reclaim them when they are no longer in use. Whether you choose to convert from BOOTP to DHCP depends on which of these two options is likely to require the least amount of work.

If you can convert all your BOOTP devices to DHCP, you still must consider whether those devices require the same IP address every time they start up. If this is not a requirement, you can enable the DHCP server to serve the next available address to the devices, and your dynamic allocation takes care of all your legacy BOOTP devices (because they are not DHCP devices).

If all your legacy BOOTP devices must continue using the same IP address they always had, it probably isn't worth the work required to convert the clients from BOOTP to DHCP. This is discussed in the next section.

Static Address Assignments for BOOTP Clients

If your legacy BOOTP devices require the same IP address they got from a BOOTP server, you can choose to use static allocation or automatic allocation. If you choose static allocation, you must add an entry for each BOOTP device. To continue providing BOOTP clients with their old IP addresses, you must take the following steps:

  • Configure your DHCP server to respond to BOOTP requests.

  • Examine your BOOTP server configuration file, and for each entry in the file, create a static address assignment on your DHCP server that includes the hardware address and the IP address to be assigned to that client.

  • Make sure that all the appropriate DHCP options are configured in the DHCP server to correspond with all the options specified in the bootptab file.

  • Turn off your old BOOTP server.

  • Restart your BOOTP devices.

NOTE

Often, entries in your bootptab file are very regular. You may find it easiest to simply write a PERL or shell script to convert your bootptab file into the format your DHCP server expects. Unfortunately, you cannot do this for the Microsoft DHCP server, but it does work with the ISC DHCP server and with DHCP servers provided by quite a few other vendors.

You might also want to ask whether your vendor already has scripts that you can use. The bootptab file format varies between different versions of the BOOTP daemon, and from site to site. One site's script probably doesn't work for another site without changes, but it can still be useful to start from somebody else's conversion script instead of writing a completely new one.

Many BOOTP devices perform a second-stage startup process, in which they download a file from a Trivial File Transfer Protocol (TFTP) or network file system (NFS) server—for example, a startup image or a configuration file. The BOOTP protocol requires that the IP address of the server from which to load this file is included in the siaddr and sname fields of the BOOTP packet. However, some newer BOOTP clients actually use the DHCP tftp-server-name and bootfile-name options. You must make sure that you configure the DHCP server to send the second-stage start-up information to the BOOTP client in the same way that the BOOTP server does.

You can tell very quickly whether you have this issue. Scan (or grep) through your bootptab file, looking for the tag symbol sa=value. This is the tag for the TFTP server address. If this tag is present, you should configure the DHCP server with the tftp-server-name option instead of telling it to use the sname field in the BOOTP header.

NOTE

Static IP address assignments do not enable BOOTP clients to roam across multiple subnets, unless you create multiple reservations for a given hardware address. Also, if a network is renumbered, the address assigned to a particular BOOTP client might be incorrect for the network segment to which that client is connected. So, this method is effective for enabling BOOTP clients to continue receiving their old IP addresses, but it provides little of the benefit of DHCP.

Automatic IP Address Assignment for BOOTP Clients

Rather than completely eliminating BOOTP, or providing and maintaining static address allocations for all BOOTP clients, you can also have some DHCP servers automatically allocate IP addresses to BOOTP clients. This form of BOOTP service is sometimes called dynamic BOOTP.

This method is attractive because it enables you to serve BOOTP clients from the same pool of addresses as dynamic clients. It doesn't require you to create DHCP reservations; yet it isn't adversely affected if you do. This configuration has the added advantage of enabling BOOTP clients to function correctly even if they roam across multiple subnets, or if the network is renumbered. The disadvantage is that the DHCP server must permanently reserve any IP addresses it assigns to BOOTP clients because BOOTP does not include any mechanism for automatically recovering IP addresses that are no longer in use.

NOTE

The ISC DHCP server provides some ways of working around the BOOTP protocol's inability to provide for automatic IP address reclamation. The first of these is the dynamic-bootp-lease-length parameter, which you can set to some length shorter than infinity. To use this parameter safely, you must be able to assume that any BOOTP client on your network is always powered off and back on again at least once during the specified interval. For example, if your site is an office that operates Monday through Friday, and all network devices in the office are always powered off on weekends, you can set this interval to one week and be sure that no BOOTP device retains its address for that long.

The ISC server also provides the dynamic-bootp-lease-cutoff parameter. This parameter specifies a specific date when all BOOTP leases end. You can use this, for example, in a college dormitory environment, where it is known that all students leave the dorm on a certain day. If the cutoff is set to the next day, all IP addresses assigned to students in the dorm using BOOTP are reclaimed at once. Of course, it's important to reset this cutoff when it expires!

Separate DHCP and BOOTP Servers

Another alternative is to leave your BOOTP server unchanged, and provide service for all BOOTP devices through the BOOTP server. BOOTP and DHCP servers can inter-operate on the same network or subnet, however you must run the two servers on separate computers. Therefore, if you choose this option, you must manage two servers. In such a scenario, making changes to network topology is complicated because you must update both servers. If the number of legacy BOOTP devices is extremely large, or if for other reasons you do not want to move your BOOTP service to your DHCP server, you can leave the BOOTP server intact and configure the DHCP server not to respond to BOOTP requests.

Whichever approach you select, be very careful not to allocate leases to a DHCP dynamic pool if they are either in use by a BOOTP server, or reserved for a BOOTP device in some other scope. This can result in a duplicate IP address assignment.

   

< Back Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.