Droms R. The DHCP handbook
Подождите немного. Документ загружается.
NOTE
The lease limit feature of the ISC DHCP server depends on the DHCP server having a clear
idea of how many leases are allocated to a particular class. If you are using the failover proto-
col, there is no way for this to happen; depending on which leases are renewed on which
servers, it is possible that twice as many leases will be allocated as you intend. It is also possi-
ble that exactly the number of leases you intend will be allocated. Therefore, you cannot
implement a reliable lease limiting system with failover. It might be possible to modify the ISC
DHCP server to do a better job, but at the time of this writing, nobody is doing so.
Automatic Generation of Subclasses
To further automate the process of setting lease limits at customer sites, it is possible
for the ISC DHCP server to create subclasses automatically, based on the matching
expression in the master class. These classes are then recorded in the lease database
so that they persist across restarts of the DHCP server. This is a handy way to get the
address allocation limiting described earlier without requiring anybody to, for
example, register specific cable modem remote IDs with the DHCP server. Example
20.8 shows an example of a master class that automatically spawns subclasses.
Example 20.8
class “customer-sites” {
spawn with option agent.remote-id;
lease limit 1;
}
In Example 20.8, whenever a request is received from a client that contains the
relay agent information option and a remote ID suboption, the server looks up
that suboption in the class’s hash table. If that suboption is present, the existing
subclass is used. Otherwise, a new subclass is allocated and recorded in the lease
database, and that new class is used to account for leases in use at that site.
NOTE
Spawning classes can be combined with predefined subclasses because the spawn with and
match with statements both have the same effect if the class they match already exists. To do
this, you use spawn with instead of match with, as in Example 20.6.
Differentiation Between Similar Sets of Subclasses
In some cases it might be helpful to use spawning classes as described earlier in this
chapter but group clients into different sets of subclasses as well. The
spawn with
CHAPTER 20 Programmable DHCP Server Customization346
024 3273 CH20 10/3/02 5:00 PM Page 346
statement for each class might be identical. When this is case, you can use a match
if statement along with the spawn with statement. For example, suppose the broad-
band ISP we’ve been using as an example sells two different kinds of circuits, with
different circuit IDs, and the first 4 bytes of the circuit ID are the speed, in kilobits
per second. A customer that purchases the 1544Kbps connection is allowed up to
eight globally routable IP addresses. A customer that purchases the 256Kbps connec-
tion is allowed only one. Example 20.9 shows how this can be configured.
Example 20.9
class “slow-sites” {
match if substring (option agent.circuit-id, 0, 4) = “0256”;
spawn with option agent.remote-id;
lease limit 1;
}
class “fast-sites” {
match if substring (option agent.circuit-id, 0, 4) = “1544”;
spawn with option agent.remote-id;
lease limit 8;
}
You can also use the match if statement with a match statement, when predefined
subclasses are being used.
Client Class Options
Two options are defined in DHCP specifically for the purpose of grouping DHCP
clients into classes: the
user class option and the vendor class identifier
option. The ISC DHCP server doesn’t actually treat these options specially, but they
have special meanings that relate to client classification. Another class-related option
is the
vendor-specific information option, which is treated specially by the DHCP
server.
The user class Option
Using the user class option, which is defined in RFC 3004, is a very simple way to
classify clients based on information that is supplied by the user. The
user class
option contains one or more attributes, each of which can be any arbitrary string of
bytes. Because the
user class option is intended to be specified by the user of the
computer, each attribute is normally a human-readable ASCII text string. Most DHCP
clients allow the user to specify only a single attribute. DHCP clients can send this
string to the DHCP server to specify attributes that apply the user who is using the
Client Class Options 347
024 3273 CH20 10/3/02 5:00 PM Page 347
machine. For example, if you support a sales department, an engineering depart-
ment, and a support department, you might configure sales machines to report a
user class attribute of “sales”, engineering might report “eng”, and support might
report “
support”. You can then use this information to classify the client, as shown
in Example 20.10.
Example 20.10
class “sales” {
match if option user-class = “sales”;
}
class “engineering” {
match if option user-class = “engineering”;
}
class “support” {
match if option user-class = “support”;
}
NOTE
When it was originally defined, the user class option allowed the user to specify only a
single attribute. Several widely deployed DHCP clients, including the Microsoft and ISC
clients, support the old single-attribute user class option. Example 20.10 shows the single-
attribute user class option. Although RFC 3004 is a standard, we can’t show you an
example of a multi-attribute user class option yet because none of the servers we have
access to implement the RFC 3004 user class option.
For this option to be useful, you must configure it into each DHCP client at your
site. The presumption is that every time a new DHCP-enabled workstation is
installed, either the network administrator or the user configures that workstation
with some kind of class identifier. Some modern DHCP clients, including those
supplied by Microsoft and ISC, provide a way for the user to specify a user class.
The
user class option violates one important precept of DHCP: that the DHCP
server, not the user, configures the TCP/IP configuration. However, in practice,
getting users to set their
user class option is not too hard. Unlike IP addresses, user
class identifiers are normally human-readable text strings that make sense even to
novice users.
The vendor class identifier Option
The vendor class identifier option is intended for use by DHCP client vendors,
to identify the vendor that supplied the DHCP client and, possibly, to provide identi-
fication information about the hardware on which the DHCP client is running. The
CHAPTER 20 Programmable DHCP Server Customization348
024 3273 CH20 10/3/02 5:00 PM Page 348
vendor defines the format of the vendor class identifier option. Currently, no
process exists whereby vendors can ensure that the identifier they choose is unique
to them. However, vendors usually use trademarked company names, so conflicts are
unlikely. The Sun implementation of the
vendor class identifier option is used
here as an example of how this option works.
Sun specifies vendor class identifiers as ASCII text strings, with information about
the client encoded as a series of labels separated by periods. The leftmost label is
most general, with labels becoming more specific toward the right. For example, the
most general label is
SUNW, indicating that the computer is a Sun workstation, and a
Sun SPARC Ultra 5/10 workstation sends a vendor class identifier of
SUNW.Ultra-
5_10. Ultra-5_10 encodes the specific hardware type. A PC running Solaris identifies
itself with the vendor class identifier of
SUNW.i86pc.
A workstation with a SPARC processor running Solaris might require somewhat
different options than a workstation with a processor from the Intel x86 family
running Solaris, and you need to configure it accordingly. Example 20.11 shows how
to send a different
root-path option for these two processor architectures.
Example 20.11
if option vendor-class-identifier = “SUNW.Ultra-5_10” {
option root-path “/export/root/sparc”;
} else if option vendor-class-identifier = “SUNW.i86pc” {
option root-path “/export/root/i86pc”;
}
Example 20.11 is somewhat simplistic; if you support DHCP clients that are supplied
by other vendors, you might end up with a long list of
if, elsif, and else state-
ments. Also, you might support several different types of Sun SPARC hardware and
might want to specify the same behavior for all these types without listing them all
explicitly.
Example 20.12 shows a more general case than Example 20.11. It first checks to see
whether the
vendor class identifier option starts with the string SUNW., and then
it checks the next five characters in the option to see what kind of Sun workstation
sent the request, using the
switch statement.
Example 20.12
if substring (option vendor-class-identifier, 0, 5) = “SUNW.” {
switch (substring (option vendor-class-identifier, 5, 5)) {
case “Ultra”:case “Sparc”: option root-path “/export/root/sparc”;
Client Class Options 349
024 3273 CH20 10/3/02 5:00 PM Page 349
break;
case “i86pc”:
option root-path “/export/root/i86pc”;
break;
}
}
This is a very straightforward example of using the vendor class identifier
option. You can also use the vendor class identifier option as a key with which
to address and encapsulate a series of vendor-specific options.
The vendor-specific information Option
Chapter 6, “The Format of DHCP Messages,” describes the format of DHCP messages
and, in particular, the format of the DHCP
options field. The vendor-specific
information option is actually a DHCP option whose length is variable. It contains
either uninterpreted vendor-specific data or a sequence of option tags, lengths, and
option data, in the same format as the
options field itself.
Example 20.13 shows an example of a vendor-specific information option that
contains vendor-specific option tags. It starts with the code for the
vendor-specific
information option, 43, followed by the length, and finally the payload. The
payload is a sequence of two vendor-specific options, Options 1 and 2. Option 1 is
an IP address (10.0.0.1 in Example 20.13), and Option 2 is a 32-bit number
(227883991).
Example 20.13
43 12 1410001241314959215
The ISC DHCP server enables you to define vendor-specific option spaces and then
define options within those spaces. You can then direct the DHCP server to use
option spaces you have defined to generate the
vendor-specific information
option. Option spaces are described in Chapter 14.
A HYPOTHETICAL EXAMPLE OF THE VENDOR-SPECIFIC INFORMATION OPTION
Suppose you set up a DHCP server for use in a bank branch. The bank purchased a
customized turnkey system for operating each branch; each teller gets a workstation, and a
central server runs a couple proprietary protocols. The vendor defines a set of DHCP options
used to configure the teller workstations. (Let’s call the vendor ExampleSoft and use the
vendor’s name for the option space.) The vendor must send two pieces of information to each
workstation: the IP address of the central server and a token that the client workstation uses
to identify its location to the central server, which might actually support more than one
CHAPTER 20 Programmable DHCP Server Customization350
Example 20.12 Continued
024 3273 CH20 10/3/02 5:00 PM Page 350
branch. The two options are called central-server and site-token, respectively.
Example 20.14 shows how these options are introduced to the DHCP server.
Example 20.14
option space ExampleSoft;
option ExampleSoft.central-server code 1 = ip-address;
option ExampleSoft.site-token code 2 = integer 32;
The site also has some networked printers that get their IP addresses by using DHCP and do
not require the ExampleSoft vendor-specific options. Meanwhile, the branch manager has in
her office a workstation running NetBSD that she uses to exchange e-mail with other branch
managers and to prepare presentations. Example 20.15 shows the use of the
vendor-option-
space
statement to indicate that the ExampleSoft option space should be used to generate
the vendor-specific information option, but only if the vendor class identifier option
the client sent consists of the string ExampleSoft. This example also shows two subnet decla-
rations for different branches that are served by the DHCP server and by the ExampleSoft
branch server. It also shows how vendor-specific options can vary by scope, just like any other
options.
Example 20.15
if option vendor-class-identifier = “ExampleSoft” {
vendor-option-space ExampleSoft;
}
option ExampleSoft.central-server 10.0.0.1;
option domain-name-servers 10.0.0.11, 10.0.0.12;
subnet 10.0.10.0 netmask 255.255.255.0 {
range 10.0.10.10 10.0.10.200;
option routers 10.0.10.1;
option domain-name “101-main.photon-bank.com”;
option ExampleSoft.site-token 227883991;
}
subnet 10.0.11.0 netmask 255.255.255.0 {
range 10.0.11.10 10.0.11.200;
option routers 10.0.11.1;
option domain-name “250-university.photon-bank.com”;
option ExampleSoft.site-token 198283471;
}
When a client sends a request that includes a vendor class identifier option whose value
is ExampleSoft, the DHCP server iterates through the in-scope definitions of all the options in
that class to create a vendor-specific option buffer that contains all the options. It then encap-
sulates that option buffer as the payload of the vendor-specific information option. The
sequence of bytes shown in Example 20.16 is the vendor-specific information option that
is returned to one of the teller workstations that is connected to the 10.0.10.0 subnet.
Client Class Options 351
024 3273 CH20 10/3/02 5:00 PM Page 351
Lease Events
The ISC DHCP server provides a way to specify actions to take when certain events
happen with respect to leases. These events are the
commit event, the expiry event,
and the
release event. These events can be used for a variety of purposes, including
for custom DNS update support and event logging. Example 20.16 shows how to
cause the DHCP server to log a message when a client’s lease expires.
Example 20.16
on expiry {
log (info, concat (“Lease “,
binary-to-ascii (10, 8, “.”, leased-address),
“ has expired.”)));
}
Lease Variables
It is possible to store variables on leases. Each lease has its own variable namespace,
so, for example, two leases could both have a variable named
my-mx-name. The DNS
update code uses lease variables to record information about the DNS update.
Example 20.17 shows how to add a Mail Exchanger (MX) record to the DNS when-
ever the DHCP server successfully updates the DNS.
Example 20.17
on commit {
if (exists (ddns-fwd-name) and (not exists (ddns-mx-name))) {
switch (ns-update (add (IN, MX, ddns-fwd-name,
“mail.fugue.com”, lease-time / 2))) {
case NOERROR:
set ddns-mx-name = ddns-fwd-name;
on expiry | release {
eval ns-update (delete (IN, MX, ddns-mx-name));
unset ddns-mx-name;
}
}
}
}
In Example 20.17, the configuration file contains executable code for the commit
event. The commit event happens whenever a lease is committed. When the commit
event occurs on a lease, this commit event code checks to see whether the variable
CHAPTER 20 Programmable DHCP Server Customization352
024 3273 CH20 10/3/02 5:00 PM Page 352
ddns-fwd-name exists. If it does, this indicates that the DHCP server has successfully
done a DNS update for this client. The
commit code also checks to see whether it has
already added an MX record, by checking the value of the
ddns-mx-name variable.
The
commit event happens every time the lease is renewed, not just the first time, so
if the
commit code didn’t check, it would re-add the MX record whenever the lease
was renewed.
If the
commit code hasn’t yet added an MX record, it tries to add it. The code in
Example 20.17 tests the result of the update by using the
switch statement. If the
result is
NOERROR, meaning that the update succeeded, the commit code sets the ddns-
mx-name variable. This allows it to remember to remove the MX record later and also
not to keep trying to add it after it has been added for the first time. The
commit
code then adds code to execute when the lease expires or is released, using the
expiry event and the release event. The expiry and release event code deletes the
MX record when the lease expires or is released. This event also unsets the
ddns-mx-
name variable because if it is not unset, it remains on the lease even though the lease
has expired.
Summary
The ISC DHCP server provides a powerful collection of tools you can use to differen-
tiate between clients. You can instruct the server to return different options to differ-
ent clients based on what the clients send.
Options can be grouped into classes. You can do this either by testing for options
that many clients send, by having each client’s scope determine its class (for
example, with
host declarations), by predefining subclasses, or by configuring the
server to automatically spawn new subclasses. You can control address allocation
policy based on the classes of which clients are members, as well as whether clients
have
host declarations and whether they use BOOTP or DHCP. You can also limit the
number of members of a particular class that can hold a lease at the same time. To
automate per-class lease limits, you can configure the server to generate new
subclasses as it runs.
Several options are designed specifically for use in classifying clients. Clients can be
configured to send the
user class option to indicate what class of user is using
them, although the
user class option is unfortunately not widely supported. Some
vendors’ clients also use the
vendor class identifier option to identify the vendor
that sent the option. The
vendor class identifier option can also be used to
determine the contents of the
vendor-specific information option.
You can program the server to take action when various events happen in the life-
time of a lease and to store variables on the lease for use when events occur.
Summary 353
024 3273 CH20 10/3/02 5:00 PM Page 353
024 3273 CH20 10/3/02 5:00 PM Page 354
IN THIS CHAPTER
• The Theory of DHCP Client
Operation
• The Microsoft DHCP Client
• The dhcpcd DHCP Client
• The pump DHCP Client
• The ISC DHCP Client
• The Apple MacOS X DHCP
Client
21
DHCP Clients
Previous chapters describe in great detail DHCP and
various aspects of how DHCP servers work and are config-
ured. This chapter describes the following:
• How a DHCP client works
• Some specific DHCP clients and what is unusual
about them
• Some of the problems you might have when using or
providing DHCP service for clients
The Theory of DHCP Client Operation
This chapter uses the ISC DHCP client as a basis for
describing the theory of operation of DHCP clients; the
ISC DHCP client is the most general of the several open-
source DHCP clients that are available. This chapter then
goes on to describe the operation of a variety of DHCP
clients.
The ISC DHCP client runs as a daemon process; that is, it
is started when the computer first starts up, and it contin-
ues to run as an independent process until the computer is
halted. Other clients may use a different implementation
strategy. The DHCP client drives the DHCP protocol; it has
an internal state machine that makes transitions as the
client moves through the protocol. The DHCP client finite
state machine is illustrated in Figure 8.1 and described in
more detail in Chapter 8, “DHCP Message Exchanges.”
Getting an IP Address
When the client is first started, it reads in a database of old
leases, examines each lease in the database, and discards
each lease that has expired. If any leases remain when this
025 3273 CH21 10/3/02 4:57 PM Page 355