Droms R. The DHCP handbook

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

UAP server

Option code: 71

Length: n

Data: list of IP addresses

The UAP server option lists addresses of User Authentication Protocol (UAP) servers

that are available to the client. The length must be a multiple of 4; if u UAP servers

are in the option, the length is

4u.

name service search order

Option code: 117

Length: n

Data: list of names services, in

the order in which they are to be

consulted

The Name Service Search Order option specifies the order in which name services

should be consulted when resolving hostnames and other information. This option

is defined in RFC 2937. Each name service is identified by its corresponding DHCP

option code, encoded as a 16-bit data value. The length must be a multiple of 2; if

there are s name services, the length is

2s.

subnet selection

Option code: 118

Length: 4

Data: IP address in the subnet from

which the client should be

assigned an IP address

The subnet selection option allows the client to explicitly identify the network

segment from which its address should be assigned. The DHCP server chooses an

address for the client based on the IP address supplied in the option. This option is

defined in RFC 3011.

When this option is present in a client’s message, the IP address in the option is used

in place of

giaddr for the purpose of allocating an IP address. The motivation for

this option is to allow DHCP proxy agents to acquire leases for clients on network

segments to which the proxy agent is not connected.

CHAPTER 9 DHCP Options156

012 3273 CH09 10/3/02 4:57 PM Page 156

authentication

Option code: 90

Length: n

Data: Protocol

Algorithm

Replay detection method

Replay detection

Authentication information

The authentication option carries information for authenticating the identity of

DHCP clients and servers and to ensure that the contents of the DHCP message have

not been altered in transit between clients and servers. The method for authentica-

tion of DHCP messages is described in the section “Authenticated DHCP Messages”

in Chapter 7. The

data field of the option is composed of several fields that define

the authentication protocol in use, the algorithm used to generate the MAC for this

message, the method and identifying information used for replay detection and the

authenticating MAC.

relay agent information

Option code: 82

Length: n

Data: relay agent information

The relay agent information option carries information about a DHCP client from

a DHCP relay agent to a DHCP server. This option is defined in RFC 3118.

The data area of the

relay agent information option is composed of one or more

suboptions. The suboptions are encoded in the same way as DHCP options; each

suboption includes a suboption code, a length, and the data.

The two suboptions defined in RFC 3046 are used by circuit access units, to pass

information about the circuit to which the DHCP client is attached.

AGENT CIRCUIT ID

Suboption code: 1

Length: n

Data: circuit ID

relay agent information

157

012 3273 CH09 10/3/02 4:57 PM Page 157

The data in the AGENT CIRCUIT ID suboption is the circuit access unit’s name for the

circuit to which the client is attached.

AGENT REMOTE ID

Suboption code: 2

Length: n

Data: remote circuit ID

The data in the AGENT REMOTE ID suboption is the remote name for the circuit to

which the client is attached.

Summary

The options section of a DHCP message carries values for most configuration para-

meters. These parameters are carried in options, whose formats are described in this

chapter. Each option carries a separate configuration parameter, as defined by the

option’s option code. The data formats for most of the options are defined in

RFC 2132. One group of options carries information that is specific to the operation

of DHCP, identifying the type of each DHCP message and the server to which the

message is directed. Other options carry information for the DHCP client, parameters

for the client’s TCP/IP software, and addresses of servers such as SMTP, NTP, and NIS

servers.

Options range in complexity from the

TCP Default TTL option to the

authentication option. The subnet mask option, the default routers option,

and the

DNS server option are the most commonly used options.

Some options, such as the Impress server option, refer to services that are no

longer available. Those options are still in the protocol specification, for backward

compatibility with earlier versions of DHCP and BOOTP.

The IETF continues to identify and define new options for DHCP. For example, the

relay agent information option, which was published in January 2001, allows

relay agents to add additional information about DHCP clients to messages

forwarded to servers. The initial definition of the

relay agent information option,

