Droms R. The DHCP handbook

Подождите немного. Документ загружается.

we would de-allocate the IP addresses previously assigned to those devices and allo-

cate new addresses to the devices on the network segment (or segments) available in

the new location.

Moving or Adding Network Services

As organizations within DEC Palo Alto grew, it was not uncommon for us to add

new facilities such as printers, name servers, and Network Time Protocol (NTP)

servers to the network and then manually configure the address for each client.

Because we did not always have time to modify the configurations of existing func-

tioning clients, we disseminated information about new network services when new

machines were installed or when users complained that, for example, they couldn’t

access the printers closest to their cubicles.

Renumbering the Network

As the organization grew, we restructured the network. On one occasion, the entire

DEC corporate network number changed from Class B (128.45.0.0) to Class A

(16.0.0.0) addressing. This necessitated changing the IP address of every network

device on the Palo Alto campus—more than 1,000 computers. Because we did not

have an automatic configuration mechanism, network administrators had to renum-

ber the machines, a process that consisted of walking to every machine and manu-

ally changing its IP address. Because people worked odd hours at DEC Palo Alto, we

often forced people out of the buildings as we updated the machines. We then

waited for users to report problems. This indicated which machines had not been

renumbered correctly.

Reclaiming Disused IP Addresses

Machines for which we allocated IP addresses eventually failed, moved out of our

jurisdiction, or were reassigned to different users and reinstalled, at which time the

machines lost their old identities. When we were aware of these transitions, we easily

updated our records and reclaimed the IP addresses belonging to such machines.

However, if transfers occurred without our knowledge, we were not aware that these

IP addresses were no longer in use.

In such cases, we had no reliable way to determine whether an IP address was no

longer in use. Although we often used the

ping command (that is, the ICMP echo

request/reply protocol) to determine whether an address was still in use.

Unfortunately, if there was no response to such a test, this indicated only that the

address was not in use at that moment. The address could have been configured in a

device that was powered off. We eventually found ways of handling this problem.

First, we tried to locate the person who owned the device for which the IP address

was allocated. If we couldn’t find the owner of the device, we sent a

ping to a

CHAPTER 1 An Introduction to DHCP6

003 3273 CH01 10/3/02 5:01 PM Page 6

suspect IP address periodically for about a month, and if we did not receive a

response during that period, we reclaimed the address. Occasionally, someone would

power up a device that had been disused for a few months, and the new device to

which the old device’s IP address was assigned would start behaving erratically.

A First Attempt at Automating Device Configuration

In 1985 Bill Croft and John Gilmore devised a protocol called Bootstrap Protocol

(BOOTP). The idea behind BOOTP was to automate network device configuration.

This could eliminate the need for the system administrator to manually configure

each network device.

BOOTP requires that the administrator create a table that contains a list of BOOTP

clients, their IP addresses, and other configuration parameters they might need.

When a BOOTP client needs to configure itself, it broadcasts a request, which the

BOOTP server receives. The BOOTP server looks up the client in the table, finds its

parameters, and sends these parameters to the client.

BOOTP works fairly well, except that it only configures the device; the network

administrator must perform the remaining tasks. Various sites experimented with

dynamic address allocation using BOOTP, but they were not very successful because

the protocol was limited in what it could do; it was a simple database lookup proto-

col, and it provided no means for reclaiming addresses.

DHCP is a direct descendent of BOOTP. DHCP packets and BOOTP packets look very

much alike, and DHCP and BOOTP clients and servers can take advantage of the

same network infrastructure. Both protocols accomplish the task of automatically

configuring network devices; the difference is that DHCP can solve other problems.

The Benefits of DHCP

The tedious and time-consuming method of assigning IP addresses described in the

section “Configuring Devices on a Network,” earlier in this chapter, was once

commonplace. However, thanks to DHCP, a network administrator no longer has to

manually configure each new network device before it can be used on the network.

DHCP has enabled the use of laptops that roam between networks, by eliminating

the need for manual reconfiguration when a laptop changes its access point. The use

of DHCP is especially important with wireless LANs, in which mobile devices can

move between access points without even reconnecting a cable.

With the proliferation of DHCP, network administrators can also choose the level of

control they want to exercise with regard to address allocation; they can still manu-

ally assign IP addresses to DHCP clients, or they can have the DHCP server automati-

