Droms R. The DHCP handbook

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

The fixed-address Declaration

fixed-address address-1 [ , ..., address-n ];

To make a static IP address assignment for a client, the client must match a host

declaration, as described earlier. In addition, the host declaration must contain a

fixed-address declaration. A fixed-address declaration specifies one or more IP

addresses or domain names that resolve to IP addresses. If a client matches a

host

declaration and one of the IP addresses specified in the host declaration is valid for

the network segment to which the client is connected, the client is assigned that IP

address.

A static IP address assignment overrides a dynamically assigned IP address that is

valid on that network segment. That is, if a new static mapping for a client is added

after the client has a dynamic mapping, the client cannot use the dynamic mapping

the next time it tries to renew its lease. The DHCP server does not assign an IP

address that is not correct for the network segment to which the client is attached

and does not override a valid dynamic mapping for one network segment based on a

static mapping that is valid on a different network segment.

There should be only one

fixed-address declaration per host declaration.

The pool Declaration

pool {

[ permit list ]

[ range declarations ]

[ statements ]

}

You can use the pool declaration to declare an address pool from which IP addresses

can be allocated, with its own permit list to control client access and its own scope

in which you can declare pool-specific parameters.

pool declarations can appear

within

subnet declarations or shared-network declarations. The addresses in a partic-

ular pool are declared with

range declarations. Addresses must be correct for the

subnet declaration within which the pool declaration is made. If the pool declara-

tion appears within a

shared-network declaration, the addresses must be on subnets

that were previously declared within the same

shared-network declaration.

You can control address allocation in pools by using the pool permit list—the list of

permit statements that appear in a pool declaration. A permit statement begins with

either the

allow or deny keyword, followed by a statement of what is permitted or

APPENDIX B ISC DHCP Server Configuration File Reference466

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

not permitted. If a pool has a list of things that are permitted, any client that doesn’t

match one of the permits cannot be allocated an address from the pool. If a pool has

a list of things that are not permitted, any client that doesn’t match one of those

permits can be allocated an address from the pool.

The known clients Permit

[ allow | deny ] known clients;

The known clients permit either allows or prevents allocation from a pool to any

client that has a

host declaration (that is, any client that is known).

The unknown clients Permit

[ allow | deny ] unknown clients;

The unknown clients permit either allows or prevents allocation from a pool to any

client that has no

host declaration (that is, any client that is not known).

The members of Permit

[ allow | deny ] members of “class”;

The members of permit either allows or prevents allocation from the pool to any

client that is a member of the named class.

The dynamic bootp clients Permit

[ allow | deny ] dynamic bootp clients;

The dynamic bootp clients permit either allows or prevents allocation from the

pool to any BOOTP client.

The all clients Permit

[ allow | deny ] all clients;

The all clients permit either allows or prevents allocation from the pool to all

clients. This can be useful when you want to write a

pool declaration but you do not

yet want addresses to be allocated from it. You can also use it to force all clients that

were allocated addresses from a pool to obtain new addresses immediately the next

time they renew their leases.

The pool Declaration 467

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

The class Declaration

class “class-name” {

[ statements ]

[ declarations ]

}

You use class declarations to group clients together based on information they send.

A client becomes a member of a class based on the class’s matching rules, or because

the client matches a subclass of that class.

class-name should be the name of the class and is used in members of permit state-

ments, as well as in

subclass declarations for subclasses of the named class.

When a packet is received from a client, every class declaration is examined for a

match, match if, or spawn statement, and that statement is checked to see if the

client is a member of the class.

class scopes are considered to be more specific than pool or subnet declaration

scopes, but they are less specific than

host declaration scopes. (See the section

“Scopes” in Chapter 14 for a description of scopes.)

The match if Statement

match if boolean-expression;

A client is considered a member of a class if, when the server receives a packet from

the client,

boolean-expression evaluates to true. boolean-expression may depend

on the contents of the packet the client sends.

The match Statement

match data-expression;

If data-expression, when evaluated using the contents of a client’s request, returns

a value that matches a subclass of the class in which the

match statement appears,

the client is considered a member of both the subclass and the class. If a

class decla-

ration contains both a

match if statement and a match statement, the match if

statement must match before the match statement is considered.

The spawn with Statement

spawn with data-expression;

If data-expression evaluates to a non-null value, the server looks for a subclass of

the class in which the

spawn with statement appears that matches the result of the

APPENDIX B ISC DHCP Server Configuration File Reference468

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

evaluation. If such a subclass exists, the client is considered a member of both the

subclass and the class. If no such subclass exists, one is created and recorded in the

lease database, and the client is considered a member of the new subclass as well as

the class. The matching data for the subclass is the result of evaluating

data-expres-

sion. If a class declaration contains both a match if statement and a spawn with

statement, the match if statement must match before the spawn with statement is

considered.

The lease limit Statement

lease limit limit;

The lease limit statement causes the DHCP server to limit the number of members

of a class that can hold a lease at any one time to

limit. This limit applies to all

