Droms R. The DHCP handbook

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

FIGURE A.13 Finding a DHCP client’s lease in the Address Leases window.

Example 17.1

No known equivalent exists for the Microsoft DHCP server.

Example 18.1 through 18.9

Because the Microsoft DHCP server does not implement the failover protocol, there

is no equivalent for these examples.

Example 19.1

The section “Examples 3.8 and 3.9,” earlier in this appendix, describes how to set

the maximum lease time. The Microsoft DHCP server does not allow configuration

of a minimum or a default lease time.

Examples 20.1 through 20.14

No known equivalents exist for the Microsoft DHCP server.

Example 22.1

No known equivalent exists for the Microsoft DHCP server.

APPENDIX A Microsoft DHCP Server Examples456

031 3273 App A 10/3/02 5:04 PM Page 456

Example 22.2

You can enable the Microsoft DHCP client on some interfaces and not enable it on

others. See Chapter 20, “Conditional Behavior,” for more information. (However, we

know of no way to configure the Microsoft DHCP server not to provide service on

some interfaces.)

Example 22.3

See the section in Chapter 19 on the Microsoft DHCP client for more information.

Example 22.4

No known equivalent exists for the Microsoft DHCP server.

Examples 22.5 through 22.7

No known equivalents exist for the Microsoft DHCP client.

Examples in Appendixes

These system-specific examples are not applicable to Windows 2000.

Examples in Appendixes 457

031 3273 App A 10/3/02 5:04 PM Page 457

031 3273 App A 10/3/02 5:04 PM Page 458

ISC DHCP Server

Configuration File

Reference

This appendix provides a complete reference for the ISC

DHCP server’s configuration file. Every possible statement

or syntax that can appear in the

dhcpd.conf file is

described here. This appendix begins with a description of

the organization of the file and then documents all types

of declarations and statements. It ends with a complete list

of predefined DHCP options and their formats.

The material in this appendix is adapted from material

found at

ftp://ftp.isc.org/isc/dhcp/3doc/dhcp-eval.5

and ftp://ftp.isc.org/isc/dhcp/3doc/dhcpd.conf.5,

How to Use This Appendix

This appendix is organized into groups of statements and

declarations of similar types. It is not organized alphabeti-

cally. (To look something up alphabetically, refer to the

index.) Furthermore, this appendix does not attempt to

explain how to use the syntax it describes. For that infor-

mation, refer to the relevant chapters in this book, particu-

larly Chapter 14, “The ISC DHCP Server,” Chapter 15,

“Configuring a DHCP Server,” Chapter 16, “Client

Identification and Fixed-Address Allocation,” Chapter 17,

“Setting Up a Reliable DHCP Service,” and Chapter 20

“Customizing the Server’s Response to Clients.”

Each subsection of this appendix that describes a specific

element of syntax from the configuration file also provides

a syntax diagram for that element. In a syntax diagram,

text that appears in boldface is actual syntax that you

032 3273 App B 10/3/02 5:04 PM Page 459

APPENDIX B ISC DHCP Server Configuration File Reference460

enter into the file, exactly as it is shown. Text that appears in italics is intended to

represent some information that you must provide. Such information is explained in

the text following the syntax diagram.

Some text in the syntax diagram is specified using neither boldface nor italics. In

such cases, you have a choice as to what syntax to write. If a portion of a syntax

diagram is enclosed in square brackets, as shown in Example B.1, you can either

include or omit that portion.

Example B.1

range low-address [ high-address ];

In this example, the high-address parameter is optional, and you can enter or omit

it, depending on the desired meaning, which is described later in this appendix, in

the section “The

range Declaration.” low-address and high-address are not meant

to be typed in literally, but represent some general syntax that is described in the

text that follows the syntax diagram.

When a selection of possible keywords can be entered in a particular part of the

syntax diagram, these keywords are enclosed in square brackets and separated by

vertical bars, as shown in Example B.2. The text following the syntax diagram

explains whether you must enter one of these keywords.

Example B.2

[ allow | deny ] known clients;

In this example, you must enter either the allow keyword or the deny keyword, but

not both.

Finally, in some cases you can specify one or more values in a particular portion of

the syntax, denoted by square brackets and ellipses, as in the following example:

option name code code = { type-1 [ ... , type-n ] };

In this example, you can enter one or more types within the braces, separated by

commas.

File Organization

The dhcpd.conf file is a sequence of statements and declarations. Declarations are

evaluated once, when the server reads the file, and they tend to persist as structures

in the DHCP server’s in-memory database. Statements are generally evaluated each

