Droms R. The DHCP handbook

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

OMAPI

To put an ISC DHCP server into the

PARTNER-DOWN state, you need to use the OMAPI

protocol. The OMAPI protocol is a control protocol that allows you to connect to the

ISC DHCP server and change its state without stopping it.

To use OMAPI, you need to have

omapi-port and omapi-key statements in your

dhcpd.conf file. The omapi-port statement tells the server to listen for OMAPI

connections on the port you specify, and the

omapi-key statement tells the server

what authentication key to use to authenticate your OMAPI connection. A sample

configuration is shown in Example 18.8.

Example 18.8

key EXKEY {

algorithm HMAC-MD5.SIG-ALG.REG.INT;

secret pRP5FapFoJ95JEL06sv4PQ==;

};

omapi-port 520;

omapi-key EXKEY;

When the DHCP server is configured to use OMAPI, you can connect to it by using

an OMAPI client and issue commands to the server. There is an interactive OMAPI

client called

omshell that is ideal for simple server changes like this. To use omshell

to put the “example” failover peer on the primary server into the PARTNER-DOWN state,

assuming the configuration shown in Examples 18.4, 18.5, and 18.7, you use the

commands shown in Example 18.9.

Example 18.9

% omshell

> server 10.0.1.1

> key EXKEY pRP5FapFoJ95JEL06sv4PQ==

> port 520

> connect

obj: <null>

> new failover-state

obj: failover-state

> set name = “example”

obj: failover-state

> open

obj: failover-state

…

> set local-state = 1

CHAPTER 18 Configuring a Failover Server316

022 3273 CH18 10/3/02 5:00 PM Page 316

obj: failover-state

…

> update

obj: failover-state

…

> ^D

Getting Out of the PARTNER-DOWN State

If you have been operating a single server in the

PARTNER-DOWN state and are ready to

bring back the other server, you don’t need to do anything special except make sure

the two servers can communicate. When you start the server that was down, it auto-

matically connects to the running server, synchronizes with it, waits for the MCLT to

expire, and begins serving clients.

You must be careful not to restart the failed server when the server that is in the

PARTNER-DOWN state is not running. If the failed server starts up and is unable to

contact the other server, it assumes that things are as they were when it went down,

and it begins allocating IP addresses that the other server has reclaimed. So as a rule,

you should have an administrative policy that before you put a server into the

PARTNER-DOWN state, you make sure that its peer won’t come back up unexpectedly.

Loss of the Database on One Server

The failover protocol provides a completely transparent mechanism for restoring a

lost database. All you have to do is generate a configuration file for the server that

lost its database and start it up. It automatically connects to the other server and

downloads that server’s entire database.

Lost Leases

With the ISC server, it’s sometimes possible to get into a state where, because of soft-

ware bugs, particularly in older versions, the lease databases are not in sync. This sort

of problem can persist even after you upgrade to a newer version of the server

without the bugs. The usual symptom of this is log messages such as “Peer holds all

free leases” and “No free leases,” when you know there are plenty of available IP

addresses. Another symptom of a lost lease is that a client always gets leases that are

the MCLT long, even though the servers are operating in the

NORMAL state. The

message “Invalid binding state transition: active to expired” might indicate that the

server still has this bug. It might also indicate some other problem.

There is no one fix to this problem. The easiest thing to try, particularly if you know

that your current software is working, is to force the two servers to resynchronize.

You can do this by using the OMAPI method shown in Example 18.9, but you put

Operating a Failover Pair 317

Example 18.9 Continued

022 3273 CH18 10/3/02 5:00 PM Page 317

both servers into state number 6 (RECOVER) instead of putting one server into state

number 1 (

PARTNER-DOWN). This forces the servers to resynchronize, and it can help.

If this doesn’t work, a more drastic solution is to stop one of the servers and delete

its lease database. Then restart it, and it recovers its database from its peer. At this

point the two databases are definitely in sync. The problem is that by doing this, you

lose all information about any out-of-sync leases. This can result in service interrup-

tions for the clients that held those leases.

Pool Balancing

When the ISC DHCP server tries to balance its pools, it prints a message like this:

pool 80c3ea92 10.0.1.0 total 100 free 25 backup 5 lts 10

This indicates that a pool in the shared network named 10.0.1.0 has a total of 100 IP

addresses. Of those, 25 are in the

FREE state and 5 are in the BACKUP state. The lts

value (leases to send) means that the primary server concludes that it needs to move

10 of its free IP addresses into the

BACKUP state for the secondary server to allocate.

If the lts is less than 10% of the number of free IP addresses, the server does not

attempt to balance the pools. This prevents the servers from rebalancing every time

they allocate an IP address, which would be quite inefficient.

Pool balancing is a rough operation—it doesn’t always get the pools exactly in

balance. You can run into serious problems when there are a very small number of

available IP addresses; for example, one server will have all the free leases and the

other will have none, so when a new client comes along, it might not be able to get

an IP address.

Leases

