Droms R. The DHCP handbook

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

NOTE

In this chapter, it is assumed that the servers are unable to coordinate and thus must be

configured to operate without knowledge of one another’s actions. Although the failover

protocol solves many of the problems described in this chapter much more elegantly than the

solutions presented here, it is still under development. At the time of this writing, two

vendors are known to have deployed implementations of a previous version of the failover

protocol, and the protocol draft was undergoing a major revision. By the time this book is

published, some preliminary implementations of the new failover protocol may be available.

Dynamic Address Allocation

In order for two servers to perform dynamic (or automatic) address allocation on the

same network, they must allocate addresses from separate address pools. If both

servers are configured with the same address pools, over time they will indepen-

dently give the same addresses to different clients. DHCP is a fairly robust protocol

in the face of this; you may not notice that anything is wrong, but you might see an

abundance of abandoned leases. Unfortunately, over time this means that both

servers will perform less and less well and may eventually stop working entirely. The

solution is to give each server a separate, nonoverlapping address pool on each

network segment. For example, you might configure Server 1 with a range that

includes addresses 10.127.42.5 through 10.127.42.130 and Server 2 with a range that

includes addresses 10.127.42.131 through 10.127.42.253. When a client tries to start

up for the first time, both servers try to offer addresses. Server 1 might offer

10.127.42.5, and Server 2 might offer 10.127.42.131. The client chooses one of these

addresses, requests it from the appropriate server, and starts using the lease. As long

as the client needs the lease and the server from which it got the lease is working,

the client operates normally. Because the two servers are assigning addresses from

different ranges, there is no chance that each server will assign the same address to

different clients.

If the server fails, the client continues using the address it was assigned until its lease

expires. During that period, it tries from time to time to renew its lease. As long as

the server comes back before the lease expires, the client continues to operate

normally. If the server isn’t reachable by the time the lease expires, the client

acquires a new lease from the other server, assuming that the server is running.

Static Address Allocation

When assigning addresses to clients statically, as described in Chapter 16, “Client

Identification and Fixed-Address Allocation,” both servers should be configured with

the same list of static addresses for clients.

CHAPTER 17 Setting Up a Reliable DHCP Service296

021 3273 CH17 10/3/02 5:05 PM Page 296

If both servers are running when a client requests an address, both offer it the same

address. The client selects one of the two servers, requests the address from that

server, and contacts that server for a lease extension. If the server the client initially

selected is unable to respond, the client extends its lease through the other server.

In a sense, when you set up two DHCP servers to provide static address assignment

for the same network, you set up communicating DHCP servers. The servers commu-

nicate through whatever mechanism you choose to use to provide them with identi-

cal static address configurations. The effectiveness of this strategy depends on the

degree to which the server configurations remain synchronized.

Hybrid Allocation Models

As mentioned in Chapters 15 and 16, you can set up a DHCP server that performs

static address allocation for some clients on some networks and dynamic allocation

for other clients on other networks. If you do this, you can still set up redundant

DHCP service.

For static address assignments, you simply maintain duplicate DHCP configurations

on both servers. For dynamic assignments, you maintain separate address allocation

pools for each server. Clients with statically assigned addresses see no apparent inter-

ruption in service when a server goes down for longer than their lease duration.

Clients with dynamically assigned addresses see an interruption if the server from

which they got their addresses goes down for longer than their lease duration.

NOTE

When you run a redundant DHCP server configuration that mixes static and dynamic address-

ing, it is vitally important that the static address assignments for each server be consistent. If

both servers are running and one server has a static address assignment for a particular client

and the other has no such assignment, when that client tries to start up, each server offers it a

different address. This could mean that the server that knows it has a valid static address

would send a DHCPNAK message whenever the client sends a DHCPREQUEST message for the

nonstatic address offered by the other server.

Also, if the client gets the dynamically assigned address from Server 1, and then Server 1’s

static address mapping is updated to include a mapping for that client, the client is forced to

reinitialize with a new IP address, resulting in an interruption of network service for the user.

To avoid this, you should shut down both servers when installing a new server configuration,

install the new configuration on both servers, and then start up both servers. As long as you

