dhcpd.conf.5

DHCP服务器源码

address is available to the client, the server will send a DHCPACK.
If the address is no longer available, or the client isn't permitted
to have it, the server will send a DHCPNAK.  If the server knows
nothing about the address, it will remain silent, unless the address
is incorrect for the network segment to which the client has been
attached and the server is authoritative for that network segment, in
which case the server will send a DHCPNAK even though it doesn't know
about the address.
.PP
There may be a host declaration matching the client's identification.
If that host declaration contains a fixed-address declaration that 
lists an IP address that is valid for the network segment to which the
client is connected.  In this case, the DHCP server will never do
dynamic address allocation.  In this case, the client is \fIrequired\fR
to take the address specified in the host declaration.   If the
client sends a DHCPREQUEST for some other address, the server will respond
with a DHCPNAK.
.PP
When the DHCP server allocates a new address for a client (remember,
this only happens if the client has sent a DHCPDISCOVER), it first
looks to see if the client already has a valid lease on an IP address,
or if there is an old IP address the client had before that hasn't yet
been reassigned.  In that case, the server will take that address and
check it to see if the client is still permitted to use it.  If the
client is no longer permitted to use it, the lease is freed if the
server thought it was still in use - the fact that the client has sent
a DHCPDISCOVER proves to the server that the client is no longer using
the lease.
.PP
If no existing lease is found, or if the client is forbidden to
receive the existing lease, then the server will look in the list of
address pools for the network segment to which the client is attached
for a lease that is not in use and that the client is permitted to
have.   It looks through each pool declaration in sequence (all
.I range
declarations that appear outside of pool declarations are grouped into
a single pool with no permit list).   If the permit list for the pool
allows the client to be allocated an address from that pool, the pool
is examined to see if there is an address available.   If so, then the
client is tentatively assigned that address.   Otherwise, the next
pool is tested.   If no addresses are found that can be assigned to
the client, no response is sent to the client.
.PP
If an address is found that the client is permitted to have, and that
has never been assigned to any client before, the address is
immediately allocated to the client.   If the address is available for
allocation but has been previously assigned to a different client, the
server will keep looking in hopes of finding an address that has never
before been assigned to a client.
.PP
The DHCP server generates the list of available IP addresses from a
hash table.   This means that the addresses are not sorted in any
particular order, and so it is not possible to predict the order in
which the DHCP server will allocate IP addresses.   Users of previous
versions of the ISC DHCP server may have become accustomed to the DHCP
server allocating IP addresses in ascending order, but this is no
longer possible, and there is no way to configure this behavior with
version 3 of the ISC DHCP server.
.SH IP ADDRESS CONFLICT PREVENTION
The DHCP server checks IP addresses to see if they are in use before
allocating them to clients.   It does this by sending an ICMP Echo
request message to the IP address being allocated.   If no ICMP Echo
reply is received within a second, the address is assumed to be free.
This is only done for leases that have been specified in range
statements, and only when the lease is thought by the DHCP server to
be free - i.e., the DHCP server or its failover peer has not listed
the lease as in use.
.PP
If a response is received to an ICMP Echo request, the DHCP server
assumes that there is a configuration error - the IP address is in use
by some host on the network that is not a DHCP client.   It marks the
address as abandoned, and will not assign it to clients.
.PP
If a DHCP client tries to get an IP address, but none are available,
but there are abandoned IP addresses, then the DHCP server will
attempt to reclaim an abandoned IP address.   It marks one IP address
as free, and then does the same ICMP Echo request check described
previously.   If there is no answer to the ICMP Echo request, the
address is assigned to the client.
.PP
The DHCP server does not cycle through abandoned IP addresses if the
first IP address it tries to reclaim is free.   Rather, when the next
DHCPDISCOVER comes in from the client, it will attempt a new
allocation using the same method described here, and will typically
try a new IP address.
.SH DHCP FAILOVER
This version of the ISC DHCP server supports the DHCP failover
protocol as documented in draft-ietf-dhc-failover-07.txt.   This is
not a final protocol document, and we have not done interoperability
testing with other vendors' implementations of this protocol, so you
must not assume that this implementation conforms to the standard.
If you wish to use the failover protocol, make sure that both failover
peers are running the same version of the ISC DHCP server.
.PP
The failover protocol allows two DHCP servers (and no more than two)
to share a common address pool.   Each server will have about half of
the available IP addresses in the pool at any given time for
allocation.   If one server fails, the other server will continue to
renew leases out of the pool, and will allocate new addresses out of
the roughly half of available addresses that it had when
communications with the other server were lost.
.PP
It is possible during a prolonged failure to tell the remaining server
that the other server is down, in which case the remaining server will
(over time) reclaim all the addresses the other server had available
for allocation, and begin to reuse them.   This is called putting the
server into the PARTNER-DOWN state.
.PP
You can put the server into the PARTNER-DOWN state either by using the
.B omshell (1)
command or by stopping the server, editing the last peer state
declaration in the lease file, and restarting the server.   If you use
this last method, be sure to leave the date and time of the start of
the state blank:
.PP
.nf
.B failover peer "\fIname\fB" state {
.B   my   state partner-down;
.B   peer state \fIstate\fB at \fIdate\fB;
.B }
.fi
.PP
When the other server comes back online, it should automatically
detect that it has been offline and request a complete update from the
server that was running in the PARTNER-DOWN state, and then both
servers will resume processing together.
.PP
It is possible to get into a dangerous situation: if you put one
server into the PARTNER-DOWN state, and then *that* server goes down,
and the other server comes back up, the other server will not know
that the first server was in the PARTNER-DOWN state, and may issue
addresses previously issued by the other server to different clients,
resulting in IP address conflicts.   Before putting a server into
PARTNER-DOWN state, therefore, make
.I sure
that the other server will not restart automatically.
.PP
The failover protocol defines a primary server role and a secondary
server role.   There are some differences in how primaries and
secondaries act, but most of the differences simply have to do with
providing a way for each peer to behave in the opposite way from the
other.   So one server must be configured as primary, and the other
must be configured as secondary, and it doesn't matter too much which
one is which.
.SH FAILOVER STARTUP
When a server starts that has not previously communicated with its
failover peer, it must establish communications with its failover peer
and synchronize with it before it can serve clients.   This can happen
either because you have just configured your DHCP servers to perform
failover for the first time, or because one of your failover servers
has failed catastrophically and lost its database.
.PP
The initial recovery process is designed to ensure that when one
failover peer loses its database and then resynchronizes, any leases
that the failed server gave out before it failed will be honored.
When the failed server starts up, it notices that it has no saved
failover state, and attempts to contact its peer.
.PP
When it has established contact, it asks the peer for a complete copy
its peer's lease database.  The peer then sends its complete database,
and sends a message indicating that it is done.  The failed server
then waits until MCLT has passed, and once MCLT has passed both
servers make the transition back into normal operation.  This waiting
period ensures that any leases the failed server may have given out
while out of contact with its partner will have expired.
.PP
While the failed server is recovering, its partner remains in the
partner-down state, which means that it is serving all clients.  The
failed server provides no service at all to DHCP clients until it has
made the transition into normal operation.
.PP
In the case where both servers detect that they have never before
communicated with their partner, they both come up in this recovery
state and follow the procedure we have just described.   In this case,
no service will be provided to DHCP clients until MCLT has expired.
.SH CONFIGURING FAILOVER
In order to configure failover, you need to write a peer declaration
that configures the failover protocol, and you need to write peer
references in each pool declaration for which you want to do
failover.   You do not have to do failover for all pools on a given
network segment.    You must not tell one server it's doing failover
on a particular address pool and tell the other it is not.   You must
not have any common address pools on which you are not doing
failover.  A pool declaration that utilizes failover would look like this:
.PP
.nf
pool {
	failover peer "foo";
	deny dynamic bootp clients;
	\fIpool specific parameters\fR
};
.fi
.PP
Dynamic BOOTP leases are not compatible with failover, and, as such,
you need to disallow BOOTP in pools that you are using failover for.
.PP
The  server currently  does very  little  sanity checking,  so if  you
configure it wrong, it will just  fail in odd ways.  I would recommend
therefore that you either do  failover or don't do failover, but don't
do any mixed pools.  Also,  use the same master configuration file for
both  servers,  and  have  a  separate file  that  contains  the  peer
declaration and includes the master file.  This will help you to avoid
configuration  mismatches.  As our  implementation evolves,  this will
become  less of  a  problem.  A  basic  sample dhcpd.conf  file for  a
primary server might look like this:
.PP
.nf
failover peer "foo" {
  primary;
  address anthrax.rc.vix.com;
  port 519;
  peer address trantor.rc.vix.com;
  peer port 520;
  max-response-delay 60;
  max-unacked-updates 10;
  mclt 3600;
  split 128;
  load balance max seconds 3;
}

