Droms R. The DHCP handbook
Подождите немного. Документ загружается.
023 3273 CH19 10/3/02 4:58 PM Page 336
IN THIS CHAPTER
•Differentiating Between
Clients
• Controlling Address Allocation
•Client Class Options
• Lease Events
• Lease Variables
20
Programmable DHCP
Server Customization
A few of the preceding chapters discuss how to set up the
DHCP server so that it configures all clients with essen-
tially the same parameters. They also show some simple
ways to specify whether the server provides addresses to
specific clients or to clients the server doesn’t know about.
To configure computers on the network without DHCP,
you must manually configure each computer individually.
Although this is a tedious process, it gives you one advan-
tage: You can customize each computer’s configuration
based on its user’s needs rather than configure all systems
identically.
This chapter describes how to program the ISC DHCP
server so that it can perform many of the same customiza-
tions you might perform when configuring clients manu-
ally, as well as some automatic customizations that are
difficult to perform manually. It also shows how to classify
clients more accurately, and it describes the capabilities of
the ISC DHCP server class construct. You will learn how to
set up different address allocation pools so that you can
use different address allocation strategies for different
clients. In addition, you will learn how to send different
parameters or use different settings for specific clients,
different classes of clients, and clients whose addresses
come from different pools.
For the most part, this level of customization is specific to
the ISC DHCP server version 3.0 and higher.
Customizations that are also possible for the Microsoft
Windows 2000 DHCP server are noted where appropriate.
024 3273 CH20 10/3/02 5:00 PM Page 337
Differentiating Between Clients
The DHCP server differentiates between clients based on what each client sends to
the server in its messages. Chapter 16, “Client Identification and Fixed-Address
Allocation,” discusses how the DHCP server identifies a specific client by using either
the DHCP
client identifier option or the client’s link-layer address.
The DHCP server can also make decisions about a client based on other options the
client sends or on the other contents of the client’s packet. Unlike the
client iden-
tifier option and link-layer address, the other contents of a DHCP packet generally
aren’t guaranteed to be unique. Configuring the server to use them to differentiate
between clients enables you to control the server’s behavior with respect to classes of
clients, rather than just to specific individual clients.
Conditional Statements
The simplest way to differentiate between clients is to use conditional statements.
Conditional statements work by testing some logical expression; if the result of evalu-
ating that expression is
true, the statements that are enclosed in the conditional
statement are executed (for example, some special configuration parameters or
options might be defined). If the result of evaluating an expression is
false or null,
the statements are not executed.
NOTE
You can use many different kinds of expressions to determine what sort of client sent a
request. Appendix B, “ISC DHCP Server Configuration File Reference,” provides a complete list
of the different kinds of expressions that the DHCP server recognizes.
If you provide an else clause, the parameters or options within the else clause are
defined. You can chain together a series of
if statements by using the elsif state-
ment as well.
Consider an installation where IP addresses are in somewhat short supply, so the
administrator needs to configure the DHCP server not to allocate leases for longer
than they will be used. At this site, all site-owned computers are registered with the
DHCP server by using
host declarations. The site owns a number of printers that
support TCP/IP. These printers send the vendor class identifier
acme-printers. The
site administrators don’t register these printers because they’re easy to identify. The
site also provides IP addresses to visiting mobile clients. Example 20.1 shows how to
give long leases to the printers, shorter leases to site-owned machines, and very short
leases to visiting mobile clients.
CHAPTER 20 Programmable DHCP Server Customization338
024 3273 CH20 10/3/02 5:00 PM Page 338
Example 20.1
if known {
max-lease-time 18000;
default-lease-time 18000;
} elsif option vendor-class-identifier = “acme-printers”
max-lease-time 90000;
default-lease-time 90000;
} else {
max-lease-time 300;
default-lease-time 300;
}
In Example 20.1, the known expression is used to test whether a client has a host
declaration. For clients that have host declarations, the default lease time is 18,000
seconds; the maximum lease time is also 18,000 seconds. Clients that don’t have
host declarations but send the vendor class identifier option acme-printers get
longer lease times. All other clients receive much shorter lease times.
NOTE
The ISC DHCP server also provides a switch statement, which functions in much the same
way as the C switch statement or the LISP cond statement (the syntax is similar to C, but the
semantics are more similar to LISP). This is described in Appendix B.
You can also nest conditional statements. Example 20.2 shows a configuration
similar to the one mentioned previously, except that there is a special case for
Microsoft RAS servers. RAS servers tend to ask for leases they don’t need and then
forget they got them, so generally it is a good idea not to give addresses to RAS
servers. If you must give an address to a RAS server, it should have a very short lease,
so that when the RAS server forgets about it, the address can be quickly reclaimed.
Example 20.2
if substring (option dhcp-client-identifier, 1, 3) = “RAS” {
if not known {
ignore booting;
} else {
max-lease-time 300;
default-lease-time 300;
}
} elsif known {
max-lease-time 18000;
default-lease-time 18000;
Differentiating Between Clients 339
024 3273 CH20 10/3/02 5:00 PM Page 339
} else {
max-lease-time 300;
default-lease-time 300;
}
Example 20.2 checks to see whether the second through the fourth byte of the
DHCP
client identifier option is the string “RAS”. If it is, the client is a Microsoft
RAS server. If it is a RAS server and if no
host declaration for that particular client
exists, it is not given an IP address; the message is simply ignored. If the RAS server
has a
host declaration (that is, it is known), it gets a very short lease. If the client
identifier option wasn’t sent or doesn’t begin with RAS, but the client is known, it
gets a long lease. If the client is not known, it gets a very short lease.
NOTE
You can only use conditional statements to conditionalize option and parameter definitions.
You cannot conditionally define a new option because new option definition happens when
the configuration file is processed. Likewise, it’s not possible to conditionally define hosts,
subnets, shared networks, groups, pools, address ranges, leases, or permits because all these
declarations are processed when the configuration file is parsed, not when a client request
comes in.
Client Classing
The ISC DHCP server provides a construct called a class that you can use to group
clients in a more general manner than you can with a
host declaration. Like host
declarations and subnet declarations, classes have scope. (See Chapter 14, “The ISC
DHCP Server.”) You can also use a client’s membership in a class to control how
addresses are allocated to it.
Clients become members of classes either because they match a class’s matching rule
or because they match a subclass of that class. Class-matching rules are evaluated
before any conditional statements that may exist in any scope. Currently, a client
can be a member of up to five classes. This limit is arbitrary and might be eliminated
in the future.
Class-matching rules are evaluated in the order in which the classes are originally
declared. For example, if a client matches two classes based on those classes’ match-
ing rules, the scope of the class declared first in the configuration file is considered
more specific than the scope of the class declared second.
CHAPTER 20 Programmable DHCP Server Customization340
Example 20.2 Continued
024 3273 CH20 10/3/02 5:00 PM Page 340
Class-Matching Rules
Two kinds of class-matching rules exist: explicit rules and subclass-matching rules. In
Example 20.3, if a client sends the
vendor class identifier option acme-printers
or united-printers, it is considered to be in the class printers. If it sends a DHCP
client identifier option that starts with the string RAS, it is a member of the ras-
clients class. As an example of class-based scoping, members of the printers class
receive long lease times, whereas members of the
ras-clients class receive very
short lease times. Of course, if a more specific scope overrides the class scope’s defini-
tion of the
domain-name option, the particular client receives the option from the
more specific scope. The only scopes that are more specific than a class scope are the
scope of another class that appears earlier in the configuration file and the scope of a
host declaration.
Example 20.3
class “printers” {
match if option vendor-class-identifier = “acme-printers” ||
option vendor-class-identifier = “united-printers”;
default-lease-time 18000;
max-lease-time 18000;
}
class “ras-clients” {
match if substring (option dhcp-client-identifier, 1, 3) = “RAS”;
default-lease-time 300;
max-lease-time 300;
}
Subclass Matching
As discussed earlier in this chapter, you can use
host declarations to group clients as
either known or unknown. You can also use this feature to differentiate between
clients that are registered with the network administrator and clients that are not.
However, you might want to divide clients into more than two sets—those that are
registered and those that are not.
For example, consider an ISP that sells broadband service. At each customer site,
there is a cable modem. Whenever a DHCP request comes in from a client computer
that is attached to the cable modem, the cable modem attaches a
relay-agent-
information option to the request. The cable modem vendor would like to be able to
provide different levels of service to some clients than to others, depending on what
they have paid for.
Master classes and subclasses provide an efficient method of matching many differ-
ent possible values that might result from evaluating some expression. Instead of
specifying a
match if statement, as in an explicit class declaration, a master class
Differentiating Between Clients 341
024 3273 CH20 10/3/02 5:00 PM Page 341
has a match statement with an expression that extracts some data from the client’s
DHCP packet. Each
subclass declaration refers to its master class by name and
includes in its declaration a value for the master class’s
match expression. If the value
extracted from the client’s DHCP packet matches the value specified in the
subclass
declaration, the client matches the master class and the subclass.
When you’re determining membership, if a client is a member of a particular
subclass, it’s also a member of the master class. Indeed, you cannot check that it is a
member of the subclass because the subclass has the same name as the master class.
Subclass scopes are considered more specific than master-class scopes. Subclasses are
not, however, required to have scopes, and not specifying a scope saves memory.
Example 20.4 shows an example of a
class declaration and several subclass declara-
tions, using the DHCP
client identifier option to differentiate between clients.
One subclass has its own scope; the other two do not.
Example 20.4
class “engineering” {
match option dhcp-client-identifier;
}
subclass “engineering” “amee-pc”;
subclass “engineering” 1:00:00:ac:42:a9:a6 {
option root-path “server1.example.com:/var/clients/root-netbsd”;
}
subclass “engineering” “nilo1”;
As you can see from this example, it is possible that some matching data will be in
the form of an ASCII string and some will be in the form of a sequence of hexadeci-
mal bytes separated by colons. You might have noticed that
subclass declarations
look very much like
host declarations. Indeed, in many cases you can use them in
exactly the same way. However, you can’t specify a fixed address in a
subclass decla-
ration, and, as Chapter 16 describes, the method a DHCP server uses to determine a
client’s identity is more complicated than a simple pattern match.
Controlling Address Allocation
You can control address allocation in two ways:
•You can group one or more ranges of addresses into a pool declaration and
then control access to those pools by using permit lists. These permit lists can
be based on the client’s class, known/unknown status, or protocol.
CHAPTER 20 Programmable DHCP Server Customization342
024 3273 CH20 10/3/02 5:00 PM Page 342
•You can specify a limit to the number of leases that members of a particular
class can hold at any one time. You can configure the DHCP server to automat-
ically create new classes and apply lease limits to them.
You can also combine these two mechanisms.
Pool-Based Address Allocation
An address allocation pool is a group of addresses that can be allocated on a particular
network segment. A pool can contain addresses from more than one subnet, as long
as all the subnets are configured on the same network segment.
Allocation Based on Class Membership
Example 20.5 shows clients from different classes grouped onto different subnets
that are configured on the same network segment. The first pool has a permit list
that enables only clients in the
engineering class to be assigned addresses. The
second pool’s permit list enables only clients in the
sales class, and the third pool
prohibits members of the
engineering and sales classes from being assigned
addresses, which means all other clients will be assigned addresses from that pool.
A pool’s permit list is the set of all
allow and deny statements within the pool
declaration.
Example 20.5
shared-network BUILDING-1-LAN {
subnet 10.227.109.0 netmask 255.255.255.0 {
option routers 10.227.109.1;
option domain-name-servers 10.227.109.2;
pool {
range 10.227.109.10 10.227.109.254;
allow members of “engineering”;
}
}
subnet 10.227.110.0 netmask 255.255.255.0 {
option routers 10.227.110.1;
option domain-name-servers 10.227.110.2;
pool {
range 10.227.110.10 10.227.110.254;
allow members of “sales”;
}
}
subnet 10.228.0.0 netmask 255.255.255.0 {
option routers 10.228.0.1;
Controlling Address Allocation 343
024 3273 CH20 10/3/02 5:00 PM Page 343
option domain-name-servers 10.228.0.2;
pool {
range 10.228.0.10 10.228.0.254;
deny members of “engineering”;
deny members of “sales”;
}
}
}
Example 20.5 shows pools used to contain address ranges on different subnets.
However, it is also possible to have more than one allocation pool on the same
subnet. For example, you might want to reserve a small pool on each subnet on a
network for unregistered clients and reserve the rest of the IP addresses for registered
clients.
Other Allocation Controls
In addition to permitting or denying access to a particular pool based on the class to
which a client belongs, you can permit or deny pool access in several other ways.
You can permit allocation based on whether a client has a host declaration, by using
the
allow known clients directive or the allow unknown clients directive. You can
also permit or deny allocation of addresses to BOOTP clients by using the
allow
dynamic bootp clients directive. Finally, it is possible to explicitly permit or deny
all access to a pool by using the
allow all clients directive or the deny all
clients directive.
Class-Based Address Allocation
Sometimes it is useful to restrict the number of addresses assigned to a class of clients
without reserving a specific pool of addresses for the members of that class.
Reserving a pool requires either that the maximum number of addresses permitted to
each class is reserved at all times or that the pool of available addresses for all
permitted classes is shared in an uncontrolled manner.
For example, consider the broadband ISP mentioned earlier in this chapter. This ISP
has one large network segment that serves all client sites. (In practice, the network
might be segmented, but we’ll assume that the network has a single network
segment for simplicity.) Each site has a cable modem that accesses the network by
exchanging packets with a head-end system at the ISP. Whenever a DHCP client at
a client site broadcasts a DHCP request, the cable modem relays that request to
the central DHCP server after attaching a
relay agent information option that
contains the
circuit ID and remote ID agent options. The remote ID is always
unique to the customer site.
CHAPTER 20 Programmable DHCP Server Customization344
Example 20.5 Continued
024 3273 CH20 10/3/02 5:00 PM Page 344
This cable modem provider might want to enable customers to obtain more than
one IP address, but it does not want to enable customers to obtain an unlimited
number of IP addresses. The provider can do this by declaring a subclass for each
client site, based on the contents of the
relay agent information option, and by
specifying a limit on the number of leases that members of that class can obtain. The
fact that the
relay agent information option is appended to every client packet
relayed from a particular customer site and is the same for every host at that site
restricts the number of leases that DHCP clients at that site can obtain. Example 20.6
shows how this can be done.
Example 20.6
class “customer-sites” {
match option agent.remote-id;
lease limit 1;
}
subclass “customer-sites” 0:42:77:a9:c6;
subclass “customer-sites” 17:a8:ee:0:0;
subclass “customer-sites” f7:aa:90:1c:2b;
subclass “customer-sites” 27:c9:45:12:a0;
subclass “customer-sites” 99:91:a0:1c:22;
In Example 20.6, the lease limit is specified as 1 in the master class. The subclasses
inherit the lease limit from the master. This means that only one member of each
subclass can hold a lease at any one time. One IP address is fine for a normal home
subscriber, but suppose the ISP in our example sells to businesses as well, using
the same distribution system. A business site might need more than one globally
routable IP address. In this case, the ISP might write a special
subclass statement for
that business, specifying a larger limit, as shown in Example 20.7.
Example 20.7
subclass “customer-sites” 99:91:a0:1c:22 {
lease limit 8;
}
NOTE
If a client is a member of a class that limits the number of leases allocated to it but is also a
member of a class that doesn’t, it can get an IP address only through the class that limits lease
allocation. If a client is a member of two classes that limit lease allocation and one is full but
the other is not, its lease is allocated from the class that is not full.
Controlling Address Allocation 345
024 3273 CH20 10/3/02 5:00 PM Page 345