follow this sequence, both servers can run at the same time with consistent states. Of course,

this also means that both servers will be down at the same time, but as long as the startup

time on both servers is reasonably short, this shouldn’t be a problem.

Setting Up a Secondary DHCP Server 297

021 3273 CH17 10/3/02 5:05 PM Page 297

Problems with Setting Up Redundant Servers

Setting up redundant servers that don’t speak an interserver protocol is not a good

solution to the problem of providing redundant service. If you can find a server that

provides a reliable interserver protocol, such as the IETF DHCP failover protocol, it is

best to use that protocol because it solves all the problems described in this section.

Address Consistency Rule Violations

When two servers are set up in a redundant configuration with dynamic address

allocation, clients may not be assigned the same IP address every time they start up.

This can happen even in situations in which no outage exists; if a client relinquishes

its address on shutdown or simply doesn’t remember its previous address across

restarts, each time it comes up, both DHCP servers compete to give it an IP address.

This means that clients do not have consistent addresses across restarts. Because

DHCP tries to ensure that the client always gets the same IP address, a redundant

DHCP server setup with dynamic allocation behaves differently than a single server

with dynamic allocation—and this might be a problem for some users.

Loss of Address While in Use

Using multiple servers with separate address ranges doesn’t solve the problem of a

DHCP client losing its IP address when the lease expires. If a client is assigned an

address from one server and is unable to renew the lease with that server before it

expires, the other server assign it a different IP address. Any network connections

that were in use when the lease expired are broken, probably without warning. For

this reason, it is a good idea to use longer leases—even with a redundant server

configuration—as an additional strategy for improving reliability.

Dynamic Allocation Pool Starvation

If you set up two DHCP servers to perform dynamic address allocation on a particu-

lar network segment, you must assign each server a part of the address pool. In the

event of an outage, it might be necessary to support the entire network segment

with only the addresses assigned to the server that has not failed. This means you

may have to allocate twice as many addresses as are actually needed. If addresses are

in short supply, you might not have enough IP addresses to adequately serve that

network segment.

Duplicate Responses from Redundant Servers

Whenever a client transmits a

DHCPDISCOVER

message on a network with redundant

DHCP servers—whether the servers use static or dynamic address allocation—both

servers respond. This means the client generally must choose between two offers,

CHAPTER 17 Setting Up a Reliable DHCP Service298

021 3273 CH17 10/3/02 5:05 PM Page 298

one from each server. This creates extra network traffic and causes both servers,

rather than just one server, to do work. It also means that you really cannot have a

primary and a secondary server; the two servers compete as equals.

When a DHCP client sends a request, the

secs

field in the DHCP packet is initialized

to the number of seconds that have elapsed since the client first started sending the

request. One possible way to set up a primary server and a secondary server is to

have the secondary server respond only if the

secs

field is larger than some predeter-

mined amount. Because the

secs

field is zero for the first request a client sends, the

secondary server does not respond to it, but it does respond if the client sends a

second request. You can configure version 3.0 or later of the ISC DHCP server to do

this, as shown in Example 17.1.

Example 17.1

min-secs 15;

In Example 17.1, the server is configured not to respond unless the

secs

field in the

client’s request has a value of at least 15. Whether all clients use the

secs

field

correctly is unknown. This is something to be aware of: If redundant DHCP service is

set up in this way, clients that don’t correctly set the

secs

field are simply ignored by

the secondary server.

Summary

The major causes of DHCP server failure are power failures, hardware failures, and

network problems. To improve reliability, you can use long lease times and set up

secondary DHCP servers. These tactics work best when you combine them, although

you can also use them separately. Long lease times by themselves are a very easy

solution, but they don’t solve all the reliability problems that can come up; in partic-

ular, they work poorly for mobile clients and for clients that are powered on during

DHCP service outage.

You can improve reliability by having more than one DHCP server serve a given

network segment. This is advantageous because it means that even clients that lose

their addresses while one DHCP server is unavailable can still use the network.

Redundant DHCP service is not an ideal solution; the DHCP failover protocol is a

solution that better handles the problem of setting up redundant service.

Summary 299

021 3273 CH17 10/3/02 5:05 PM Page 299