cally allocate IP addresses for clients. They can also decide whether clients must be

registered before they are assigned IP addresses.

The Benefits of DHCP 7

003 3273 CH01 10/3/02 5:01 PM Page 7

Availability of DHCP Clients

The widespread availability of DHCP clients is due in large part to Microsoft

Corporation’s early decision to include a DHCP client in the Windows 95 distribu-

tion. Since then, most major desktop operating system vendors have followed suit,

and new Apple Macintosh, Windows 2000, and Windows XP systems come pre-

configured to use DHCP when IP networking is enabled. Most free, Unix-like operat-

ing systems also come with DHCP clients that can be configured fairly easily, and the

Internet Software Consortium (ISC) provides an open-source implementation of

DHCP that includes a server, a client, and a relay agent. The ISC implementation of

DHCP runs on many commercial Unix implementations, as well as on all free, Unix-

like operating systems.

DHCP on Large Networks

Using DHCP on a large network offers clear benefits. When you must allocate and

then configure a great number of devices, a protocol that completely automates

these processes saves a tremendous amount of time. Even if you still manually allo-

cate IP addresses for each client, DHCP’s ability to automatically reclaim IP addresses

from DHCP clients saves time and hassle in the long run.

Mobility

One big advantage of DHCP is that it allows for mobile devices (that is, devices that

are plugged in at different network locations at varying times). For example, at the

University of Oregon, where DHCP is used, network connectivity is provided in the

dorms, the library, teachers’ offices, and classrooms. When students do homework in

their dorms, they plug their laptop computers into Ethernet jacks. When these

students need to go to the library to work with reference material, they unplug their

laptops from the network, put them to sleep, take them to the library, and plug

them back in. The laptops automatically acquire new IP addresses and continue

using the network.

Teachers can work on presentations on their laptop computers in their offices but

store the presentations on a file server. A teacher can then use the same laptop that

is plugged into the network hookup in a classroom to access the presentation from

the file server, without reconfiguring the machine.

Visiting faculty members and salespeople with DHCP-ready laptop computers can

plug those computers into the network and immediately use the network, without

requiring any intervention from a system administrator. University of Oregon faculty

members who go to conferences can bring their laptops, which are DHCP-ready, plug

them into the terminal room network at the conference, and immediately use the

network there.

CHAPTER 1 An Introduction to DHCP8

003 3273 CH01 10/3/02 5:01 PM Page 8

DHCP on Small Networks

It can be convenient to set up a DHCP server on a very small network. Even though

few clients are involved in such cases, the advantages of not having to manually

configure each client’s IP stack can be significant. Configuring a simple DHCP server

for a single subnet shouldn’t take much more time than configuring the IP stack on

a new machine. You must configure the IP stack on the DHCP server manually, of

course, but the time you save configuring the second machine attached to the local

network makes up for the time you spent configuring the DHCP server. DHCP saves

time on every machine configured from the third onward.

Of course, if you are an experienced network administrator, you will probably

already know how to set up a DHCP server; if you are doing this for the first time,

you might need to add five or six machines to the network before you realize any

time savings. But in any case, you will have learned a valuable skill.

Another advantage of setting up DHCP on small networks is enhanced mobility. If a

University of Oregon professor has a laptop computer configured to use DHCP and

has a network at home, it is convenient to run DHCP on the home network. If that

professor does not have DHCP service on his or her home network, then the profes-

sor must manually reconfigure the laptop computer every time he or she moves it

from the home to the office or back again.

Assigning IP Addresses Using DHCP

A major difference between the ways in which the DHCP server and a network

administrator allocate addresses is that DHCP enforces a limit on how long an IP

address can be used. This seemingly subtle change makes many of the problems

experienced with IP address allocation on the network at DEC Palo Alto much easier

to solve. The rest of the protocol is analogous to what a network administrator does:

A DHCP client (in the DHCP protocol, this refers to the device itself, not to the user)

requests an IP address. The server, using its knowledge of the network and a list of IP

addresses and client identities it maintains, provides one. Chapter 8, “DHCP Message

Exchanges,” and Chapter 15, “Configuring a DHCP Server,” discuss this process in

detail.

DHCP Server as Agent

The DHCP server acts as an agent in performing address allocation. Like a network