time a request is received for a client. The scope in which a statement appears deter-

mines whether it is evaluated for a given client.

032 3273 App B 10/3/02 5:04 PM Page 460

Many declarations have scopes within which other declarations and statements can

be written. Most scopes are simply collections of statements and declarations that are

enclosed in braces. One exception is the global scope, which is the text of the

dhcpd.conf file that appears outside all pairs of braces. Chapter 14 describes how the

DHCP server evaluates scopes.

Statements fall into two major categories:

• Conditional statements

• Statements that define options or parameters

The server handles options in much the same way that it handles parameters. The

only difference between them is that parameters control what the server does, and

options tell the server what to send to the DHCP client. Chapter 20 describes how

conditional statements can be used.

Declarations can’t appear within conditional statements because conditional state-

ments are evaluated every time a packet is received, and declarations are evaluated

when the configuration is read, and they persist thereafter.

In cases where the syntax for a declaration or statement calls for an IP address, you

can specify a domain name instead. This can be very convenient, but there are some

things to be aware of when you specify a domain name instead of an IP address:

• Doing a DNS lookup can delay the DHCP server’s response to a DHCP client.

• The DHCP server does not notice updates to the domain name server when

they happen.

•ADNS lookup can return more than one IP address.

DHCP calls for IP addresses, not domain names, to be sent to clients. This means

that whenever you specify a domain name in the configuration file, the DHCP server

has to translate that domain name into an IP address. It does this by sending a DNS

lookup request to the domain name server and waiting for a response. Each DNS

lookup is processed sequentially. If the DHCP server has to do a lot of DNS lookups,

this can significantly delay its response to the client.

DNS lookups for statements in the DHCP configuration file are processed when the

DHCP server receives a request from a DHCP client. The DHCP server caches the

result of any DNS lookup for an hour, so if you only specify a few names in the

DHCP configuration file, the DHCP server won’t be delayed very much in doing DNS

lookups. This means, though, that there may be as much as an hour’s delay before

the DHCP server notices that a record has changed in the DNS.

File Organization 461

032 3273 App B 10/3/02 5:04 PM Page 461

If you use domain names in declarations, these are processed once, when the DHCP

server starts. If you make a change in the domain name server to a record that is

used in a declaration, the DHCP server will not pick up that change until you restart

it. Also, if you use a lot of different names in the DHCP configuration file, the DHCP

server can take a long time to start. For this reason, if you have a large number of

fixed-address declarations (that is, thousands or more), it is better to use an IP

address than a domain name in those declarations.

A DNS lookup can return more than one IP address. If you specify a domain name in

the configuration file where exactly one IP address is called for, and if the lookup on

that domain name returns more than one IP address, the server uses the first IP

address that the DNS server returns and silently ignores the others. If you specify a

domain name where more than one IP address is allowed, the DHCP server uses all

the IP addresses returned by the DNS server. It is also possible for the DNS server to

return no addresses for a domain name. In this case, the DHCP server reports an

error.

The configuration file has a free-form syntax. Statements and declarations that don’t

have scopes always end with a

; character. Declarations that have scopes always end

with a

} character, after the end of the scope. The following example shows a state-

ment, a declaration with no scope, and a declaration with a scope:

option dhcp-client-identifier 1:15:2e:17:49:ad:c3;

fixed-address 10.0.1.17;

host “foo” {

...

}

You can specify comments in the configuration file. A comment begins with a #

character, and continues to the end of the line. If the # character appears inside

quotation marks, it does not start a comment. Comments can appear in the middle

of statements and declarations. The following examples show how comments can be

used:

# This is a comment that appears on its own line.

option domain-name-server 10.0.1.1; # This is a comment.

fixed-address # This is also a comment.

10.0.1.17; # and so is this.

option domain-name “#this is not a comment.”;

APPENDIX B ISC DHCP Server Configuration File Reference462

032 3273 App B 10/3/02 5:04 PM Page 462

The shared-network Declaration

shared-network name {

[ statements ]

[ declarations ]

}

You use the shared-network declaration to inform the DHCP server that the subnets

declared within it are connected to the same network segment. Parameters specified

in the scope of the

shared-network declaration are considered to be more specific

than (and thus override) parameters specified in the global scope.

name should be the name of the network segment that the shared-network declara-

tion represents. The server uses this name when printing debugging messages, so it

should be a name that meaningfully describes the network segment. The name may

have the syntax of a valid domain name (although it is never used as such), or it

may be any arbitrary name that you choose.

The subnet Declaration

subnet subnet-number netmask subnet-mask {

[ statements ]

[ declarations ]

}