021 3273 CH17 10/3/02 5:05 PM Page 300

IN THIS CHAPTER

•Types of Failover Relationships

• Setting Up Failover Service for

the First Time

• Configuring the ISC DHCP

Server to Do Failover

• Operating a Failover Pair

•Issues Specific to the ISC

DHCP Failover

Implementation

Configuring a Failover

Server

This chapter discusses failover in practical terms. In order

to get the maximum benefit from this chapter, you should

also read Chapter 10, “Failover Protocol Operation,” which

describes the details of the failover protocol and how it

operates.

This chapter does not describe how to set up a really

complicated failover configuration—just the basic configu-

ration. This should be enough to provide you with the

building blocks necessary to produce a more complicated

configuration if you need one.

This chapter describes the three basic kinds of failover pair

configurations and the uses of each. It then describes the

process of adding support for failover in your environ-

ment, based on the kind of DHCP service you presently

have. It then walks you through the process of configuring

a pair of ISC DHCP servers that were not using failover so

that they do use it. This chapter then describes some of the

issues that can come up if you operate a failover pair and

how to deal with them. Finally, it describes issues that are

specific to the ISC DHCP server.

Types of Failover Relationships

There are three main categories of failover relationships

that you might want to set up:

• Cooperating partners

• Failover

• Backing store

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

Remember that failover servers always appear in pairs. These three categories of rela-

tionships define how each member of a failover pair behaves. Which type of failover

relationship you choose depends on what you are trying to accomplish. The type of

failover relationship you choose determines some aspects of how you configure your

server, as shown in Table 18.1.

TABLE 18.1 Parameters That Determine the Failover Server Relationship Type

Role Listens Responds Free Address Balance

Cooperating Partners Relationship

Primary Yes Yes 50%

Secondary Yes Yes 50%

Primary/Backup Relationship

Primary Yes Yes 50%

Backup Yes Sometimes 50%

Backing Store Relationship

Active Yes Yes 100%

Backing store No Never 0%

The Cooperating Partners Relationship

In a cooperating partners relationship, the two failover servers are both acting as

DHCP servers for a common set of network segments, all the time. Both DHCP

servers receive every client message. The servers should be using load-balancing, and

the load should be shared equally between the two failover partners.

A cooperating partners relationship works well in environments where you want

both redundancy and load-balancing; if one server fails, you want DHCP service to

continue, but while both servers are running, you want them to share the DHCP

service load.

The Failover Relationship

A primary/backup relationship provides redundancy but not load-balancing. In a

primary/backup relationship, one of the two servers (not necessarily the server whose

failover role is “primary”) is the primary server, and the other server acts as a backup.

Both servers hear all DHCP requests for the network segments that they serve, but

normally only the primary responds.

The backup server responds if a client indicates that it has been unable to contact

the primary server for more than a predetermined amount of time. The backup

server also responds if it is out of contact with the primary server.

CHAPTER 18 Configuring a Failover Server302

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

When the backup server fails, the primary server has to follow the same failover rules

that apply for cooperating partners—it can’t allocate leases that are in the

BACKUP

state. When the primary server fails, the backup server takes over service, but it also

has to follow the failover rules, and it can’t allocate leases that are in the

FREE state.

It’s impossible to know which server will fail, so even though one server is doing all

the allocations, it’s still important to keep the pools roughly in balance—that is,

there should be roughly the same number of backup leases as free leases. Because the

primary server takes backup leases from the secondary server as its pools become

depleted, the pools tend to stay in balance as long as the servers are communicating.

The Backing Store Relationship

When two servers are in a backing store relationship, one server, the active server,

uses the backing store server to back up its database. The other server, the backing

store server, never serves any clients, nor does it hear requests from clients. In this

configuration there is no failover-style redundancy; if the active server fails, DHCP

service stops until the active server comes back.

The advantage of this type of failover configuration is that it allows you to deploy a

dataless DHCP server—that is, a DHCP server that runs in a device that has no

nonvolatile storage for its lease database. This server uses the backing store server to

save its lease database.

Normally, the active server behaves just like a regular DHCP server, but it maintains

a failover relationship with the backing store server. When the backing store server

