dhcpd.conf.5

DHCP服务器源码

.I mclt
statement
.RS 0.25i
.PP
.B mclt \fIseconds\fR\fB;\fR
.PP
The \fBmclt\fR statement defines the Maximum Client Lead Time.   It
must be specified on the primary, and may not be specified on the
secondary.   This is the length of time for which a lease may be
renewed by either failover peer without contacting the other.   The
longer you set this, the longer it will take for the running server to
recover IP addresses after moving into PARTNER-DOWN state.   The
shorter you set it, the more load your servers will experience when
they are not communicating.   A value of something like 3600 is
probably reasonable, but again bear in mind that we have no real
operational experience with this.
.RE
.PP
The 
.I split
statement
.RS 0.25i
.PP
.B split \fIindex\fR\fB;\fR
.PP
The split statement specifies the split between the primary and
secondary for the purposes of load balancing.   Whenever a client
makes a DHCP request, the DHCP server runs a hash on the client
identification.   If the hash comes out to less than the split value,
the primary answers.   If it comes out to equal to or more than the
split, the secondary answers.   The only meaningful value is 128, and can
only be configured on the primary.
.RE
.PP
The 
.I hba
statement
.RS 0.25i
.PP
.B hba \fIcolon-separated-hex-list\fB;\fR
.PP
The hba statement specifies the split between the primary and
secondary as a bitmap rather than a cutoff, which theoretically allows
for finer-grained control.   In practice, there is probably no need
for such fine-grained control, however.   An example hba statement:
.PP
.nf
  hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
      00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;
.fi
.PP
This is equivalent to a \fBsplit 128;\fR statement.  You must only have
\fBsplit\fR or \fBhba\fR defined, never both.  For most cases, the
fine-grained control that \fBhba\fR offers isn't necessary, and \fBsplit\fR
should be used.  As such, the use of \fBhba\fR is deprecated.
.RE
.PP
The 
.I load balance max seconds
statement
.RS 0.25i
.PP
.B load balance max seconds \fIseconds\fR\fB;\fR
.PP
This statement allows you to configure a cutoff after which load
balancing is disabled.  The cutoff is based on the number of seconds
since the client sent its first DHCPDISCOVER or DHCPREQUEST message,
and only works with clients that correctly implement the \fIsecs\fR
field - fortunately most clients do.  We recommend setting this to
something like 3 or 5.  The effect of this is that if one of the
failover peers gets into a state where it is responding to failover
messages but not responding to some client requests, the other
failover peer will take over its client load automatically as the
clients retry.
.RE
.SH CLIENT CLASSING
Clients can be separated into classes, and treated differently
depending on what class they are in.   This separation can be done
either with a conditional statement, or with a match statement within
the class declaration.   It is possible to specify a limit on the
total number of clients within a particular class or subclass that may
hold leases at one time, and it is possible to specify automatic
subclassing based on the contents of the client packet.
.PP
To add clients to classes based on conditional evaluation, you can
specify a matching expression in the class statement:
.PP
.nf
class "ras-clients" {
  match if substring (option dhcp-client-identifier, 1, 3) = "RAS";
}
.fi
.PP
Note that whether you use matching expressions or add statements (or
both) to classify clients, you must always write a class declaration
for any class that you use.   If there will be no match statement and
no in-scope statements for a class, the declaration should look like
this:
.PP
.nf
class "ras-clients" {
}
.fi
.SH SUBCLASSES
.PP
In addition to classes, it is possible to declare subclasses.   A
subclass is a class with the same name as a regular class, but with a
specific submatch expression which is hashed for quick matching.
This is essentially a speed hack - the main difference between five
classes with match expressions and one class with five subclasses is
that it will be quicker to find the subclasses.   Subclasses work as
follows:
.PP
.nf
class "allocation-class-1" {
  match pick-first-value (option dhcp-client-identifier, hardware);
}

class "allocation-class-2" {
  match pick-first-value (option dhcp-client-identifier, hardware);
}

subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
subclass "allocation-class-1" 1:0:0:c4:aa:29:44;