administrator, the DHCP server must have a clear, unambiguous understanding of

the network’s layout in order to assign addresses, and it must know the network’s

address allocation policy.

Assigning IP Addresses Using DHCP 9

003 3273 CH01 10/3/02 5:01 PM Page 9

NOTE

One of the most common errors new DHCP administrators make is thinking of the DHCP

server as just another database lookup engine and, therefore, providing the DHCP server with

only the information the administrator thinks it needs to know. Remember that it is just as

important for the DHCP server to know what not to do as what to do.

Address Leasing

As explained earlier, DHCP servers must operate automatically, and are unable to

exercise judgment or ask what happened to old devices. Further differentiating

between DHCP and manual address allocation is the lease. Rather than simply assign-

ing each client an IP address to keep until the client is done with it, the DHCP server

assigns the client an IP address with a lease; the client is allowed to use this IP

address only for the duration of that lease. When the lease expires, the client is

forced to stop using that IP address. To prevent a lease from expiring, which essen-

tially shuts down all network access for the client, the client must renew its lease on

its IP address before it expires. Most DHCP clients renew their leases many times.

Address Reclamation with DHCP

By constraining clients from using IP addresses after their leases expire, and by

providing a mechanism for clients to continue renewing their leases as long as they

are powered on and connected to the network, DHCP enables the reliable reclama-

tion of disused IP addresses. If a device is left powered off for an extended period, it

must contact the DHCP server for its IP address when it is powered on again. If the

device’s former address is not available, it is given a new address. This prevents most

address allocation conflicts.

Renumbering with DHCP

The lease mechanism also facilitates renumbering. If every device on a network uses

DHCP, then renumbering is a simple matter of reconfiguring the server’s idea of what

the network looks like. It is possible to renumber so transparently that users who do

not pay close attention to their TCP/IP configuration information are unaware that

the network has been renumbered.

Describing Network Services with DHCP

In addition to providing a means for distributing IP addresses, DHCP enables config-

uration information to be distributed in the form of DHCP options, including the

following:

CHAPTER 1 An Introduction to DHCP10

003 3273 CH01 10/3/02 5:01 PM Page 10

• The default router addresses

• The domain name servers’ addresses

•The name of a bootfile to load (for devices that boot over the network)

• The name of the root file system and swap server (for diskless clients)

Chapter 9, “DHCP Options,” provides a complete list of these options. Chapter 11,

“DHCP–DNS Interaction,” describes how to use them, and Chapter 21, “DHCP

Clients,” discusses options some common clients use.

Moving or Adding Network Services with DHCP

When a network service is added or needs to be moved, it is possible to take advan-

tage of the regular lease renewal process to propagate new information. The adminis-

trator simply updates the DHCP server configuration as appropriate. If a service’s IP

address changes, the configuration is updated to reflect this. If there is a new printer,

that printer is added to the list of printers that are available on the subnet (or

subnets) serving the area near the printer. As DHCP clients renew their leases, they

automatically acquire this new information and begin using it.

One problem with updating information about services through the DHCP server is

that the DHCP client, not the DHCP server, decides when to renew its lease. The new

configuration information does not reach the DHCP client until the client renews its

lease. If the DHCP client takes a long time to renew its lease, it does not get its new

configuration information for a long time.

A new DHCP message, called

DHCPFORCERENEW, allows DHCP servers to notify DHCP

clients that new configuration information is available. When a DHCP client receives

DHCPFORCERENEW message from a DHCP server, the client contacts the server imme-

diately. The server can then pass a new IP address and other configuration informa-

tion to the client.

Perceived Problems of DHCP

Despite DHCP’s benefits, many network administrators resist deploying DHCP

because of various perceived problems, which are discussed in the following sections.

Excess Broadcast Traffic

Some network administrators believe that DHCP generates a large amount of broad-

cast traffic. Although DHCP does use broadcasts, the amount of broadcasting is rela-

tively minimal. In the worst case, the first two DHCP messages that a DHCP client

sends must be broadcast; depending on the networking capabilities of the operating

Perceived Problems of DHCP 11

003 3273 CH01 10/3/02 5:01 PM Page 11

systems on the client and server, the server might also need to broadcast its

responses to the client. When combined, this creates a total of four broadcast

packets.

In most cases, however, the client need only send one broadcast packet on startup;

