Droms R. The DHCP handbook

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

Example 14.8

option domain-name “example.org”;

Client parameters are specified in the same way as server parameters, with the name

of the parameter followed by its value, as shown in Example 14.9.

Example 14.9

filename “netbsd-alpha”;

All the options defined by the DHCP server are documented in Appendix B.

User-Defined Options

In addition to the predefined options listed in Appendix B, the ISC DHCP server

provides the ability to define new options. These include new options standardized

after the version of the server you are running was shipped, experimental options,

site-local options, and vendor-specific options.

You define a new option by specifying an option name, a code, and a format.

Example 14.10 shows an option called

acme-config-file, with a code of 129, whose

format is a simple string of ASCII text.

Example 14.10

option acme-config-file code 129 = text;

Options can be more complex than this. You can define an option that encodes a set

of values of different types, an array of values, or an array of sets of values. Example

14.11 shows an option definition that encodes one or more IP addresses, an option

definition that encodes one or more sets of IP addresses and 16-bit numbers, and an

option that encodes an IP address, a 32-bit number, and an ASCII text string.

Example 14.11

option acme-font-servers code 130 = array of ip-address;

option acme-registrars code 131 = array of { ip-address, integer 16 };

option acme-license-info code 132 = { ip-address, integer 32, text };

NOTE

The DHCP server currently supports only data types defined in RFC 2132. You cannot encode

some things that might be desirable; for example, you cannot send more than one text string.

CHAPTER 14 The ISC DHCP Server236

018 3273 CH14 10/3/02 5:02 PM Page 236

Appendix B gives a complete list of data types that you can use in defining new

options.

Option Spaces

In addition to defining new options that are used just like regular DHCP options,

you can declare new option spaces. An option space is a collection of options. The

standard set of DHCP options is numbered from 0 to 255 and all option numbers

greater than 128 are reserved for site-local use. If you define a new option space, it

has its own numbering system, probably also from 0 to 255, with different options

corresponding to each number. For example, the

host-name option has an option

code of 1. If you define a new option space, you can define a different option in that

option space that also has an option code of 1. This new option does not replace the

host-name option because it is in a different option space.

Five predefined option spaces exist: the dhcp option space, the server option space,

the

agent option space, the nwip option space, and the fqdn option space. You

cannot define new option spaces with these names. The

dhcp option space contains

all the DHCP options that are not encapsulated. The

server option space represents

all the server control parameters—for example, the

authoritative statement is repre-

sented internally as the

authoritative option in the server option space. The fqdn

option space allows the fields of the fqdn option to be examined and modified indi-

vidually. The

agent and nwip option spaces contain the suboptions for the relay

agent information option and the netware/IP option.

You can define new option spaces for three reasons: to support vendor-specific

options, to support site-specific options, and to define a new option in the

dhcp option space that encapsulates its own set of suboptions, like the agent and

nwip option spaces.

Some DHCP clients use vendor-specific options. These options are encapsulated in

the

vendor-specific information option. This option is handled differently than

the other encapsulation options because you might need to configure the DHCP

server to handle more than one vendor’s set of vendor-specific options. The

vendor-specific information option is described in Chapter 20.

The second reason to define a new option space is so that overlapping site-specific

option codes can be defined. This might be necessary because some vendors of

DHCP and BOOTP clients (for example, NCD and Hewlett-Packard) used the site-

specific code range (128–254) to define their own vendor-specific option codes

before it was reserved for site-specific options and before the

vendor-specific

information option was defined.

Configuring the ISC DHCP Server 237

018 3273 CH14 10/3/02 5:02 PM Page 237

The site-option-space Parameter

Although some of the option codes for these vendors might overlap, you may want

to provide different global values for different vendors. You can do this by defining

option spaces and then using the

site-option-space parameter to determine which

option code is actually sent to the client.

Example 14.12 shows a configuration that provides different global values for a site-

specific option to two different devices that are identified by using

host declarations.

This example makes practical sense only if many

host declarations exist, not just

two.

Example 14.12

option space acme;

option acme.toast-color code 137 = integer 16;

option acme.toast-color 4096;

option space ypl;

option ypl.ot-modulation code 137 = array of integer 32;

option ypl.ot-modulation 10, 188277, 423119, 9188271;

host acme1 {

hardware ethernet 99:aa:bb:0c:ad:e2;

site-option-space acme;

}

host ypl1 {

hardware ethernet aa:ee:ee:1c:a2:29;

site-option-space ypl;

}

The site-option-space parameter tells the DHCP server that for all options whose

codes are between 128 and 254, the server should use the values declared in the

specified option space instead of the values from the default option space.

Configuring Connections to Other Services