in RFC 3046, included two suboptions. Since the publication of RFC 3046, several

additional suboptions have been defined as new uses for information from relay

agents has been identified. Another new option, the

authentication option, which

was published in June 2001, allows clients and servers to confirm the source and

validate the contents of DHCP messages.

CHAPTER 9 DHCP Options158

012 3273 CH09 10/3/02 4:57 PM Page 158

IN THIS CHAPTER

• Failover Protocol Overview

• Lease Handling with Failover

• Failover Operational States

•Binding Update Conflicts

• Pool Rebalancing

• Complex Failover

Configurations

Failover Protocol

Operation

This chapter describes the DHCP failover protocol. DHCP

provides for dynamic IP address allocation. In order to

provide dynamic IP address allocation, a DHCP server must

maintain a database of IP addresses, and it must maintain

dynamic state for each IP address. Because of this, two

DHCP servers that want to allocate IP addresses from the

same pool must somehow cooperate to synchronize their

database of IP addresses. Otherwise, both servers can allo-

cate the same IP address to different DHCP clients. The

failover protocol provides a reliable way for two DHCP

servers to cooperate in allocating IP addresses out of the

same pool.

The failover protocol also provides for disaster recovery. As

soon as two failover peers have synchronized for the first

time, either peer can safely and completely recover from

the total loss of the other peer and all its data, even if the

two servers are not communicating at the time of the

failure.

NOTE

The failover protocol allows only two DHCP servers to share a

particular set of IP addresses; there is no provision for three or

more DHCP servers to share the same set of addresses.

This chapter is intended to give an overview of the failover

protocol so that a network administrator can understand

how it works and successfully operate a failover pair. If you

are interested in implementing the protocol, you will find

this to be a useful introduction, but it is by no means

sufficient by itself to act as a reference for implementers.

013 3273 CH10 10/3/02 4:59 PM Page 159

CHAPTER 10 Failover Protocol Operation160

To implement the failover protocol, you should consult the protocol specification. At

the time of this writing, the failover protocol was under review for publication as an

Internet Standard protocol. The specification is available as an Internet Draft titled

draft-ietf-dhc-failover-10.txt. You can obtain the latest revision of this document

from the DHC working group page on the IETF Web site (

www.ietf.org). When the

specification is accepted as a standard, it will be published as an RFC, which will be

listed on the DHC working group Web page at

http://www.ietf.org/html.charters/

dhc-charter.html

Failover Protocol Overview

The DHCP synchronization protocol is called the failover protocol because it was

initially intended to provide a way for one DHCP server to act as a primary server

and for a second DHCP server to act as a backup. In a very basic failover configura-

tion, the secondary server does not provide DHCP service when it is in contact with

the primary; it simply accepts updates from the primary. The secondary will start to

provide DHCP service only if it loses contact with the primary. Thus, DHCP service

will fail over from the primary to the secondary server. In a more advanced configu-

ration, both the primary and secondary servers provide service at the same time,

using a well-defined load-balancing algorithm to determine which server answers

which requests.

Synchronizing the databases between two DHCP servers is relatively easy, as long as

those two servers are able to communicate with each other. The central problem that

the failover protocol solves is providing correct, reliable DHCP service in the face of

a communication failure. There are several ways in which the primary and

secondary server might lose contact with each other:

• One of the two servers might fail due to a hardware or software problem.

• The local network to which one of the servers is attached might fail.

• The network somewhere between the two servers might fail.

In the case of any of these failures, one server can’t differentiate between a network

failure and a server failure and can’t tell if the other server might still be running.

So, when the two servers are not in contact, each functions as if the other server is

still running, adjusting its operation so that the DHCP service remains reliable, the

server databases are not updated with conflicting information, and the two servers

don’t assign the same IP address to different clients.

Database Synchronization

The failover protocol uses a technique called lazy updates, in which each server tries

to keep the other up-to-date but neither server is required to be entirely up-to-date

