|
|
|
Tuning Your DHCP Service
|
| |
 |
|
|
|
|
 |
|
From:
The DHCP Handbook
Author: Ralph Droms; Ted Lemon
Publisher: MTP
More Information
|
|
|
|
|
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. 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. 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
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. 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. 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.
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. 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. 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! 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. |
| |
|
|
|
|
|
|
|
Breaking News
|
|
One of the primary architects of OpenCable, Michael
Adams, explains the key concepts of this initiative in his book
OpenCable Architecture.
|
|
|
|
|
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.
|
|
|
|
|