An ISC DHCP server can communicate with three other types of entities on the

network—DHCP failover peers, DNS servers, and OMAPI clients. Whether the DHCP

server interacts with these other services, and how it does so, is configured in the

dhcpd.conf file.

CHAPTER 14 The ISC DHCP Server238

018 3273 CH14 10/3/02 5:02 PM Page 238

DHCP Failover Configuration

DHCP failover configuration information specifies which DHCP failover servers, if

any, the DHCP server will be peering with, and what pools will be shared in which

peering arrangements. The DHCP server can be configured with any number of

peering relationships, and any IP address allocation pool can be associated with any

failover peering relationship that has been declared.

DNS Update Configuration

The DHCP server can be configured to set up DNS mappings for DHCP clients when

it assigns IP addresses to them and to remove those mappings when clients stop

using their leases. The information that can be configured includes information

about what names to assign to DHCP clients, what DNS servers to contact for various

sets of names, and authentication keys to use when updating those DNS servers.

The DHCP server may also use DNS servers to look up hostnames that are specified

in the configuration file. This depends on how the particular operating system on

which the DHCP server is running performs hostname-to-IP address translation. If

this can be configured at all, it must be configured in the operating system’s configu-

ration files, not in the DHCP configuration file.

OMAPI Configuration

The DHCP server can be configured to accept connections from OMAPI clients.

OMAPI is a protocol that allows a client to examine and modify objects on the

DHCP server over a network connection. OMAPI is not enabled by default. To enable

OMAPI, you must write an

omapi-port statement in the DHCP configuration file.

OMAPI clients can make significant changes to the DHCP server’s internal state, so it

is important to authenticate the OMAPI protocol. To do this, you must use the

omapi-key statement. These statements are described in Appendix B. The omapi-key

statement requires you to define a key. Keys are used primarily for DNS updates, and

the procedure for defining keys is described in Chapter 23, “Configuring Dynamic

DNS Updates.”

OMAPI is a control protocol for the ISC DHCP server and client. The use of OMAPI

in controlling the DHCP server is beyond the scope of this book. For information

about how to use OMAPI, consult the documentation that comes in the ISC DHCP

distribution. The

dhcpd manual page documents DHCP server OMAPI objects. The

dhcpctl and omapi manual pages describe how to write C programs that use OMAPI.

The easiest way to learn how to use OMAPI is to read the

omshell man page and try

to use the

omshell program to examine and modify the state of the DHCP server.

Configuring the ISC DHCP Server 239

018 3273 CH14 10/3/02 5:02 PM Page 239

Network Configuration Information

Network configuration information describes to the DHCP server the physical layout

of the network. The DHCP server actually doesn’t need to know how network

segments are interconnected; the network infrastructure—routers, bridges, ethernet

switches, and so on—takes care of this. It does need to know what subnets are

assigned to each network segment and what network segments are present in the

network.

Even network segments that don’t get DHCP service may need to be described to the

server, either so it can behave appropriately in response to requests from those

networks or so it can be told not to respond to requests on those networks. The ISC

DHCP server is quite insistent about this. If you do not describe the networks to

which the DHCP server machine is attached, the ISC DHCP server refuses to operate.

Configuration File Declarations

You must use the

shared-network and subnet declarations to describe the network

configuration. The

shared-network declaration describes a network segment: a single

network on which any connected node receives all link-layer broadcasts sent by any

other connected node. The

subnet declaration declares an IP subnet: a single

network on which any connected node receives all IP-layer broadcasts sent by any

other connected node. You can configure more than one subnet on a network

segment; if you do so, you must enclose the

subnet declarations for those subnets in

shared-network declaration. If only one IP subnet is configured on a particular

network segment, you don’t have to write an explicit

shared-network declaration.

Chapter 15 describes subnet and shared-network declarations in detail. Example

14.13 shows an example of a

subnet declaration for the subnet whose network

number is 10.117.22.0 and whose subnet mask is 255.255.255.0.

Example 14.13

subnet 10.117.22.0 netmask 255.255.255.0 {

}

Scopes

The ISC DHCP server derives the parameters used to control its behavior with respect

to a certain client, and the parameters and options it sends the client, from the

scopes in which the client appears. Scopes do not control the choice of address

assigned to a client; this is controlled by the network segment to which the client is

connected and the address allocation rules that apply for the addresses that are avail-

able on that network segment.

CHAPTER 14 The ISC DHCP Server240

018 3273 CH14 10/3/02 5:02 PM Page 240

An option that appears in the global scope (that is, outside any declaration with its

own scope) applies to all clients. Options in scopes other than the global scope apply

only to the clients that appear within those scopes and the scopes outside them. For

example, if a client matches a