You use the subnet declaration to provide the DHCP server with enough information

to determine whether a particular IP address is on the subnet. A

subnet declaration

should exist for every subnet from which the DHCP server might receive a DHCP

request. If the DHCP server allocates an IP address for a client from a particular

subnet, statements in that subnet’s scope are executed and are considered more

specific than statements in the global scope or in the

shared-network scope.

subnet-number should be an IP address or domain name that resolves to the subnet

number of the subnet being described.

netmask should be an IP address or domain

name that resolves to the subnet mask of the subnet being described. You can use

the subnet number, together with the subnet mask, to determine whether a particu-

lar IP address is on the specified subnet.

If no

subnet-mask option is specified in scope for a client receiving an IP address on

a particular subnet, the subnet mask from the

host declaration is supplied to the

client in the

subnet-mask option. If a subnet-mask option statement in any scope

applies to the client, however, it takes precedence over the subnet mask in the

subnet declaration.

The subnet Declaration 463

032 3273 App B 10/3/02 5:04 PM Page 463

The range Declaration

range low-address [ high-address ] ;

For any subnet on which addresses are assigned dynamically, there must be at least

one

range declaration. The range declaration specifies that the server may allocate to

DHCP clients every address from

low-address to high-address. You can specify a

single IP address by omitting

high-address.

All IP addresses in the range should be on the same subnet. If the range declaration

appears within a

subnet declaration, all addresses should be on the declared subnet.

If the

range declaration appears within a shared-network declaration, all addresses

should be on subnets that are already declared within the

shared-network declara-

tion. This is true even if the range is enclosed in a

pool declaration and the pool

declaration is enclosed in the shared-network or subnet declaration.

The host Declaration

host name {

[ statements ]

[ declarations ]

}

The host declaration provides information about a particular DHCP client. name

should be a name for the host declaration. Every host declaration must have a

unique name, but the only purpose of the name is to identify the host declaration;

the name does not, for example, have anything to do with the client’s hostname..

host declarations match DHCP or BOOTP clients based on either the clients’ link-

layer address or the

dhcp-client-identifier option that the client sends. Chapter

16 discusses how this works in detail. BOOTP clients do not normally send a

dhcp-

client-identifier option. Therefore, you must use the link-layer IP address for all

clients that might send BOOTP protocol requests.

The

host declaration has three purposes:

•To assign a static IP address to a client

•To declare a client as “known”

•To specify a scope in which statements can be executed for a specific client

You can make the DHCP server treat some DHCP clients differently than others if

host declarations exist for those clients. Any request coming from a client that

matches a

host declaration is considered to be from a “known” client. Requests that

do not match any

host declaration are considered to be from “unknown” clients.

APPENDIX B ISC DHCP Server Configuration File Reference464

032 3273 App B 10/3/02 5:04 PM Page 464

You can use this knowledge to control how addresses are allocated, as described in

Chapters 16 and 20.

It is possible to write more than one

host declaration for a client. This can be useful

if the client has a different scope on different subnets; for each IP address that

requires a different scope, one

host declaration should exist. A client can be in the

scope of only one

host declaration at a time. host declarations with static address

assignments are in scope for a client only if one of the address assignments is valid

for the network segment to which the client is connected. The host scope is the most

specific scope. The name of every

host declaration must be unique, even among host

declarations that refer to the same DHCP client.

The hardware Declaration

hardware type address;

A host declaration that is matched to a DHCP or BOOTP client using the client’s

link-layer address should include a

hardware declaration. type should be the type of

network hardware—currently,

ethernet, token-ring, or fddi. address should be the

link-layer address—a list of octets specified as hexadecimal numbers, separated by

colons.

The dhcp-client-identifier option Statement

option dhcp-client-identifier identifier;

Within a host declaration, you can use a dhcp-client-identifier option statement

to match a

host declaration to a DHCP client. If it is being used to identify the

client, the

dhcp-client-identifier option statement must not be specified within

any kind of conditional statement. It also must not have a value that is dependent

on what the DHCP client sent, because it is executed when the configuration file is

parsed, not when a packet is received. If the DHCP client sends a

dhcp-client-iden-

tifier option statement with the value specified in identifier, the host declaration

matches.

NOTE

The DHCP server does not report an error if you specify both a dhcp-client-identifier

option and a hardware declaration. The DHCP server attempts to match the client to the host

declaration first, using the dhcp-client-identifier option sent by the client and then by

using the client’s link-layer address.

The

host Declaration 465

032 3273 App B 10/3/02 5:04 PM Page 465