Droms R. The DHCP handbook
Подождите немного. Документ загружается.
Automatic Allocation
In some cases, you might want the benefits of static address allocation without the
costs; that is, you might want clients to have permanent, fixed IP addresses, but you
do not want to configure them into the DHCP server. DHCP defines an address allo-
cation strategy that enables automatic allocation of static addresses. RFC 2131 refers
to this mode as automatic allocation.
When a client first sends a
DHCPDISCOVER message on a network segment, the server
allocates it a lease from an address range, just as in dynamic allocation. However,
instead of offering a limited lease, the server offers an unlimited lease. DHCP speci-
fies that a lease interval of 4294967295 (FFFFFFFF) must be treated as having an infi-
nite duration—that is, the lease never expires.
Until the version 3.0 release, the ISC DHCP server did not explicitly support this
mode. However, in version 3.0, the
infinite keyword was added, allowing leases to
be specified as unlimited. The DHCP server does not expire an unlimited lease,
which means that an unlimited lease has the same effect as a static IP address
allocation.
Access Control
In addition to identifying DHCP clients and assigning fixed addresses to them, you
might want to identify clients for other reasons. For instance, some sites want to
control access to leases that the DHCP server supplies. Even though these sites
support dynamic IP address allocation, they do not want to allocate IP addresses to
clients that the network administrators do not know. Some sites might want to
group clients in some way—for example, by allocating IP addresses for known clients
on a particular network segment on one subnet and allocating IP addresses for
unknown clients on the same network segment from a different subnet. Chapter 20,
“Conditional Behavior,” explains this second scenario in detail.
If you want to set up a DHCP server that provides IP addresses only to clients it
knows, you need to write
host declarations for all known hosts, but do not specify
fixed addresses for those hosts. Then configure the DHCP server not to provide IP
addresses to unknown clients. Example 16.10 shows a simple server configuration
file that limits access to the DHCP server to clients for which host entries exist, and
it allocates addresses dynamically. This works whether the client stays in the same
location or moves from one network segment to another.
Example 16.10
option domain-name “acl.example.com”;
subnet 10.227.94.0 netmask 255.255.255.0 {
pool {
deny unknown clients;
CHAPTER 16 Client Identification and Fixed-Address Allocation286
020 3273 CH16 10/3/02 4:58 PM Page 286
range 10.227.94.2 10.227.94.253;
}
option routers 10.227.94.254;
option domain-name-servers 10.227.94.1;
option broadcast-address 10.227.94.255;
}
host blaznorf {
hardware ethernet 00:2b:5c:e9:ad:11;
}
host gzarond {
hardware ethernet 00:e9:ac:22:08:ee;
}
In Example 16.10, the deny unknown clients statement within the pool declaration
prevents the DHCP server from allocating addresses from that pool to clients it does
not recognize. The
pool declaration provides a set of addresses to allocate and the
subnet declaration provides some options to send. The two
host declarations define
the two DHCP clients with which the server is willing to communicate. Most DHCP
server configurations of this type define more than two hosts, of course.
The ISC DHCP server also enables you to deny access to specific clients. You may
want to provide general access to clients without a registration process, but you
might not want to assign addresses to some specific DHCP clients. Consider the GSI
internal network, which we discussed in the section “Static Allocation.” Suppose
there is a networked printer connected to the server subnet that the network admin-
istrator does not want to assign an IP address; she wants it to be accessible only
through AppleTalk (EtherTalk). She can set up a host declaration for that printer (as
shown in Example 16.11), and it will not be assigned an IP address.
Example 16.11
host laserwriter {
option dhcp-client-identifier “treekiller”;
ignore booting;
}
Unfortunately, using DHCP, you cannot get the printer to stop requesting an address.
However, you can prevent the server from giving it one. Example 16.11 uses the
ignore statement. This prevents the DHCP server from recording its refusal to
provide an address to the client in the system log. If a client is requesting addresses
frequently, this can be very helpful. If you want to see a log message when the client
is refused, you can use the
deny statement instead of the ignore statement.
Access Control 287
Example 16.10 Continued
020 3273 CH16 10/3/02 4:58 PM Page 287
NOTE
Access control is not synonymous with authentication. As mentioned previously, some DHCP
clients can be reconfigured with different client identifiers. It is also possible with almost any
network adapter to supply a link-layer address other than the one assigned to that adapter.
This means you can set up access control based on the DHCP client identifier or the client’s
link-layer address, but you still must trust that the client is telling the truth—and a malicious
client can easily fool the DHCP server.
The DHCP authentication mechanism, described in Chapter 7, “Transmitting DHCP
Messages,” provides a way in which you can actually authenticate the client’s identification.
By using this mechanism, you can ensure that malicious clients do not masquerade as legiti-
mate clients. However, even with authentication and access control, you still cannot prevent
unauthorized users from simply choosing an address they know is not in use at the moment
and using it.
Summary
The DHCP server must uniquely identify DHCP clients, and it does so by using the
dhcp-client-identifier option, the client’s link-layer address, or a nonstandard
mechanism. If the mechanism does not guarantee the uniqueness of the identifier,
conflicts can occur. DHCP does not provide a way to deal with these conflicts; it
simply mandates that clients’ identifications must be unique.
Static address allocation allows you to configure DHCP servers with user-supplied
mappings between IP addresses and client identification. You can also configure
servers to automatically make permanent assignments between IP addresses and
client identification, using automatic address allocation. You can also configure
servers to perform a combination of static and dynamic address allocation.
In addition to using the client’s identification as a key to its IP address, you can also
configure DHCP servers to enable or deny access to leases by using the client’s iden-
tification; however, without an authentication mechanism, this method is not
considered a reliable way to control access to a network.
CHAPTER 16 Client Identification and Fixed-Address Allocation288
020 3273 CH16 10/3/02 4:58 PM Page 288
IN THIS CHAPTER
• Determining Your Level of
DHCP Service Reliability
• Specific Failures in DHCP
Service
•Improving Reliability by Using
Long Leases
• Setting Up a Secondary
DHCP Server
•Problems with Setting Up
Redundant Servers
17
Setting Up a Reliable
DHCP Service
As discussed in Chapter 1, “An Introduction to DHCP,”
loss of DHCP service can be a major problem if you
depend on such service for automated management of IP
addresses and computer configurations. When DHCP
service is unavailable, new computers and computers that
move to new network segments may be unable to use
network services. Applications running on computers that
depend on network service are also disrupted.
This chapter discusses specific ways in which the DHCP
service might fail and presents solutions for those failure
modes. It also describes some general DHCP service imple-
mentations that provide additional reliability through
redundant DHCP servers.
Determining Your Level of DHCP Service
Reliability
Before you decide on an implementation strategy for
providing reliable DHCP service, it is appropriate to review
how a loss of DHCP service will affect you and to deter-
mine the appropriate level of reliability for your organiza-
tion and network infrastructure. The loss of DHCP service
has two major effects: DHCP clients are unable to obtain
new addresses, and they are unable to extend leases on
addresses that were previously assigned through DHCP.
The Effects of Loss of Service
In many circumstances, the loss of DHCP service does not
immediately affect most DHCP clients and network users
and, in fact, may be less disruptive in the short run than
the loss of DNS or network file services. DNS service is
021 3273 CH17 10/3/02 5:05 PM Page 289
CHAPTER 17 Setting Up a Reliable DHCP Service290
used with every new connection that requires resolution of a DNS name, so loss of
DNS service is immediately obvious to users. On the other hand, a DHCP client that
was assigned an address will continue to function normally and won’t attempt to
contact the DHCP server until half the duration of its lease expires. Even after it
begins to request an extension on its lease, the DHCP client will continue to use its
address. Only if the DHCP service is still unavailable when the lease actually expires
must the DHCP client stop using its address and terminate network connections.
DHCP clients that restart while DHCP service is unavailable simply continue to use
their previously assigned addresses until their leases expire. As long as a computer
isn’t moved to a new network segment, the computer can use its old address. The
loss of DHCP service has an effect only when a lease actually expires.
Of course, clients that require DHCP service cannot access the network until such
service is restored. If you administer a network to which laptop computers are
frequently connected and disconnected, or if clients that you support request a short
lease duration, many of your clients may be quickly affected by the loss of DHCP
service. And, unfortunately, this loss of service may cause DHCP clients to fail in
ways that your end users might not understand (and might not be patient about!).
Different DHCP clients react in different ways when they cannot contact a DHCP
server. In many cases, the user experiences long startup times while the DHCP client
attempts to contact the DHCP server, along with unexplained loss of network access.
NOTE
Recent DHCP clients from Microsoft and Apple have an additional feature that may cause
confusion when DHCP service is unavailable. If these clients cannot contact a DHCP server,
they choose an address from a range of addresses that are reserved for autoconfiguration.
Unfortunately, a computer that performs this autoconfiguration appears to be operating
normally, but in effect it is using an IP address that cannot be used to reach destination
computers that are not connected to its local network segment. The user has no indication of
network initialization failure, but it cannot access network services. A DHCP client that
performs autoconfiguration assigns itself an IP address on the 169.254.0.0/16 network. This
mechanism for autoconfiguration is currently documented as the Internet Draft
“Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network,” and it is available as
draft-ietf-dhc-ipv4-autoconfig-04.txt.
You must determine your own requirements for the reliability of your DHCP service
based on the ways in which your clients access your network, the length of the
leases you choose, and your tolerance for calls to your help desk. Although no single
solution exists that fits the needs of every network, the next section covers some
specific failure modes and suggests some solutions for those scenarios.
021 3273 CH17 10/3/02 5:05 PM Page 290
Specific Failures in DHCP Service
DHCP service can fail for quite a few reasons. The most obvious is that the computer
on which the DHCP server is running fails. Another obvious reason is that network
connectivity may be lost between the DHCP client and the DHCP server. Less
obvious are failures of relay agents and IP address starvation caused by buggy
clients, misconfigured servers, and denial-of-service attacks. Chapter 24, “Debugging
Problems with DHCP,” and the section “Authenticated DHCP Messages” in
Chapter 7, “Transmitting DHCP Messages,” discuss debugging incorrectly configured
servers and denial-of-service attacks.
Server Failures
The most common server failure is simply a power outage. This can result from a
power loss on the electrical circuit to which the server computer is connected or an
accident that causes the computer to power off or causes a sitewide power loss.
Server hardware failures can also cause interruption (or, in some cases, complete loss)
of service.
Limited Power Failure
In the event of a power failure that is limited to the server machine and a small
number of other machines, few of which are DHCP clients, there shouldn’t be much
of a problem. DHCP requires that the server record leases on some kind of stable
storage (for example, a hard-disk drive) before confirming them. As long as the
DHCP server vendor takes this requirement seriously, the server can simply be
restarted.
The easiest way to mitigate this problem is to make sure that the duration of the
power failure is short and to fix the problem quickly. The longer the server is
powered off, the more likely it is that a DHCP client without a valid lease will
attempt to acquire one. Such clients must wait until DHCP service is restored before
they can use the network. Because of the way lease renewal works, clients with exist-
ing leases usually have at lease one-half of the lease duration left at any given time,
so you can safely take a little less than one-half of the lease duration you assign to
restore service.
Major Power Outages
When power goes common off throughout a site, the recovery process is a bit differ-
ent than it is for failures in which only the DHCP server is affected. The problem in
this scenario is that all the DHCP clients powered off at the same time and will likely
power back on at the same time. If the DHCP server is not available when the
clients’ power is restored, the clients may not get addresses and will continue to
retry. This creates the following three problems:
Specific Failures in DHCP Service 291
021 3273 CH17 10/3/02 5:05 PM Page 291
• Until the clients are assigned addresses, they can’t use the network.
•While the clients try to obtain addresses, they might create a significant
amount of broadcast traffic on the network.
• All the DHCP messages from the clients are directed at the DHCP server. When
it comes back online, the server might experience an even higher load than if
it had been available when the first clients started requesting addresses.
For these reasons, it is recommended that you arrange for your DHCP server to be
available before the clients start requesting service. The easiest way to do this is to
power the computer that hosts your DHCP server by an uninterruptable power supply
(UPS). This is a lovely misnomer for a battery-backed-up power supply that,
although not actually uninterruptable, can be purchased in configurations that
enable your server computer to run for a reasonable period of time during a power
outage. If you can afford it, you might choose to provide backup power for your
network equipment, using a generator. If you have limited funds, however, you
might find it useful to run the DHCP server on a computer with very low power
consumption, to reduce the cost of the UPS you will need to keep it running for
whatever duration you plan.
NOTE
Laptops come with their own built-in UPSs. Although laptops are usually thought to be inap-
propriate for network services because they are often limited in processing and storage capac-
ity, they may be suitable for supplying DHCP service. In many installations, the number of
DHCP requests and the computing power required to process them are low enough that an
inexpensive, obsolete laptop is sufficient. If you leave the laptop plugged in all the time, you’ll
get a few hours of continuous service in the event of a power failure. If you power the
computer through UPS, it will take a very long time before the UPS’s battery dies.
Another solution is to put your DHCP server on a computer that starts up more
quickly than your DHCP clients. If you run DHCP on a machine that is running
Unix, BSD, or Linux, you might be able to arrange to start the DHCP server very
early in the startup process. If you do this, you must arrange for the disk partition
on which the server stores its files to be cleaned early in the startup process.
A very inexpensive solution to the problem of extremely high server load after a
power outage is to simply ask users to shut down their computers if power fails.
Obviously, not everybody will comply, but if you get even 50% compliance, you will
cut your power-on DHCP server load in half.
CHAPTER 17 Setting Up a Reliable DHCP Service292
021 3273 CH17 10/3/02 5:05 PM Page 292
Hardware Failures
Hardware failures are usually less common than power failures, but they have much
the same effect: A DHCP server stops running and doesn’t come back again until
some problem is corrected. In the worst case, a hardware failure may actually cause
the loss of the DHCP database, and it may be necessary to recover the database from
backups.
Planned Outages
You may choose to shut down the DHCP server to perform maintenance on it.
Unless the maintenance takes a long time, the potential problems that occur in such
cases are much the same as in a power outage. DHCP clients without leases are
unable to obtain them while the server is down. As long as the server is working
again before half of the lease duration is assigned to clients, however, clients with
valid leases when the server is down continue to operate normally.
At some point you might also choose to move your network’s DHCP service to a
different computer with a different IP address. The easiest way to make this infra-
structure change is to shut down the DHCP server on the old computer, copy all the
configuration files to the new computer, and restart the DHCP server on the new
computer. The new server then acquires all assigned addresses and lease information.
Computers using that DHCP service discover the new server when they restart or
extend existing leases.
Resource Starvation
For most sites, DHCP is a fairly low-demand service that is unlikely to place a heavy
load on a DHCP server machine. However, if the DHCP server machine also provides
other services, some of which are high demand, resource starvation caused by those
services can affect the DHCP server. Also, if a DHCP server is configured to support
enough clients, it is possible to create a load so large that the server is unable to keep
up (although this has not been observed in practice). Finally, having a great deal of
broadcast or multicast traffic on the network to which the DHCP server machine is
connected creates a load as well.
To avoid resource starvation caused by competing network services on the same host
computer, make sure not to overcommit the machine on which DHCP service is
running. If you envision providing high-demand NFS service, consider running the
DHCP server on a different computer. If you run a very large DNS service, run it on a
separate computer (this should be a problem for only very large sites).
To avoid resource starvation caused by a very high DHCP client load, you might
want to install DHCP service on multiple computers rather than on a single DHCP
server. Load-sharing can be provided between DHCP servers by using the failover
protocol described in the Chapter 18, “Failover Configuration.”
Specific Failures in DHCP Service 293
021 3273 CH17 10/3/02 5:05 PM Page 293
BROADCAST- AND MULTICAST-INDUCED LOADS
Broadcast and multicast traffic on a network can require computers connected to the network
to process every broadcast or multicast packet, even if the packet is of no interest. In general,
IP networks have relatively little broadcast traffic, but networks running other protocols in
addition to IP may see more broadcast traffic.
Multicast traffic is intended to reach only computers with clients that are interested in such
traffic. Unfortunately, the way multicast is implemented on some network cards requires that
the computer examine all multicast traffic, even if it is not of interest. If you run heavy multi-
cast traffic on the network to which your DHCP server is connected, make sure that the DHCP
server does not subscribe to this traffic. Also, be sure that the network adapter and the driver
for that adapter have efficient multicast filters and do not require the computer to perform
multicast filtering. Even if the network interface card correctly supports multicast, the pres-
ence of high-bandwidth multicast traffic on a broadcast network can consume enough band-
width that all other services experience a loss of reliability.
Network Infrastructure Failures
DHCP service requires a working network connection between the DHCP client and
the DHCP server. If the client and server are not connected to the same network
segment, a working DHCP relay agent must exist.
Failure of Network Hardware
If you experience a network outage that prevents computers holding valid IP
addresses from using the network, it probably doesn’t matter if DHCP service is
interrupted, nobody can use the network anyway. However, if you have local
services on a network that a DHCP user might access, you probably want the DHCP
service to be at least as reliable as the network to which that user is connected.
DHCP service should always be at least as reliable for any given DHCP user as the
network connection between that user and the services he or she uses.
The easiest way to meet this goal is to simply have a reliable DHCP server close to
the other services that any given DHCP user needs. For example, if you have several
LANs, each with its own servers and clients, a DHCP server should run on each LAN.
If you have several LANs with client machines and a single LAN in a machine room
with all the servers, you really need only a DHCP server in the machine room.
Another way to avoid losing DHCP service when other services are still available is
to increase the network’s reliability. Within a single site, you might want to set up
redundant power sources for routers, switches, and bridges. If you run a central
DHCP server to manage addresses across a large corporate network, serving sites
connected only by wide area links, you can establish redundant paths. This means
that any given site must be connected to the central DHCP site by more than one
wide area link. This is harder to accomplish than it sounds; it is quite common to
CHAPTER 17 Setting Up a Reliable DHCP Service294
021 3273 CH17 10/3/02 5:05 PM Page 294
buy WAN links from two different telephone companies, only to learn that both
links run through the same conduit between your site and some central distribution
point. One company might also be buying bandwidth from the other, in which case
both links could be running on the same optical fiber from one site to the other.
Even having each site connected to two or more different sites does not prevent a
single point of failure. Links may still run through the same conduit to a single
switching office before they are routed to two different sites. A catastrophic failure at
the switching site could take down your network and your DHCP service, which
means that your site wouldn’t be able to talk to the outside world or operate inde-
pendently while steps were being taken to restore connectivity.
Misconfigured or Failed Relay Agents
Most relay agents are embedded in dedicated routers and most likely will not fail
unless the routers themselves fail. Relay agents can be misconfigured; for example, if
the DHCP server receives a new IP address, relay agents that aren’t reconfigured with
the server’s new address will fail. When changing the DHCP server’s IP address, you
must update all relay agents as well.
Improving Reliability by Using Long Leases
As mentioned earlier, one way to maintain DHCP service across an outage is to
define leases so that they don’t expire during a normal outage. Configuring lease
durations is discussed in more detail in Chapter 19, “Tuning a DHCP Service.”
Setting Up a Secondary DHCP Server
Another way to maintain DHCP service in the presence of a partial power loss or
partial network outage is to set up two DHCP servers and enable them to both serve
the same network. It might be worthwhile to set up each server on a different
network. In this case, if you lose connectivity to or power for one network but not
the other network, DHCP service continues.
In order for two DHCP servers to provide DHCP service for the same network
segment (or segments), the servers must coordinate their behavior. Each server must
either know what the other is doing or be configured so that it can operate without
knowing what the other is doing. In order for each server to know what the other is
doing, you must use the DHCP failover protocol or a protocol that provides similar
functionality. Chapter 10, “Failover Protocol Operation,” and Chapter 18, “Failover
Configuation,” describe the operation and use of the DHCP failover protocol.
Setting Up a Secondary DHCP Server 295
021 3273 CH17 10/3/02 5:05 PM Page 295