host declaration, the client appears in the host decla-

ration scope and all the scopes outside it.

Example 14.14 shows a configuration that makes heavy use of scoping. Every decla-

ration in the DHCP server configuration file that has enclosing braces automatically

comes with its own scope. In addition, you can explicitly declare a scope by using

the

group statement. Example 14.14 uses the group statement to provide the same

parameters to a group of

host declarations for NCD X terminals that otherwise have

no common scope.

Example 14.14

option domain-name “example.org”;

option domain-name-servers ns1.example.org, ns2.example.org;

subnet 10.0.17.0 netmask 255.255.255.0 {

option broadcast-address 10.0.17.255;

option routers 10.0.17.254;

range 10.0.17.10 10.0.17.253;

}

subnet 10.0.16.0 netmask 255.255.255.0 {

option broadcast-address 10.0.16.255;

option routers 10.0.16.254;

range 10.0.16.10 10.0.16.253;

}

# NCD X terminals

group {

filename “/tftpboot/Xncd19c”;

host ncd1 { hardware ethernet 00:00:a7:09:21:ac; }

host ncd2 { hardware ethernet 00:00:a7:1c:33:90; }

host ncd3 { hardware ethernet 00:00:a7:2a:04:17; }

}

If a client connected to the 10.0.16.0 subnet sends a DHCPDISCOVER message, the

DHCP server considers that client to be in the scope of the 10.0.16.0 subnet. It finds

the

broadcast-address and routers options in that scope, and then it moves to the

scope that is outside the subnet scope—in this case, the global scope—and finds the

domain-name and domain-name-servers options. The explicitly specified options it

Configuring the ISC DHCP Server 241

018 3273 CH14 10/3/02 5:02 PM Page 241

finds for the client, then, are the broadcast-address, routers, domain-name, and

domain-name-servers options.

A client can appear in more than one scope at the same time. Figure 14.1 shows a

diagram of the scopes declared in Example 14.14. As you can see, each host declara-

tion has a scope. When a client matches a

host declaration, the DHCP server consid-

ers that client to be in the scope of the

host declaration. It also considers the client

to be in the scope of the

subnet declaration for the subnet from which the client is

assigned an IP address. If, for example, the client matching the

ncd1 host declaration

is assigned an address on the 10.0.16.0 subnet, the client appears in that subnet’s

scope and in the

host declaration scope, as well as in all the scopes containing them.

CHAPTER 14 The ISC DHCP Server242

Global Scope

option domain-name “example.org”

option domain-name-servers ns1.example.org,ns2.example.org;

Scope of the 10.0.17/24 Subnet

option broadcast-address 10.0.17.255;

option routers 10.0.17.254;

Scope of the 10.0.16/24 Subnet

option broadcast-address 10.0.16.255;

option routers 10.0.16.254;

Group scope

filename “/tftboot/Xncd19c”;

Scope of host NCD1

hardware ethernet 00:00:a7:09:21:ac;

Scope of host NCD2

hardware ethernet 00:00:a7:l:33:90;

Scope of host NCD3

hardware ethernet 00:00:a7:2a:04:17;

FIGURE 14.1 A diagram of the scopes in Example 14.14.

018 3273 CH14 10/3/02 5:02 PM Page 242

The DHCP server processes scopes by cycling through each specific scope in which

the client appears, in reverse order of specificity—in this case, the subnet scope and

then the host scope.

Specific Scopes

A specific scope is a scope the client specifically matches, not the scopes that contain

such a scope. For example, a client never matches the global scope; it gets parameters

from the global scope because the global scope contains some scope that the client

does match.

The specificity of a scope that a client matches is dependent on the type of declara-

tion with which the scope is associated. The fewer clients a particular type of declara-

tion can match, the more specific its scope is considered to be. This ordering is

somewhat arbitrary; classes are considered more specific than subnets, for example,

so a

subnet declaration that can match only 10 clients can be considered less specific

than a

class declaration that happens to match hundreds of clients throughout the

network.

The exact ordering of specificity of declarations starts with the most specific declara-

tion, the

host declaration, and continues through the subclass, class, subnet, and

pool scopes, to the least specific scope, which is the shared-network scope. Scopes

that don’t match clients (for example, group scopes and the global scope) do not

have an inherent specificity. For each specific scope that the server considers, it also

considers the scopes outside that scope, all the way to the global scope.

The server never considers the same scope twice. If the same outer scope contains

two specific scopes that the client matched, that scope is considered in the process of

evaluating the more specific of the two specific scopes and is skipped when the other

specific scope is processed.

The scopes considered for the client

ncd1 in Example 14.14 are, in order, the global

scope, the scope of subnet 10.0.16.0, the scope for the group declaration that