goes down, the active server continues to operate in communications-interrupted

mode.

When the active server is powered down or rebooted, it loses its lease database. So

when it starts back up, it contacts the backing store server and rereads its configura-

tion database. It can then proceed to allocate IP addresses as usual.

According to the failover protocol, if the backing store server is unreachable when

the active server comes up, the active server can’t serve DHCP requests until it

regains contact with the backing store server. This is a major weakness in this kind of

failover relationship. One solution to the problem is to allow the server to extend

leases by the minimum client lead time (MCLT) when clients request it but not to

allocate any new leases.

Types of Failover Relationships 303

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

Setting Up Failover Service for the First Time

There are three possible scenarios for a new failover installation:

•You currently have no DHCP service.

•You have one DHCP server providing all service.

•You have two DHCP servers providing service out of disjoint pools.

The failover protocol does not provide a mechanism for synchronizing server config-

urations—all it provides is a way to share IP address allocation pools. So in all three

cases, you must create a master DHCP configuration that applies to both members of

the failover pair.

If you have no DHCP server, you can simply create a DHCP configuration as

described in Chapters 15, “Configuring a DHCP Server,” and 16, “Client

Identification and Fixed-Address Allocation.” You might want to test the configura-

tion with a single DHCP server before you proceed to setting up a failover pair.

If you currently have a single DHCP server, the master configuration is that DHCP

server’s configuration. If you have two DHCP servers serving addresses out of disjoint

allocation pools, then you must combine the two server configurations to produce a

single configuration.

After you have created the master DHCP configuration, you must create an individ-

ual configuration for each of the two servers, based on the master configuration. The

only difference between the two configurations is the failover configuration informa-

tion—everything else should be the same.

A DHCP configuration file for a DHCP server that does dynamic allocation must

either explicitly or implicitly declare one or more address allocation pools. If you

want to share these pools using failover, you must mark each pool that you want to

share because it is possible for the DHCP server to share some pools and not share

others.

If you already have DHCP service operating without failover, whether it is a single

DHCP server or a pair of servers with disjoint allocation pools, you do not need to

do anything with the lease files—just leave them as they are. The failover protocol

assumes that the failover pair as a whole is completely in control of the lease data-

base. The lease database on an individual server does not reflect the complete state

of the lease database. Therefore, it is very important not to change the lease database

on an individual server yourself.

CHAPTER 18 Configuring a Failover Server304

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

NOTE

It is very common for someone setting up failover for the first time to provide failover configu-

ration information for both servers but not configure the allocation pools to be shared.

However, if someone did do this, both servers would behave as if they were in a failover rela-

tionship, in the sense that they would log messages about connecting and about state

changes, but they would not actually share their address allocation pools. Because they would

both be configured with the same address allocation pool, this would be disastrous: Both

servers would allocate IP addresses out of the same pools without cooperating.

Configuring the ISC DHCP Server to Do Failover

To illustrate the failover configuration process, let’s use the ISC DHCP server as an

example. The ISC DHCP server currently supports only the cooperating partners and

primary/backup relationships. This example describes the cooperating partners rela-

tionship, but it also describes in a general way how the configuration would need to

be changed in order to implement a different relationship.

If you do not currently have DHCP running at your site, we will assume that you

have already written a master DHCP configuration by using the information in

Chapters 14, “The ISC DHCP Server,” 15, “Configuring a DHCP Server,” and 16,

“Client Identification and Fixed-Address Allocation.”

Merging Configuration Files

If you have two DHCP servers serving IP addresses out of disjoint pools, you must

merge the DHCP configurations. In this example, we refer to the two disjoint

servers as Server A and Server B. The configuration file for Server A is shown in

Example 18.1.

Example 18.1

option domain-name “example.org”;

option domain-name-servers 10.0.1.17;

subnet 10.0.1.0 netmask 255.255.255.0 {

option routers 10.0.1.1;

pool {

deny dynamic bootp clients;

range 10.0.1.10 10.0.1.109;

}

subnet 10.0.2.0 netmask 255.255.255.0 {

option routers 10.0.2.1;

Configuring the ISC DHCP Server to Do Failover 305

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