Failover changes the way leases are allocated. The first lease allocated to a client

when it doesn’t already have a valid lease is always for the MCLT, not the lease time

the client asked for. Also, the DHCP server writes the lease to the database once

before it sends the

DHCPACK message to the client and then a second time when it

gets the

BNDACK message back from the failover peer. So every time a lease on an IP

address is renewed, it is written to the lease database twice.

Issues Specific to the ISC DHCP Failover Implementation

In addition to the operational issues described so far in this chapter, there are also

some limitations to the ISC server that affect failover.

CHAPTER 18 Configuring a Failover Server318

022 3273 CH18 10/3/02 5:00 PM Page 318

The Version of ISC Software to Use

The ISC DHCP failover implementation is the only publicly available implementa-

tion of the current failover protocol at the time of this writing. The ISC implementa-

tion is still quite new, and the failover protocol specification itself is not even an

official standard of the IETF. If you want to use failover, you should be very careful

to run the latest version of the DHCP server. If there are two versions and one is less

recent, it is probably more buggy than the other.

Ad hoc DNS Updates

The ISC DHCP server provides two ways of doing DNS updates on behalf of a client.

The first is the ad hoc method, which is now deprecated, and the second is the

interim method. If you have an ISC DHCP server that uses the ad hoc update

method and you want to use failover, you must first switch to the interim method

and then switch to failover—you can’t do it in one step.

To switch from ad hoc to interim, simply edit your

dhcpd.conf file and change the

ddns-update-style statement to say interim instead of ad-hoc. Then wait until the

maximum lease interval has passed, and all the hosts whose DNS registration was

done using ad hoc updates either expire or are converted to the interim style.

Known Problems with the ISC DHCP Server and Failover

In some cases, features of the ISC DHCP server that were invented before failover do

not too work well if you are using failover. There are also some limitations to the ISC

failover implementation—portions of the protocol that were not a high priority

when failover was being developed and therefore have not yet been implemented.

The following is a list of these issues at the time of this writing:

• The ISC DHCP server provides a feature called lease limits that limits the

number of leases that can be assigned to members of any specific class. When

you are running failover, the two servers calculate this independently. Because

of this, the lease limit feature doesn’t work and mustn’t be used with failover.

• The ISC DHCP server does not provide a way to disable load-balancing.

• The ISC DHCP server does not implement the safe period specified in the

failover protocol.

• Information that is added to the lease database by using OMAPI is not shared

between servers. This means that, for example, if you use OMAPI to add

host

statements to the server, you have to add the same host statement to both

servers with OMAPI—failover does not keep this information synchronized.

Issues Specific to the ISC DHCP Failover Implementation 319

022 3273 CH18 10/3/02 5:00 PM Page 319

• The ISC DHCP server does not keep track of static leases. As a result, the

failover-style reserved IP addresses are not supported. This isn’t a serious

problem in most cases; you can simply define any host declarations in the

master configuration file that is shared between the two servers, and both

servers respond when a client with a reserved address tries to get its IP address.

Summary

The failover protocol provides a way to provide redundant DHCP service from two

cooperating DHCP servers. Failover servers can be configured in three different rela-

tionships, depending on your needs. If you already have two DHCP servers, you can

merge their configurations into a single failover pair configuration. If you have only

one DHCP server, you can add a second to get a failover pair. If you don’t have

DHCP service, you can easily set up a new DHCP failover pair.

Failover servers must use a common configuration file, with a small amount of

customization for each server, to describe the failover relationship.

A one-time synchronization process occurs when you first start up failover, and after

you have completed this process, the failover protocol becomes operational.

The ISC DHCP server includes an implementation of the failover protocol. If you

want to use this implementation, you should make sure to run the most recent

version. Some ISC DHCP features do not work with failover.

CHAPTER 18 Configuring a Failover Server320

022 3273 CH18 10/3/02 5:00 PM Page 320

IN THIS CHAPTER

• Network Device

Configuration and Address

Assignment Strategies

• Configuring Lease Lengths

• Monitoring the Server

Tuning a DHCP Service

The preceding chapters in Part III, “DHCP Servers and

Clients,” describe the mechanics of installing and configur-

ing a DHCP server. This chapter describes how to tune a

DHCP implementation to best meet the needs for DHCP

service at your site, and it explains some of the trade-offs

you need to consider. It also describes some ways to

monitor your DHCP server’s activities so that you can

assess and monitor how well it is functioning.

Network Device Configuration and

Address Assignment Strategies

Although DHCP may be the best choice for configuring

many of the computers at your site, you might still need to

(or choose to) configure some computers in other ways. In

practice, some legacy devices that don’t have implementa-

tions of DHCP require manual configuration of IP

addresses and DNS hostnames. Other legacy devices that

use BOOTP for configuration, such as printers and some

network hubs, may require manual configuration or provi-

sion of BOOTP service. Servers such as the DHCP server,

the DNS servers, Web servers, mail servers, and so on

should (or must) be configured manually to avoid depen-