in order for the protocol to function reliably. The servers follow a set of rules that

013 3273 CH10 10/3/02 4:59 PM Page 160

prevents either server from behaving incorrectly in cases where updates have not yet

been completed. This allows either failover peer to assign an IP address to a DHCP

client before it has updated the other peer, which means that there is no perfor-

mance penalty to the DHCP protocol as a result of using the failover protocol.

Another technique that is often used in distributed databases is a three-phase commit

protocol, which allows both servers to present the same view of the database and

means that both DHCP servers can behave almost identically. The problem with this

technique is that it does not work when the servers are unable to communicate with

one another, which is precisely the problem the failover protocol must solve. Also, in

order for the three-phase commit protocol to work, the commit must be done before

the address is offered to the client. This imposes an unacceptable delay between the

time that a client requests a lease and the time the server confirms it.

Address Allocation Constraints

Lazy updates work by establishing a set of rules for how the DHCP servers allocate IP

addresses. If both DHCP servers follow the same rules, there is no chance that both

DHCP servers will ever allocate the same IP address to different DHCP clients, even if

the servers are not in communication with one another.

The rules involve three principles. The first is that the primary and secondary

failover servers divide the pool of free addresses that they have to serve on any given

network segment into free and backup addresses. Free addresses are available for the

primary server to allocate to clients. Backup addresses are available for the secondary

server to allocate to clients.

The second principle is that DHCP servers can allocate or extend a lease only to a

limited amount of time beyond the lease time known by its peer. This limited time is

called the maximum client lead time (MCLT)—the maximum time that one server’s

idea of the lease’s expiration time can lead the other’s. The MCLT is typically quite

short—certainly no more than an hour. The server can keep extending the lease by

MCLT indefinitely, but when this happens, the client has to renew frequently. In

order to allocate a longer lease to the client, the allocating server can cooperate with

its peer to establish an acknowledged potential lease expiry time. When this time has

been established, either peer can extend the client’s lease for up to that amount of

time plus the MCLT. Of course, because the acknowledged potential lease expiry time

is a fixed point in time and not a duration, as the MCLT is, whenever a server

extends a lease, it has to reestablish the acknowledged potential lease expiry time.

The third principle is that in normal operation, an address that has been assigned to

one client cannot be assigned to another client unless both DHCP servers agree that

the first client is no longer using it.

Failover Protocol Overview 161

013 3273 CH10 10/3/02 4:59 PM Page 161

Communication Between Failover Peers

Failover peers communicate with each other by using a persistent TCP connection.

The failover protocol is asynchronous—that is, either peer can send a message to the

other peer at any time, and there is no restriction placed on the order of the

responses.

Either failover peer can connect to the other; this allows a failover connection to be

established as soon as the second failover peer starts, whether the primary or the

secondary peer starts second. When a connection is established, whether the

secondary or the primary peer initiated the connection, the primary peer sends a

CONNECT message. This message contains identification and authentication informa-

tion, as well as some information about how the primary peer is configured—in

particular, what the MCLT is. If the secondary peer recognizes the primary peer and

is able to authenticate it, it sends a

CONNECTACK message. This message contains

authentication information that is similar to that in the

CONNECT message, as well as

configuration information from the secondary peer. After these two messages have

been successfully exchanged, the peers can communicate normally.

After the failover peers have established a connection, they tell each other what state

they are in, and if necessary, the two peers synchronize their IP address databases.

This process is described in more detail in the section “Operation in the

RECOVER

State,” later in this chapter. When the servers initially connect, after any synchro-

nization has been done, the two failover peers balance each address allocation pool,

making sure that each peer starts out with roughly the same number of IP addresses.

During normal communication, when the DHCP server receives a

DHCPREQUEST

message from a client, it responds with a DHCPACK and then sends a binding update

(

BNDUPD) message to its failover peer. When the peer receives the update, it puts the