include "/etc/dhcpd.master";
.fi
.PP
The statements in the peer declaration are as follows:
.PP
The 
.I primary
and
.I secondary
statements
.RS 0.25i
.PP
[ \fBprimary\fR | \fBsecondary\fR ]\fB;\fR
.PP
This determines whether the server is primary or secondary, as
described earlier under DHCP FAILOVER.
.RE
.PP
The 
.I address
statement
.RS 0.25i
.PP
.B address \fIaddress\fR\fB;\fR
.PP
The \fBaddress\fR statement declares the IP address or DNS name on which the
server should listen for connections from its failover peer, and also the
value to use for the DHCP Failover Protocol server identifier.  Because this
value is used as an identifier, it may not be omitted.
.RE
.PP
The 
.I peer address
statement
.RS 0.25i
.PP
.B peer address \fIaddress\fR\fB;\fR
.PP
The \fBpeer address\fR statement declares the IP address or DNS name to
which the server should connect to reach its failover peer for failover
messages.
.RE
.PP
The 
.I port
statement
.RS 0.25i
.PP
.B port \fIport-number\fR\fB;\fR
.PP
The \fBport\fR statement declares the TCP port on which the server
should listen for connections from its failover peer.   This statement
may not currently be omitted, because the failover protocol does not
yet have a reserved TCP port number.
.RE
.PP
The 
.I peer port
statement
.RS 0.25i
.PP
.B peer port \fIport-number\fR\fB;\fR
.PP
The \fBpeer port\fR statement declares the TCP port to which the
server should connect to reach its failover peer for failover
messages.   This statement may not be omitted because the failover
protocol does not yet have a reserved TCP port number.   The port
number declared in the \fBpeer port\fR statement may be the same as
the port number declared in the \fBport\fR statement.
.RE
.PP
The 
.I max-response-delay
statement
.RS 0.25i
.PP
.B max-response-delay \fIseconds\fR\fB;\fR
.PP
The \fBmax-response-delay\fR statement tells the DHCP server how
many seconds may pass without receiving a message from its failover
peer before it assumes that connection has failed.   This number
should be small enough that a transient network failure that breaks
the connection will not result in the servers being out of
communication for a long time, but large enough that the server isn't
constantly making and breaking connections.   This parameter must be
specified.
.RE
.PP
The 
.I max-unacked-updates
statement
.RS 0.25i
.PP
.B max-unacked-updates \fIcount\fR\fB;\fR
.PP
The \fBmax-unacked-updates\fR statement tells the DHCP server how
many BNDUPD messages it can send before it receives a BNDACK
from the failover peer.   We don't have enough operational experience
to say what a good value for this is, but 10 seems to work.   This
parameter must be specified.
.RE
.PP
The