dence on other services (such as DHCP) and to improve

reliability. In addition, network infrastructure devices such

as routers must be configured manually.

Manual Configuration

Computers that are assigned IP addresses through manual

configuration can interact with a DHCP service in two

ways. First, the DHCP service must be configured so that it

doesn’t try to assign IP addresses to DHCP clients that

have already been assigned to other computers through

023 3273 CH19 10/3/02 4:58 PM Page 321

CHAPTER 19 Tuning a DHCP Service322

manual configuration. The DHCP administrator has to keep track of the manually

configured IP addresses and configure the ranges of available address in the DHCP

servers to exclude those IP addresses.

Second, computers or other devices that are manually configured with IP addresses

can use DHCP to obtain other configuration information. A network device can use

the

DHCPINFORM message to request other configuration information such as default

routes, DNS servers, and printer servers from a DHCP server without being assigned

an IP address. Use of the

DHCPINFORM message allows a network administrator to

reconfigure automatically servers and other devices that have been manually config-

ured with IP addresses.

Strategies for Supporting BOOTP Devices

As mentioned previously, BOOTP is the predecessor of the DHCP protocol. A

network may include legacy devices such as older printers that can only use BOOTP.

Because DHCP and BOOTP are related to each other, it is possible to use both on the

same network. RFC 1534 explains the interoperation and coexistence of BOOTP and

DHCP in detail.

You can manage legacy BOOTP devices in several ways:

• Eliminate all BOOTP devices and use only 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 BOOTP devices is to convert them so that they use

DHCP. Where possible, this is an attractive method of dealing with the issue because

it leaves the administrator with only one method of allocating addresses automati-

cally/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.

Many 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 a 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 BOOTP does not

provide for any way of automating the maintenance of BOOTP address assignments.

023 3273 CH19 10/3/02 4:58 PM Page 322

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 options is likely

to require the least amount of work.

Static Address Assignments for BOOTP Clients

If you choose to provide BOOTP service with a DHCP server, you need to move the

information about the deployed BOOTP clients to the DHCP server. Some BOOTP

clients cannot transition to a new IP address and must continue to use the same IP

address that was originally assigned by the BOOTP server. To continue providing all

your BOOTP clients with their old IP addresses, you must use static address assign-

ment by following these steps:

1. Configure the DHCP server to respond to BOOTP requests.

2. Examine the BOOTP server configuration file, and for each entry in the file,

create a static address assignment on the DHCP server that includes the hard-

ware address and the IP address to be assigned to that client.

3. 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.

4. Turn off the old BOOTP server.

5. Restart the BOOTP devices.

NOTE

Often, entries in a BOOTP server configuration file are very regular. You might find it easiest

to simply write a Perl or shell script to convert a bootptab file into the format that the 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 down-

load a file from a TFTP server or an NFS server—for example, a startup image or a

configuration file. BOOTP requires that the IP address of the server from which to

load this file be included in the

siaddr

and

sname

fields of the BOOTP packet.

However, some newer BOOTP clients actually use the DHCP

tftp-server-name

and

Network Device Configuration and Address Assignment Strategies 323

023 3273 CH19 10/3/02 4:58 PM Page 323

bootfile-name

options. You must make sure that you configure the DHCP server to

send the second-stage startup 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 through the BOOTP

server configuration 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 assignment entries for a given link-layer 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. Therefore, static IP address assignment 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 have some DHCP servers automat-

ically allocate IP addresses to BOOTP clients. This form of BOOTP service is some-

times called dynamic BOOTP.

Dynamic BOOTP 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 of

dynamic BOOTP 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 BOOTP’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 the 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.

CHAPTER 19 Tuning a DHCP Service324

023 3273 CH19 10/3/02 4:58 PM Page 324

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 parameter, 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 strategy for supporting BOOTP devices is to leave the BOOTP server

unchanged and provide service for all BOOTP devices through the BOOTP server.

BOOTP and DHCP servers can interoperate on the same network or subnet; however,

you must run the two servers on separate computers. Therefore, if you use this strat-

egy, you must manage two servers. In such a scenario, making changes to the

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 the BOOTP service to the DHCP server, you can leave the BOOTP

server intact and configure the DHCP server not to respond to BOOTP requests.

NOTE

Whichever approach you select, be very careful not to assign IP addresses 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.

Configuring Lease Lengths

DHCP lease length is a topic of heated debate among network administrators. Some

networks run DHCP lease times of one year; some use 30 seconds. Generally speak-

ing, the right lease time depends on the network’s characteristics and performance

requirements. However, you should consider a few relevant issues that, when

weighed accordingly, can influence your decision about your optimal DHCP lease

time.

Examples of Long and Short Lease Times

This section illustrates the pros and cons of long and short lease times by providing

an example that shows two hypothetical networks that use extremely long and short

DHCP leases: one with a lease duration of one year and the other with a lease dura-

tion of one minute.

Configuring Lease Lengths 325

023 3273 CH19 10/3/02 4:58 PM Page 325