update on a queue to be processed. After the update has been processed, the peer

sends a binding acknowledgement (

BNDACK)message in response. BNDUPD and

acknowledgement messages are also used during the synchronization process.

As each failover peer assigns IP addresses to clients, the pool of free addresses may

become unbalanced, with one peer having significantly more free addresses than the

other. In this case, the peer that has fewer addresses performs the appropriate pool-

rebalancing action, as described later in this chapter, in the section, “Pool

Rebalancing.”

During periods of inactivity, each peer sends periodic

CONTACT messages to the other

to probe for network outages. If no message is received from a peer for a certain

period of time, the peer assumes that the connection has broken and begins operat-

ing independently. The connection between peers can also be terminated because

one peer is being shut down; in that case, the server being shut down sends a

DISCONNECT message to its peer, and then both peers close the connection.

CHAPTER 10 Failover Protocol Operation162

013 3273 CH10 10/3/02 4:59 PM Page 162

Lease Handling with Failover

The DHCP has traditionally allowed IP addresses to be in one of two states. Either

the lease expiry time for the address is in the past, meaning that the address is avail-

able to be allocated to a client, or the lease expiry time is in the future, meaning that

the address is not available to be allocated. The duration that is assigned to leases is

likewise very simple to calculate. The failover protocol introduces additional

complexity both in terms of the number of states an IP address can be in and in

terms of how the duration of a lease is calculated.

IP Address Binding States

The failover protocol specifies many possible IP address binding states. These states

are used to indicate whether an address is in active use, which failover peer can allo-

cate an address that is not in use, and an address’s transition from being in active use

to being available for allocation. Table 10.1 lists the complete set of possible binding

states for IP addresses. An IP address can also be flagged to indicate that it is reserved

for a particular client or that it is assigned to a BOOTP client.

TABLE 10.1 IP Address Binding States

State Description

ABANDONED The address has been abandoned as a result of an IP address allocation conflict

detected by either server.

ACTIVE The address is in active use by a client.

BACKUP The address is available for allocation by the secondary peer.

EXPIRED The address is no longer known to be in use by the client, but it is still bound to

the client.

FREE The address is available for allocation by the primary peer.

RELEASED The address has been released by the client, but it is not yet available for

allocation.

RESET The address has been released through administrative action, but it is not yet

available for allocation.

When a failover peer makes a change to a client lease, it sends a BNDUPD message to

the other peer. The update includes the new state that the lease is in, the time that

the change happened, the actual expiry time of the lease, and the potential expiry

time of the lease, along with other information that identifies the client and possibly

communicates information that the client sent. When the peer processes a

BNDUPD, it

sends back a

BNDACK message.

After the first peer has received the BNDACK message, both peers have the same infor-

mation about the lease. For example, if an address is in the

BACKUP state on the

primary peer, it is also in the

BACKUP state on the secondary. When the servers are

Lease Handling with Failover 163

013 3273 CH10 10/3/02 4:59 PM Page 163

not operating normally, or when a change has been made on one server but the

other server hasn’t yet processed the update, IP addresses can be in different states

on each of the failover peers. The rules controlling how to allocate IP addresses

protect both peers from making mistakes when their IP address databases are not in

synch.

Two IP address states indicate that an address is available for allocation.

Addresses that are available for the primary server to allocate are in the

FREE

state. Addresses that are available for the secondary to allocate are in the BACKUP

state. Addresses are never available for both servers to allocate at the same time.

When an address has been assigned to a client, whether by the primary peer or the

secondary failover peer, it enters the

ACTIVE state. An address in the ACTIVE state

cannot be reallocated to another client until it reaches the

FREE state or the BACKUP

state. Therefore, either server in a failover pair can extend a lease.

A lease expires at the moment when its expiry time occurs. When the lease on an

address expires, the address moves from the

ACTIVE state to the EXPIRED state. The

server making the change then sends an update to the other server. When the

other server receives an update that moves an address from the