addresses the DHCP server allocates, not just addresses on a particular network

segment. If a client is a member of more than one class with lease limits, the server

assigns the client an address based on either class. If a client is a member of one or

more classes with limits and one or more classes without limits, the classes without

limits are not considered.

NOTE

At the time of this writing, the lease limit statement interacts badly with the DHCP failover

protocol. If you are using failover, you might find that the failover peers give out as many as

twice the number of leases that are specified in the lease limit statement. Unfortunately,

there is no guarantee that this will be consistent; the number of leases that are allowed in the

class can be anywhere from the specified limit to twice the specified limit. It is possible that

this problem might be corrected in a future version of the ISC DHCP server, but this would

not be a simple bug fix, and at the time of this writing, it is impossible to know whether that

will happen.

The subclass Declaration

subclass “class-name” class-data;

subclass “class-name” class-data {

[ statements ]

}

The subclass declaration declares a subclass of the class named by class-name.

class-data should be either a text string enclosed in quotes or a list of bytes

expressed in hexadecimal, separated by colons. Clients match subclasses based on

the results of evaluating the

match or spawn with statements in the class declaration

for

class-name. If the result of the evaluation matches class-data, the client is a

The subclass Declaration 469

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

member of the subclass and the class. Subclasses can have scopes, in which case their

scope is considered to be more specific than the scope of

class-name; if a subclass

has no scope, it inherits the scope of

class-name. (See the section “Scopes” in

Chapter 14 for information about scopes.)

The group Declaration

group {

[ parameters ]

[ declarations ]

}

You can use the group declaration to provide a common scope for whatever is

declared within it. For example, if several

host declarations require the same set of

parameters, you can group them within a

group declaration and you can specify the

statements defining those parameters once in the group scope instead of once in

each

host statement’s scope. (See the section “Scopes” in Chapter 14 for information

about scopes.)

The option space Declaration

option space space-name;

The option space declaration declares a new option space. This declaration must

precede all definitions for options in the space being declared.

space-name should be

the name of the option space. Currently five option space names are predefined:

• The

dhcp option space

• The agent option space

• The server option space

• The nwip option space

• The fqdn option space

The dhcp option space is the default option space. If an option name is specified

without an option space, it is assumed that the name refers to an option in the

dhcp

option space. For example, the option names dhcp.routers and routers are

equivalent.

The

server option space is the option space for defining server parameters. The

following two statements are exactly equivalent:

APPENDIX B ISC DHCP Server Configuration File Reference470

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

option server.filename “foo”;

filename “foo”;

The agent option space is the option space in which relay agent information subop-

tions appear. The

nwip option space is the option space in which NetWare/IP subop-

tions appear. The FQDN option space is an option space that allows the individual

fields of the

client FQDN option to be examined and modified in the DHCP configu-

ration file.

The include Directive

include “filename”;

The include directive inserts the contents of another file in a DHCP configuration

file.

filename is the name of the file to be inserted.

The key Declaration

key name {

algorithm algorithm-name;

secret secret-data;

} [ ; ]

The key declaration defines a secret key that the DHCP program can use for authenti-

cation.

name is the name of the key, which should be a syntactically valid domain

name (the name doesn’t have to appear in the DNS). This name is significant: when

the DHCP server or client sends a message authenticated with the key, the recipient

uses this name to look up the key that it uses to authenticate the message.

algorithm-name is the name of the algorithm to use. Currently, the ISC DHCP distri-

bution supports only the MD5 HMAC algorithm, which can be specified by using

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

secret is a binary secret, represented in base64, which represents the actual shared

secret. The format of the secret is the same as for ISC

BIND, and secret keys can be

generated by using the utilities included with ISC

BIND. This is described in more

detail in Chapter 23, “Configuring DHCP–DDNS Interactions.”

You can include a single file containing key declarations in both the ISC DHCP and

ISC BIND configuration files. Although ISC DHCP and ISC BIND do not use the same

configuration file syntax, the only difference between the key syntax is the semi-

colon after the closing brace in ISC BIND. The ISC DHCP configuration file format

allows this extra semicolon for compatibility with BIND, but it does not require it.

The key Declaration 471

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

The zone Declaration

zone name {

primary primary-address;

[ key key-name; ]

}

The zone declaration defines a DNS zone that the DHCP program can update. name

is the name of the zone, which should be a fully qualified domain name. primary-

address is the IP address to which to send updates for the zone. key-name is the

name of the

key directive that defines the key to use to update the zone. You may

omit the reference to the key if the DNS server does not require that updates to this

zone be authenticated. However, you should use a key even for testing, because in

practice it is easier to get the DNS server to accept an authenticated update than a

non-authenticated update, despite the additional configuration that is required.

The failover peer Declaration

failover peer name {

[ failover statements ]

}

...

pool {

failover peer name;

...

}

The failover peer declaration can take two forms. In the first form, the declaration

defines a DHCP failover protocol peering relationship. The declaration should