surrounds the

ncd1 host declaration, and the scope for the ncd1 host declaration.

An additional complication is that different values for the same parameter or option

can be specified in different scopes. The scoping rules described previously are

intended to ensure that the option or parameter that applies to a particular client is

predictable. The result of these rules is that the parameter or option that appears in

the most specific scope is always the one that is used. If a parameter within a

host

declaration is different from the same parameter within a subnet declaration, the

parameter in the

host declaration is used. If an option declared within a subnet

declaration is different from the value declared for that option in the global scope,

the value in the

subnet declaration applies to all clients connected to that subnet,

Configuring the ISC DHCP Server 243

018 3273 CH14 10/3/02 5:02 PM Page 243

and the value in the global scope applies to all other clients (assuming that it isn’t

overridden in other inner scopes).

IP Address Assignments

You can provide IP addresses for clients in two ways: through static IP address assign-

ments and through pool declarations that contain

range statements.

Static IP address assignments are performed through host declarations. Chapter 16

describes static IP address assignment in detail. Briefly, for each client that receives a

static assignment, there must be a

host declaration with information that the server

can use to match the declaration to the client, and that declaration must also

contain a fixed-address declaration that contains the IP address to assign. When a

fixed mapping exists for a client, and the client is connected to the network segment

on which that address is valid, the DHCP server will insist on assigning the client the

IP address in the

fixed-address declaration. If the client is connected to a network

segment for which it has no valid

fixed-address declaration, the DHCP server

assigns it a dynamically-allocated IP address, or no address at all, depending on how

the server is configured.

Addresses are assigned dynamically out of address pools. Address pools are declared

with

pool declarations that contain range statements. Chapter 20 describes the pool

declaration. Chapter 15 describes simple range statements.

If you are configuring a pool that will be shared between two DHCP servers in a

failover peering relationship, the pool declaration must contain a reference to the

failover peer declaration. If this reference is not present, you will experience major

problems with your DHCP service.

Invoking the ISC DHCP Server

After you have produced a configuration for a DHCP server, you must know how to

invoke it. Invoking the DHCP server involves two aspects: command-line arguments

and getting the server to work right for a particular operating system.

Command-Line Arguments

The server takes command-line switches that determine the following:

• The UDP port on which it listens

•Whether it runs in the background as a daemon

•Whether debugging output is logged to stdout

•What filename to use for the configuration file, lease database file, and process

ID file

CHAPTER 14 The ISC DHCP Server244

018 3273 CH14 10/3/02 5:02 PM Page 244

•Whether to merely test the configuration

•Whether to be verbose on startup

•Whether to save a trace file

•Whether to play back a trace file

•Whether to check the lease database for correctness

• The interface or interfaces on which the server should listen

You can specify interfaces directly on the command line. You must specify the other

parameters by using command-line switches. A switch consists of the

- character

followed by a letter or keyword. Some switches are followed by arguments, in which

case the switch and the argument are separated by a space character.

The

-p switch indicates the UDP port on which the server should listen. If this

switch is specified, the server uses the next higher port number as its source port.

DHCP specifies that the server should always listen on port 67 and transmit on port

68. If the

-p 67 switch is given (or if no -p switch is given), the server uses ports 67

and 68. In general use, it is never appropriate to use the

-p switch, but it can be very

useful for debugging or benchmarking.

The

-f switch indicates that the server should operate normally but should not fork

a subprocess and exit to the invoking process. Normally, if you just type

dhcpd, the

DHCP server prints a startup message and then appears to exit, at which point you

receive a shell prompt. However, what actually happens is that the server started a

child process that then detaches itself from the terminal and runs in the background,

while the parent process (the one you started when you typed the command) exits.

The

-f switch causes the server to remain attached to the terminal and run in the

foreground, and it is useful in situations in which you are invoking the DHCP server

from

/etc/inittab (this is a UNIX System V concept and may or may not even be

possible on the version of the operating system you are running).

The

-d switch tells the server to run in the foreground, as with the -f switch, but in

addition to logging all its output to the syslog daemon, the server logs all its output

to the terminal. This can be very useful when you are debugging the server; you

invoke it with the

-d switch the command line and watch as it configures (or fails to

configure) a client. If you are reporting a bug on the

dhcp-server mailing list, you

are always asked for the server output, and using the

-d switch is the easiest way to

get it.

The DHCP server normally looks for its configuration file in

/etc/dhcpd.conf. If you

are testing, or simply don’t want your configuration file to be stored in

/etc, you

can override this by using the

-cf switch, followed by the filename that you prefer.

Invoking the ISC DHCP Server 245

018 3273 CH14 10/3/02 5:02 PM Page 245