most clients do not require a broadcast response. Most servers can also respond

without broadcasting. Thus, in the most typical DHCP startup case, only a single

packet is broadcast—not four. After a client configures its network connection and

either as long as that connection remains valid or until the client machine is

restarted, all communication with the server is unicast. Chapter 7, “Transmitting

DHCP Messages,” discusses these issues in detail.

Another common misconception is that DHCP traffic is broadcast across the entire

enterprise network. In fact, the broadcast traffic generated through the use of DHCP

is typically limited to the network segment to which the DHCP client is connected.

Traffic across the rest of the network between the DHCP client and server is usually

sent directly to the server by using IP unicast.

In comparison, consider Address Resolution Protocol (ARP), which all IP broadcast

networks use. When one device needs to communicate with another device that is

on the same network segment, it must have the link-layer address of the second

device. Because it initially knows only the other device’s IP address, it must send an

ARP broadcast to obtain the second device’s link-layer address. After the device has

that link-layer address, it periodically verifies that it still has the correct address by

broadcasting another ARP request.

Some ARP implementations verify the link-layer address as frequently as every two

minutes. The ARP response is also broadcast, so any pair of devices on a network

segment that are in contact with one another using TCP/IP broadcast, on average,

one ARP message every minute. Computers tend to remain powered on for longer

than one minute at a time; usually, computers are powered on all day. In this case,

ARP generates as many as 180 broadcast packets for every packet DHCP generates.

Therefore, at four broadcast messages, DHCP is a comparatively insignificant

producer of broadcast traffic.

Server Load

Another common assumption is that because a DHCP server is most likely serving all

the DHCP clients at a site, it is difficult for a DHCP server to function at a large site.

Fortunately, DHCP is comparatively undemanding. A name server for a large site

might need a fairly fast machine with a good deal of memory. However, a DHCP

server for the same site can usually run quite well on an old piece of junk found in

the closet. It is very common to hear of people running the ISC DHCP server on an

old Intel 486 machine running Linux, serving several thousand DHCP clients. Many

sites serve on the order of 10,000 clients with Linux-based platforms. Although the

CHAPTER 1 An Introduction to DHCP12

003 3273 CH01 10/3/02 5:01 PM Page 12

ISC DHCP server keeps its entire client database in memory, a 10,000-client network

consumes, at most, 20MB of virtual memory.

DEALING WITH SPURIOUS DHCP TRAFFIC

One problem DHCP servers must deal with is broken clients that send too many requests. At

Pacific Bell, a single DHCP server running on a Tandem mainframe serves more than 50,000

DHCP clients. Some of the old network hardware the company installed at some of its sites

can get into a state in which it tries to obtain an IP address once every few seconds. On bad

days, this means the DHCP server receives about 5 requests every second, with occasional

sustained peaks of 50 packets per second that last for an hour or more. The DHCP server

looks at all requests and decides what to do with them, even though these requests are not

legitimate. Nonetheless, it handles this load without difficulty.

DHCP Reliability

One problem with DHCP is that if the DHCP client and the DHCP server are unable

to communicate with each other for some reason, the DHCP client’s lease eventually

expires, and it must stop using the network. This commonly occurs if the DHCP

server goes down for longer than the duration of a lease. This can also happen if a

central DHCP server is configured to serve addresses on a wide area network (WAN)

and one of the links in this WAN fails for a long time. In practice, temporary outages

of DHCP service have little or no effect on clients because a client tries to extend the

lease on its address well before the lease expires and continues to use its old address

while attempting to contact the DHCP server.

SPEAKING FROM EXPERIENCE

At DEC Palo Alto, we actually considered deploying DHCP very early on. We ran a fairly

homogenous environment—almost every machine was a DEC station of some sort, running

Ultrix. Therefore, we could have fairly easily configured all machines to run a DHCP client on

startup. However, we were afraid that if we did this, we would experience reliability problems

because of the lease mechanism, and users would complain.

Based on subsequent experiences, it is clear that this fear was unfounded. Several strategies

exist for avoiding this problem, and we found that these strategies work. Clients can renew

their leases, and users do not call to complain about losing network connectivity.

If you are deploying DHCP on a WAN and don’t have an extremely reliable, redun-

dant network setup, it is best to locate DHCP servers at each site rather than run one