contain various failover-specific statements, which are described in the following

sections. In the second form, the declaration references a previously defined failover

declaration.

Any address allocation pool that is to be shared with another DHCP server using the

failover protocol must contain a failover peer reference. Address allocation pools that

do not contain failover peer references are not shared; if the same pool declaration

appears on two DHCP servers without failover, the DHCP servers do not cooperate in

sharing the addresses.

When two DHCP servers independently allocate the same IP addresses, it is very

likely that IP address conflicts will occur. This problem is a dangerous enough that

the ISC DHCP server will refuse to start if you define a failover peer but never refer-

ence it; this usually means that the person writing the failover configuration doesn’t

understand how it must be done.

APPENDIX B ISC DHCP Server Configuration File Reference472

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

The DHCP server can support more than one failover relationship. To make this

happen, you simply write more than one failover peer declaration and reference the

appropriate failover peer declaration for each pool in the pool declaration. This is

explained in more detail in Chapter 18, “Failover Configuration.”

The primary Statement

primary;

The primary statement specifies that in this failover relationship, this DHCP server is

the primary server.

The secondary Statement

secondary;

The secondary statement specifies that in this failover relationship, this DHCP server

is the secondary server.

The address Statement

address ip-address;

The address statement specifies the IP address on which the DHCP server listens for

connections from its failover peer and from which the DHCP server attempts to

connect to its failover peer. You must specify an

address statement in every failover

peer definition.

The peer address Statement

peer address ip-address;

The peer address statement specifies the IP address from which the DHCP server

expects to receive connections from its failover peer and to which the DHCP server

connects when it attempts to connect to its failover peer. You must specify a

peer

address statement in every failover peer definition. The address you specify in the

address statement on each failover peer should be the same address that you specify

in the

peer address statement on the other peer.

The port Statement

port tcp-port;

The port statement specifies the TCP port on which the DHCP server listens for

connections from its failover peer. You must specify a

port statement in every

failover peer definition. The standard port number to use for primary servers is 847;

for secondary servers it is 647.

The failover peer Declaration 473

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

The peer port Statement

peer port tcp-port;

The peer port statement specifies the TCP port to which the DHCP server connects

when it attempts to connect to its failover peer. You must specify a

peer port state-

ment in every failover peer definition. The TCP port number you specify in the

port

statement on each failover peer should be the same port number that you specify in

the

peer port statement on the other peer.

The max-response-delay Statement

max-response-delay seconds;

The max-response-delay statement specifies the number of seconds that can elapse

with the failover connection quiet before the DHCP server assumes that it has lost

contact with its peer. This should normally be no shorter than 60 seconds.

The max-unacked-updates Statement

max-unacked-updates number;

The max-unacked-updates statement specifies the number of binding updates that

the DHCP server can send without receiving any acknowledgements. Each binding

update must be acknowledged, so once the specified number of updates has been

sent, the receipt of only one acknowledgement means that the DHCP server can

send only one more update.

The mclt Statement

mclt seconds;

The mclt statement specifies the minimum client lead time (MCLT) for the failover

relationship. The MCLT should be long enough so that a lease that is

seconds long

will be long enough to be useful but short enough so that if a server entering the

partner-down state has to wait seconds to reclaim the peer’s leases, this will not be a

serious problem. The

mclt statement can be specified only on the primary peer.

The hba and split Statements

hba colon-separated-hex-list;

split number;

APPENDIX B ISC DHCP Server Configuration File Reference474

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

The hba and split statements provide two different ways of specifying the hash

bucket assignment (HBA) for load balancing. The

hba statement allows each bit in

the hash bucket to be specified individually, whereas the

split statement allows the

HBA to be specified as a ratio.

number is the smaller number in the ratio, and 256 is

always the larger number, so a split of 128 splits clients evenly between the two

failover peers. There is no real reason to ever use a split value other than 128. Every

primary failover peer definition must include one of these two statements. Secondary

failover peer definitions must not include either statement.

The load balance max secs Statement

load balance max secs seconds;

If the secs field of the DHCP packet has a value that is greater than the value speci-

fied in

load balance max secs, that will not cause the DHCP server receiving the

packet bypasses load balancing. Most DHCP clients report in the

secs field of the

DHCP packet the number of seconds since they first attempted a transaction. The

longer the client has been attempting a transaction without success, the more likely

it is that the failover peer that should be responding to the client is unable to

respond to do so. A value of 3 seconds is generally recommended.

Programming Statements

The ISC DHCP server provides the ability to conditionally evaluate statements based

on the values the client sends, and also to set and unset variables and to log

messages to the system logger. Chapter 20 describes how you can do this.

The if Statement

if boolean-expression {

[ statements ]

}

The most basic conditional statement is the if statement. If boolean-expression

evaluates to true, the statements enclosed in braces following boolean-expression

are executed. If boolean-expression evaluates to false, those statements are

skipped.

The else Clause

if boolean-expression {

[ statements ]

} else {

[ statements ]

}

Programming Statements 475

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