subnet 10.0.0.0 netmask 255.255.255.0 {
  pool {
    allow members of "allocation-class-1";
    range 10.0.0.11 10.0.0.50;
  }
  pool {
    allow members of "allocation-class-2";
    range 10.0.0.51 10.0.0.100;
  }
}
.fi
.PP
The data following the class name in the subclass declaration is a
constant value to use in matching the match expression for the class.
When class matching is done, the server will evaluate the match
expression and then look the result up in the hash table.   If it
finds a match, the client is considered a member of both the class and
the subclass.
.PP
Subclasses can be declared with or without scope.   In the above
example, the sole purpose of the subclass is to allow some clients
access to one address pool, while other clients are given access to
the other pool, so these subclasses are declared without scopes.   If
part of the purpose of the subclass were to define different parameter
values for some clients, you might want to declare some subclasses
with scopes.
.PP
In the above example, if you had a single client that needed some
configuration parameters, while most didn't, you might write the
following subclass declaration for that client:
.PP
.nf
subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
  option root-path "samsara:/var/diskless/alphapc";
  filename "/tftpboot/netbsd.alphapc-diskless";
}
.fi
.PP
In this example, we've used subclassing as a way to control address
allocation on a per-client basis.  However, it's also possible to use
subclassing in ways that are not specific to clients - for example, to
use the value of the vendor-class-identifier option to determine what
values to send in the vendor-encapsulated-options option.  An example
of this is shown under the VENDOR ENCAPSULATED OPTIONS head in the
.B dhcp-options(5)
manual page.
.SH PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
.PP
You may specify a limit to the number of clients in a class that can
be assigned leases.   The effect of this will be to make it difficult
for a new client in a class to get an address.   Once a class with
such a limit has reached its limit, the only way a new client in that
class can get a lease is for an existing client to relinquish its
lease, either by letting it expire, or by sending a DHCPRELEASE
packet.   Classes with lease limits are specified as follows:
.PP
.nf
class "limited-1" {
  lease limit 4;
}
.fi
.PP
This will produce a class in which a maximum of four members may hold
a lease at one time.
.SH SPAWNING CLASSES
.PP
It is possible to declare a
.I spawning class\fR.
A spawning class is a class that automatically produces subclasses
based on what the client sends.   The reason that spawning classes
were created was to make it possible to create lease-limited classes
on the fly.   The envisioned application is a cable-modem environment
where the ISP wishes to provide clients at a particular site with more
than one IP address, but does not wish to provide such clients with
their own subnet, nor give them an unlimited number of IP addresses
from the network segment to which they are connected.
.PP
Many cable modem head-end systems can be configured to add a Relay
Agent Information option to DHCP packets when relaying them to the
DHCP server.   These systems typically add a circuit ID or remote ID
option that uniquely identifies the customer site.   To take advantage
of this, you can write a class declaration as follows:
.PP
.nf
class "customer" {
  spawn with option agent.circuit-id;
  lease limit 4;
}
.fi
.PP
Now whenever a request comes in from a customer site, the circuit ID
option will be checked against the class's hash table.   If a subclass
is found that matches the circuit ID, the client will be classified in
that subclass and treated accordingly.   If no subclass is found
matching the circuit ID, a new one will be created and logged in the
.B dhcpd.leases
file, and the client will be classified in this new class.   Once the
client has been classified, it will be treated according to the rules
of the class, including, in this case, being subject to the per-site
limit of four leases.
.PP
The use of the subclass spawning mechanism is not restricted to relay
agent options - this particular example is given only because it is a
fairly straightforward one.
.SH COMBINING MATCH, MATCH IF AND SPAWN WITH
.PP
In some cases, it may be useful to use one expression to assign a
client to a particular class, and a second expression to put it into a
subclass of that class.   This can be done by combining the \fBmatch
if\fR and \fBspawn with\fR statements, or the \fBmatch if\fR and
\fBmatch\fR statements.   For example:
.PP
.nf
class "jr-cable-modems" {
  match if option dhcp-vendor-identifier = "jrcm";
  spawn with option agent.circuit-id;
  lease limit 4;
}

class "dv-dsl-modems" {
  match if opton dhcp-vendor-identifier = "dvdsl";
  spawn with option agent.circuit-id;
  lease limit 16;
}
.fi
.PP
This allows you to have two classes that both have the same \fBspawn
with\fR expression without getting the clients in the two classes
confused with each other.
.SH DYNAMIC DNS UPDATES
.PP
The DHCP server has the ability to dynamically update the Domain Name
System.  Within the configuration files, you can define how you want
the Domain Name System to be updated.  These updates are RFC 2136
compliant so any DNS server supporting RFC 2136 should be able to
accept updates from the DHCP server.
.PP
Two DNS update schemes are currently implemented, and another is
planned.   The two that are currently available are the ad-hoc DNS
update mode and the interim DHCP-DNS interaction draft update mode.
If and when the DHCP-DNS interaction draft and the DHCID draft make it
through the IETF standards process, there will be a third mode, which
will be the standard DNS update method.   The DHCP server must be
configured to use one of the two currently-supported methods, or not
to do dns updates.   This can be done with the
.I ddns-update-style
configuration parameter.
.SH THE AD-HOC DNS UPDATE SCHEME
The ad-hoc Dynamic DNS update scheme is
.B now deprecated
and
.B
does not work.
In future releases of the ISC DHCP server, this scheme will not likely be
available.  The interim scheme works, allows for failover, and should now be
used.  The following description is left here for informational purposes
only.
.PP
The ad-hoc Dynamic DNS update scheme implemented in this version of
the ISC DHCP server is a prototype design, which does not
have much to do with the standard update method that is being
standardized in the IETF DHC working group, but rather implements some
very basic, yet useful, update capabilities.   This mode
.B does not work
with the
.I failover protocol
because it does not account for the possibility of two different DHCP
servers updating the same set of DNS records.
.PP
For the ad-hoc DNS update method, the client's FQDN is derived in two
parts.   First, the hostname is determined.   Then, the domain name is
determined, and appended to the hostname.
.PP
The DHCP server determines the client's hostname by first looking for
a \fIddns-hostname\fR configuration option, and using that if it is
present.  If no such option is present, the server looks for a
valid hostname in the FQDN option sent by the client.  If one is
found, it is used; otherwise, if the client sent a host-name option,
that is used.  Otherwise, if there is a host declaration that applies
to the client, the name from that declaration will be used.  If none
of these applies, the server will not have a hostname for the client,
and will not be able to do a DNS update.
.PP
The domain name is determined based strictly on the server
configuration, not on what the client sends.   First, if there is a 
.I ddns-domainname
configuration option, it is used.   Second, if there is a
\fIdomain-name\fR option configured, that is used.  Otherwise, the
server will not do the DNS update.
.PP
The client's fully-qualified domain name, derived as we have
described, is used as the name on which an "A" record will be stored.
The A record will contain the IP address that the client was assigned
in its lease.   If there is already an A record with the same name in
the DNS server, no update of either the A or PTR records will occur -
this prevents a client from claiming that its hostname is the name of
some network server.   For example, if you have a fileserver called