central DHCP server for the entire WAN. Some sites do run a central DHCP server for

their entire WAN, but they avoid trouble by having multiple redundant links to each

site so that if one link goes down, an alternate path to the DHCP server is available.

Perceived Problems of DHCP 13

003 3273 CH01 10/3/02 5:01 PM Page 13

DHCP does not currently allow a backup DHCP server to serve addresses from the

same range as a primary server. Several strategies exist for working around this limi-

tation:

•You can set leases to be long enough so that they do not expire before you fix a

failed server.

•You can set up secondary servers that do not serve the same sets of addresses.

• If you conduct static address allocation, you can set up completely redundant

DHCP servers.

Chapter 15, “Configuring a DHCP Server,” discusses these strategies in detail.

The Internet Engineering Task Force (IETF) Dynamic Host Configuration Working

Group (DHCWG) has developed a new protocol—DHCP failover—that allows DHCP

servers to operate in primary/secondary pairs, allocating IP addresses out of a shared

pool of addresses. The protocol allows the primary and secondary to share the DHCP

service load equally. It also allows the secondary to be configured to act as a backup

in case the primary server fails.

When Not to Use DHCP

Unlike manual network configuration, the automated DHCP process depends on the

presence of a DHCP server. If you use DHCP to configure a device on a network, and

if that device cannot talk to the DHCP server, it eventually stops using the network.

For this reason, using DHCP to configure network servers is not recommended. If the

DHCP server fails and, as a result, the machine on which you are running your

corporate name service suddenly loses its ability to communicate on the network, or

your corporate SMTP (e-mail) gateway goes down, you will quickly forget how

convenient DHCP is.

Some managed hubs and other network components obtain the IP address of their

management port from a vendor-supplied custom BOOTP server. It might not be a

good idea in some cases to substitute a general-purpose DHCP server for the manu-

facturer’s controller, depending on how faithfully the manufacturer adhered to the

protocol and whether you have sufficient documentation to configure the server.

Also, as with other network infrastructure, it might be more reliable to configure the

devices manually.

Address Allocation Policies

One of the primary goals for DHCP was to design a protocol that provides a mecha-

nism through which a network administrator can implement any desired administra-

tive policy. The network administrator can manually configure the DHCP server with

CHAPTER 1 An Introduction to DHCP14

003 3273 CH01 10/3/02 5:01 PM Page 14

an IP address for each machine that is connected to the network. The administrator

can also simply provide a range of addresses for the DHCP server to use and allow

the DHCP server to allocate these addresses to clients automatically. It is also feasible

to implement a scheme that combines both of these methods.

Static Allocation

With static (or fixed) allocation, the DHCP server receives a list of identification infor-

mation for DHCP clients. These identifiers specifically and uniquely identify each

client. Chapter 16, “Client Identification and Fixed-Address Allocation,” discusses

the types of identifiers that can be used.

For each identifier, the administrator gives the DHCP server an IP address to assign

to that client. If the client is mobile, the administrator can assign an address for each

client on each network segment to which the client is connected. A client cannot

configure itself on a network segment on which the administrator has not assigned it

an IP address.

Dynamic Allocation

With dynamic allocation, the DHCP server receives a range of IP addresses for each

network segment on which DHCP clients are expected to be configured. When a

DHCP client asks for an IP address, the DHCP server finds a free address on that

network segment and supplies it to the client.

Automatic Allocation

The DHCP specification talks about another method of address allocation, called

automatic allocation, in which the DHCP server allocates IP addresses as it does in

dynamic allocation, but the addresses are allocated permanently. The DHCP servers

described in this book do not actually implement automatic allocation as a specific

third alternative. However, you can approximate this scenario by simply using very

long lease durations.

Hybrid Allocation Policies

A variety of hybrid address allocation policies are possible with DHCP. With one

common policy, the administrator registers a list of known client identifiers for

which DHCP service is allowed, but the administrator does not assign fixed IP

addresses to those clients. Those clients can then acquire IP addresses dynamically

wherever they are connected. This allows the administrator to limit the use of DHCP

to registered clients, but it saves the administrator the trouble of updating the DHCP

server every time a client moves. With the growing popularity of portable computers,

this can be a major advantage.

Address Allocation Policies 15

003 3273 CH01 10/3/02 5:01 PM Page 15