ACTIVE state to the

EXPIRED state, it moves the lease into the FREE state and sends an acknowledgement

to the first server. When the first server receives the acknowledgement, it moves the

lease into the

FREE state. At this point, the lease is available for the primary peer to

allocate.

This two-way handshake is required because after an address has been assigned to a

client, either the primary or the secondary server can extend the lease. If the server

that notices that the lease has expired moved the lease immediately into the

FREE

state, it might then allocate the lease to a new client while the other server was

extending it for the original client.

This brings up an additional complication: After the server that has moved a lease

into the

EXPIRED state has sent a BNDUPD message to its peer, it can’t extend the lease

anymore. This is because when the peer receives the update, it immediately moves

the lease into the

FREE state. Even before the first server has received an acknowl-

edgement, its peer may be able to allocate the lease to a new client.

Two other states are handled similarly to the

EXPIRED state: RELEASED and RESET.

When a failover peer receives a

DHCPRELEASE message from a DHCP client, it places

that client’s lease into the

RELEASED state. The RELEASED state is handled like the

EXPIRED state in terms of how binding updates are done. It is also possible for an

administrator to release an address. In this case, the address is moved into the

RESET

state, which is also handled like the EXPIRED state.

CHAPTER 10 Failover Protocol Operation164

013 3273 CH10 10/3/02 4:59 PM Page 164

Assigning Lease Durations with Failover

In the absence of failover, the DHCP server has a clear process that it follows to

compute the client lease duration. The client can request a lease duration in its

DHCPDISCOVER and DHCPREQUEST messages. If it doesn’t, the DHCP server assigns a

default lease duration, which the network administrator can usually configure. The

DHCP server can then check this duration against a minimum specified by the

network administrator. If the duration is shorter than the minimum, the lease dura-

tion is increased to the minimum. The DHCP server can also check against a

maximum specified by the network administrator, and again, if the lease is longer

than the maximum, it is reduced to the maximum.

With the failover protocol, this lease duration is referred to as the desired lease time.

The reason for this name is that this is the time that the server would like to give to

the client. Whether or not the server can give this lease duration to the client

depends on the state of the lease. There are three entities that remember a state for

the lease: the DHCP client, the primary failover peer, and the secondary failover peer.

The lease duration must be chosen so that the DHCP client will not believe that its

lease expires later than either of the failover peers believes it expires. The DHCP

server assigning the lease to the client can always remember when it assigned the

lease to the client, so this is not the problem. The problem is the other server.

Let’s say that the primary peer receives a

DHCPDISCOVER message from a new client—

one that has no active lease. The primary peer finds an address that is in the

FREE

state and allocates this address for the client. The secondary peer does not know yet

that the primary peer has allocated this address. According to the rules in the section

“Address Allocation Constraints,” earlier in this chapter, the primary peer can’t

extend a lease by more than the MCLT. So the primary peer compares the MCLT to

the desired lease time; if the MCLT happens sooner than the desired lease time,

which is likely because MCLT is chosen to be short, the primary assigns an actual

lease expiry time that is the current time plus MCLT.

If the client confirms this lease through the normal four-packet protocol, it will end

up with a lease that expires at the actual least expiry time (which is the only lease

time a client ever sees)—in this case the MCLT. At this point, the client probably has

a lease that is shorter than the desired lease time. The short lease time will still work,

and there is no way to avoid giving the client a short initial lease. After the initial

lease assignment, the failover protocol tries to make it possible to give the client a

lease that is close to its desired lease time.

The server gives the client its desired lease time by estimating when the client will

renew its lease and computing a potential lease expiry time—the time when the client

is expected to renew plus the desired lease time. The server can assume that the

client will renew its lease halfway through. When the primary peer updates the

secondary peer, it tells the secondary peer the actual lease expiry time and also the

Lease Handling with Failover 165

013 3273 CH10 10/3/02 4:59 PM Page 165