mirror of
https://gitlab.isc.org/isc-projects/dhcp
synced 2025-09-04 00:05:30 +00:00
Newly generated from dhcpd.8
This commit is contained in:
Ted Lemon
354
dhcpd.cat8
354
dhcpd.cat8
@@ -1,182 +1,264 @@
|
|||||||
dhcpd(8) NetBSD System Manager's Manual dhcpd(8)
|
|
||||||
|
|
||||||
|
|
||||||
|
dhcpd(8) dhcpd(8)
|
||||||
|
|
||||||
|
|
||||||
NNAAMMEE
|
NNAAMMEE
|
||||||
ddhhccppdd - Dynamic Host Configuration Protocol server
|
dhcpd - Dynamic Host Configuration Protocol server
|
||||||
|
|
||||||
SSYYNNOOPPSSIISS
|
SSYYNNOOPPSSIISS
|
||||||
ddhhccppdd [--pp --ppoorrtt]
|
ddhhccppdd [ --pp _p_o_r_t ]
|
||||||
|
|
||||||
DDEESSCCRRIIPPTTIIOONN
|
DDEESSCCRRIIPPTTIIOONN
|
||||||
dhcpd(8) implements the Dynamic Host Configuration Protocol (DHCP) and
|
dhcpd(8) implements the Dynamic Host Configuration Proto-
|
||||||
the Internet Bootstrap Protocol (BOOTP). DHCP allows hosts on a TCP/IP
|
col (DHCP) and the Internet Bootstrap Protocol (BOOTP).
|
||||||
network to request and be assigned IP addresses, and also to discover in-
|
DHCP allows hosts on a TCP/IP network to request and be
|
||||||
formation about the network to which they are attached. BOOTP provides
|
assigned IP addresses, and also to discover information
|
||||||
similar but much more limited functionality.
|
about the network to which they are attached. BOOTP pro-
|
||||||
|
vides similar but much more limited functionality.
|
||||||
|
|
||||||
OOPPEERRAATTIIOONN
|
OOPPEERRAATTIIOONN
|
||||||
The DHCP protocol allows a host which is unknown to the network adminis-
|
The DHCP protocol allows a host which is unknown to the
|
||||||
trator to be automatically assigned a new IP address out of a pool of IP
|
network administrator to be automatically assigned a new
|
||||||
addresses for its network. In order for this to work, the network ad-
|
IP address out of a pool of IP addresses for its network.
|
||||||
ministrator allocates address pools in each subnet and enters them into
|
In order for this to work, the network administrator allo-
|
||||||
the dhcpd.conf(5) file.
|
cates address pools in each subnet and enters them into
|
||||||
|
the dhcpd.conf(5) file.
|
||||||
|
|
||||||
On startup, dhcpd reads the ddhhccppdd..ccoonnff file and keeps the list of avail-
|
On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and keeps the
|
||||||
able addresses on each subnet in memory. When a host requests an address
|
list of available addresses on each subnet in memory.
|
||||||
using the DHCP protocol, dhcpd allocates an address for it. Each such
|
When a host requests an address using the DHCP protocol,
|
||||||
host is assigned a lease, which expires after an amount of time chosen by
|
dhcpd allocates an address for it. Each such host is
|
||||||
the administrator (by default, one day). As leases expire, the hosts to
|
assigned a lease, which expires after an amount of time
|
||||||
which they are assigned are expected to renew the leases if they wish to
|
chosen by the administrator (by default, one day). As
|
||||||
continue to use the addresses. Once a lease has expired, the host to
|
leases expire, the hosts to which they are assigned are
|
||||||
which that lease is assigned is no longer permitted to use the IP address
|
expected to renew the leases if they wish to continue to
|
||||||
assigned to it.
|
use the addresses. Once a lease has expired, the host to
|
||||||
|
which that lease is assigned is no longer permitted to use
|
||||||
|
the IP address assigned to it.
|
||||||
|
|
||||||
In order to keep track of leases across system reboots and server
|
In order to keep track of leases across system reboots and
|
||||||
restarts, ddhhccppdd keeps a list of leases it has assigned in the
|
server restarts, dhcpd keeps a list of leases it has
|
||||||
dhcpd.leases(5) file. Before dhcpd grants a lease to a host, it records
|
assigned in the dhcpd.leases(5) file. Before dhcpd
|
||||||
the lease in this file and makes sure that the contents of the file are
|
grants a lease to a host, it records the lease in this
|
||||||
flushed to disk. This ensures that even in the event of a system crash,
|
file and makes sure that the contents of the file are
|
||||||
ddhhccppdd will not forget about a lease that it has assigned. On startup,
|
flushed to disk. This ensures that even in the event of
|
||||||
after reading the ddhhccppdd..ccoonnff file, ddhhccppdd reads the ddhhccppdd..lleeaasseess file to
|
a system crash, dhcpd will not forget about a lease that
|
||||||
refresh its memory about what leases have been assigned.
|
it has assigned. On startup, after reading the
|
||||||
|
dhcpd.conf file, dhcpd reads the dhcpd.leases file to
|
||||||
|
refresh its memory about what leases have been assigned.
|
||||||
|
|
||||||
New leases are appended to the end of the ddhhccppdd..lleeaasseess file. In order
|
New leases are appended to the end of the dhcpd.leases
|
||||||
to prevent the file from becoming arbitrarily large, from time to time
|
file. In order to prevent the file from becoming arbi-
|
||||||
ddhhccppdd creates a new ddhhccppdd..lleeaasseess file from its in-core lease database.
|
trarily large, from time to time dhcpd creates a new
|
||||||
Once this file has been written to disk, the old file is renamed
|
dhcpd.leases file from its in-core lease database. Once
|
||||||
ddhhccppdd..lleeaasseess~~, and the new file is renamed ddhhccppdd..lleeaasseess. If the system
|
this file has been written to disk, the old file is
|
||||||
crashes in the middle of this process, whichever ddhhccppdd..lleeaasseess file re-
|
renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed
|
||||||
mains will contain all the lease information, so there is no need for a
|
dhcpd.leases. If the system crashes in the middle of
|
||||||
special crash recovery process.
|
this process, whichever dhcpd.leases file remains will
|
||||||
|
contain all the lease information, so there is no need for
|
||||||
|
|
||||||
BOOTP support is also provided by this server. Unlike DHCP, the BOOTP
|
|
||||||
protocol requires that the server know the hardware address of the client
|
|
||||||
that is to be booted. The network administrator must determine that ad-
|
|
||||||
dress, allocate an IP address for the client, and enter that information
|
|
||||||
into the ddhhccppdd..ccoonnff file.
|
|
||||||
|
|
||||||
Whenever changes are made to the ddhhccppdd..ccoonnff file, ddhhccppdd must be restart-
|
|
||||||
ed. To restart ddhhccppdd, send a SIGTERM (signal 15) to the process ID con-
|
1
|
||||||
tained in //vvaarr//rruunn//ddhhccppdd..ppiidd, and then re-invoke ddhhccppdd.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
dhcpd(8) dhcpd(8)
|
||||||
|
|
||||||
|
|
||||||
|
a special crash recovery process.
|
||||||
|
|
||||||
|
BOOTP support is also provided by this server. Unlike
|
||||||
|
DHCP, the BOOTP protocol requires that the server know the
|
||||||
|
hardware address of the client that is to be booted. The
|
||||||
|
network administrator must determine that address, allo-
|
||||||
|
cate an IP address for the client, and enter that informa-
|
||||||
|
tion into the dhcpd.conf file.
|
||||||
|
|
||||||
|
Whenever changes are made to the dhcpd.conf file, dhcpd
|
||||||
|
must be restarted. To restart dhcpd, send a SIGTERM
|
||||||
|
(signal 15) to the process ID contained in _/_d_h_c_p_d_._p_i_d, and
|
||||||
|
then re-invoke dhcpd.
|
||||||
|
|
||||||
|
|
||||||
CCOONNFFIIGGUURRAATTIIOONN
|
CCOONNFFIIGGUURRAATTIIOONN
|
||||||
The syntax of the dhcpd.conf(8) file is discussed seperately. This sec-
|
The syntax of the dhcpd.conf(8) file is discussed seper-
|
||||||
tion should be used as an overview of the configuration process, and the
|
ately. This section should be used as an overview of the
|
||||||
dhcpd.conf(8) documentation should be consulted for detailed reference
|
configuration process, and the dhcpd.conf(8) documentation
|
||||||
information.
|
should be consulted for detailed reference information.
|
||||||
|
|
||||||
|
|
||||||
SSuubbnneettss
|
SSuubbnneettss
|
||||||
dhcpd(8) needs to know the subnet numbers and netmasks of all subnets for
|
dhcpd needs to know the subnet numbers and netmasks of all
|
||||||
which it will be providing service. In addition, in order to dynamical-
|
subnets for which it will be providing service. In addi-
|
||||||
ly allocate addresses, it must be assigned one or more ranges of address-
|
tion, in order to dynamically allocate addresses, it must
|
||||||
es on each subnet which it can in turn assign to client hosts as they
|
be assigned one or more ranges of addresses on each subnet
|
||||||
boot. Thus, a very simple configuration providing DHCP support might
|
which it can in turn assign to client hosts as they boot.
|
||||||
look like this:
|
Thus, a very simple configuration providing DHCP support
|
||||||
|
might look like this:
|
||||||
|
|
||||||
subnet 239.252.197.0 netmask 255.255.255.0
|
subnet 239.252.197.0 netmask 255.255.255.0
|
||||||
range 239.252.197.10 239.252.197.250;
|
range 239.252.197.10 239.252.197.250;
|
||||||
|
|
||||||
Multiple address ranges may be specified like this:
|
Multiple address ranges may be specified like this:
|
||||||
|
|
||||||
subnet 239.252.197.0 netmask 255.255.255.0
|
subnet 239.252.197.0 netmask 255.255.255.0
|
||||||
range 239.252.197.10 239.252.197.107
|
range 239.252.197.10 239.252.197.107
|
||||||
range 239.252.197.113 239.252.197.250;
|
range 239.252.197.113 239.252.197.250;
|
||||||
|
|
||||||
|
If a subnet will only be provided with BOOTP service and
|
||||||
|
no dynamic address assignment, the range clause can be
|
||||||
|
left out entirely, but the subnet statement must appear.
|
||||||
|
|
||||||
If a subnet will only be provided with BOOTP service and no dynamic ad-
|
|
||||||
dress assignment, the range clause can be left out entirely, but the sub-
|
|
||||||
net statement must appear.
|
|
||||||
|
|
||||||
LLeeaassee LLeennggtthhss
|
LLeeaassee LLeennggtthhss
|
||||||
DHCP leases can be assigned almost any length from zero seconds to infin-
|
DHCP leases can be assigned almost any length from zero
|
||||||
ity. What lease length makes sense for any given subnet, or for any
|
seconds to infinity. What lease length makes sense for
|
||||||
given installation, will vary depending on the kinds of hosts being
|
any given subnet, or for any given installation, will vary
|
||||||
served.
|
depending on the kinds of hosts being served.
|
||||||
|
|
||||||
For example, in an office environment where systems are added from time
|
For example, in an office environment where systems are
|
||||||
to time and removed from time to time, but move relatively infrequently,
|
added from time to time and removed from time to time, but
|
||||||
it might make sense to allow lease times of a month of more. In a final
|
move relatively infrequently, it might make sense to allow
|
||||||
test environment on a manufacturing floor, it may make more sense to as-
|
|
||||||
sign a maximum lease length of 30 minutes - enough time to go through a
|
|
||||||
simple test procedure on a network appliance before packaging it up for
|
|
||||||
delivery.
|
|
||||||
|
|
||||||
It is possible to specify two lease lengths: the default length that will
|
|
||||||
be assigned if a client doesn't ask for any particular lease length, and
|
|
||||||
a maximum lease length. These are specified as clauses to the subnet
|
|
||||||
command:
|
|
||||||
|
|
||||||
subnet 239.252.197.0 netmask 255.255.255.0
|
|
||||||
range 239.252.197.10 239.252.197.107
|
|
||||||
default-lease-time 600
|
|
||||||
max-lease-time 7200;
|
|
||||||
|
|
||||||
This particular subnet declaration specifies a default lease time of 600
|
2
|
||||||
seconds (ten minutes), and a maximum lease time of 7200 seconds (two
|
|
||||||
hours). Other common values would be 86400 (one day), 604800 (one week)
|
|
||||||
and 2592000 (30 days).
|
|
||||||
|
|
||||||
Each subnet need not have the same lease--in the case of an office envi-
|
|
||||||
ronment and a manufacturing environment served by the same DHCP server,
|
|
||||||
it might make sense to have widely disparate values for default and maxi-
|
|
||||||
mum lease times on each subnet.
|
|
||||||
|
dhcpd(8) dhcpd(8)
|
||||||
|
|
||||||
|
|
||||||
|
lease times of a month of more. In a final test environ-
|
||||||
|
ment on a manufacturing floor, it may make more sense to
|
||||||
|
assign a maximum lease length of 30 minutes - enough time
|
||||||
|
to go through a simple test procedure on a network appli-
|
||||||
|
ance before packaging it up for delivery.
|
||||||
|
|
||||||
|
It is possible to specify two lease lengths: the default
|
||||||
|
length that will be assigned if a client doesn't ask for
|
||||||
|
any particular lease length, and a maximum lease length.
|
||||||
|
These are specified as clauses to the subnet command:
|
||||||
|
|
||||||
|
subnet 239.252.197.0 netmask 255.255.255.0
|
||||||
|
range 239.252.197.10 239.252.197.107
|
||||||
|
default-lease-time 600
|
||||||
|
max-lease-time 7200;
|
||||||
|
|
||||||
|
This particular subnet declaration specifies a default
|
||||||
|
lease time of 600 seconds (ten minutes), and a maximum
|
||||||
|
lease time of 7200 seconds (two hours). Other common
|
||||||
|
values would be 86400 (one day), 604800 (one week) and
|
||||||
|
2592000 (30 days).
|
||||||
|
|
||||||
|
Each subnet need not have the same lease--in the case of
|
||||||
|
an office environment and a manufacturing environment
|
||||||
|
served by the same DHCP server, it might make sense to
|
||||||
|
have widely disparate values for default and maximum lease
|
||||||
|
times on each subnet.
|
||||||
|
|
||||||
BBOOOOTTPP SSuuppppoorrtt
|
BBOOOOTTPP SSuuppppoorrtt
|
||||||
Each BOOTP client must be explicitly declared in the ddhhccppdd..ccoonnff file. A
|
Each BOOTP client must be explicitly declared in the
|
||||||
very basic client declaration will specify the client network interface's
|
dhcpd.conf file. A very basic client declaration will
|
||||||
hardware address and the IP address to assign to that client. If the
|
specify the client network interface's hardware address
|
||||||
client needs to be able to load a boot file from the server, that file's
|
and the IP address to assign to that client. If the
|
||||||
name must be specified. A simple bootp client declaration might look
|
client needs to be able to load a boot file from the
|
||||||
like this:
|
server, that file's name must be specified. A simple
|
||||||
|
bootp client declaration might look like this:
|
||||||
|
|
||||||
host haagen hardware ethernet 08:00:2b:4c:59:23
|
host haagen hardware ethernet 08:00:2b:4c:59:23
|
||||||
fixed-address 239.252.197.9
|
fixed-address 239.252.197.9
|
||||||
filename "/tftpboot/haagen.boot";
|
filename "/tftpboot/haagen.boot";
|
||||||
|
|
||||||
OOppttiioonnss
|
OOppttiioonnss
|
||||||
DHCP (and also BOOTP with Vendor Extensions) provide a mechanism whereby
|
DHCP (and also BOOTP with Vendor Extensions) provide a
|
||||||
the server can provide the client with information about how to configure
|
mechanism whereby the server can provide the client with
|
||||||
its network interface (e.g., subnet mask), and also how the client can
|
information about how to configure its network interface
|
||||||
access various network services (e.g., DNS, IP routers, and so on).
|
(e.g., subnet mask), and also how the client can access
|
||||||
|
various network services (e.g., DNS, IP routers, and so
|
||||||
|
on).
|
||||||
|
|
||||||
These options can be specified on a per-subnet basis, and, for BOOTP
|
These options can be specified on a per-subnet basis, and,
|
||||||
clients, also on a per-client basis. In the event that a BOOTP client
|
for BOOTP clients, also on a per-client basis. In the
|
||||||
declaration specifies options that are also specified in its subnet dec-
|
event that a BOOTP client declaration specifies options
|
||||||
laration, the options specified in the client declaration take prece-
|
that are also specified in its subnet declaration, the
|
||||||
dence. An reasonably complete DHCP configuration might look something
|
options specified in the client declaration take
|
||||||
like this:
|
|
||||||
|
|
||||||
subnet 239.252.197.0 netmask 255.255.255.0
|
|
||||||
range 239.252.197.10 239.252.197.250
|
|
||||||
default-lease-time 600 max-lease-time 7200
|
|
||||||
option subnet-mask 255.255.255.0
|
|
||||||
option broadcast-address 239.252.197.255
|
|
||||||
option routers 239.252.197.1
|
|
||||||
option domain-name-servers 239.252.197.2, 239.252.197.3
|
|
||||||
option domain-name "isc.org";
|
|
||||||
|
|
||||||
A bootp host on that subnet that needs to be in a different domain and
|
|
||||||
use a different name server might be declared as follows:
|
|
||||||
|
|
||||||
host haagen hardware ethernet 08:00:2b:4c:59:23
|
3
|
||||||
fixed-address 239.252.197.9
|
|
||||||
filename "/tftpboot/haagen.boot"
|
|
||||||
option domain-name-servers 192.5.5.1
|
|
||||||
option domain-name "vix.com";
|
|
||||||
|
|
||||||
A complete list of DHCP Options and their syntaxes is provided in
|
|
||||||
dhcpd.conf(5).
|
|
||||||
|
|
||||||
|
|
||||||
|
dhcpd(8) dhcpd(8)
|
||||||
|
|
||||||
|
|
||||||
|
precedence. An reasonably complete DHCP configuration
|
||||||
|
might look something like this:
|
||||||
|
|
||||||
|
subnet 239.252.197.0 netmask 255.255.255.0
|
||||||
|
range 239.252.197.10 239.252.197.250
|
||||||
|
default-lease-time 600 max-lease-time 7200
|
||||||
|
option subnet-mask 255.255.255.0
|
||||||
|
option broadcast-address 239.252.197.255
|
||||||
|
option routers 239.252.197.1
|
||||||
|
option domain-name-servers 239.252.197.2, 239.252.197.3
|
||||||
|
option domain-name "isc.org";
|
||||||
|
|
||||||
|
A bootp host on that subnet that needs to be in a differ-
|
||||||
|
ent domain and use a different name server might be
|
||||||
|
declared as follows:
|
||||||
|
|
||||||
|
host haagen hardware ethernet 08:00:2b:4c:59:23
|
||||||
|
fixed-address 239.252.197.9
|
||||||
|
filename "/tftpboot/haagen.boot"
|
||||||
|
option domain-name-servers 192.5.5.1
|
||||||
|
option domain-name "vix.com";
|
||||||
|
|
||||||
|
A complete list of DHCP Options and their syntaxes is pro-
|
||||||
|
vided in dhcpd.conf(5).
|
||||||
|
|
||||||
FFIILLEESS
|
FFIILLEESS
|
||||||
//eettcc//ddhhccppdd..ccoonnff, //eettcc//ddhhccppdd..lleeaasseess, //vvaarr//rruunn//ddhhccppdd..ppiidd,
|
//eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,,
|
||||||
//eettcc//ddhhccppdd..lleeaasseess~~.
|
//vvaarr//ddbb//ddhhccppdd..lleeaasseess~~..
|
||||||
|
|
||||||
SSEEEE AALLSSOO
|
SSEEEE AALLSSOO
|
||||||
dhcpd.conf(5), dhcpd.leases(5)
|
dhcpd.conf(5), dhcpd.leases(5)
|
||||||
|
|
||||||
AAUUTTHHOORR
|
AAUUTTHHOORR
|
||||||
dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
|
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
|
||||||
Vixie Labs. Funding for this project was provided by the Internet Soft-
|
contract with Vixie Labs. Funding for this project was
|
||||||
ware Corporation. Information about the Internet Software Consortium can
|
provided by the Internet Software Corporation. Informa-
|
||||||
be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
|
tion about the Internet Software Consortium can be found
|
||||||
|
at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
4
|
||||||
|
|
||||||
|
|
||||||
March 16, 1996 3
|
|
||||||
|
|||||||
@@ -1,182 +1,264 @@
|
|||||||
dhcpd(8) NetBSD System Manager's Manual dhcpd(8)
|
|
||||||
|
|
||||||
|
|
||||||
|
dhcpd(8) dhcpd(8)
|
||||||
|
|
||||||
|
|
||||||
NNAAMMEE
|
NNAAMMEE
|
||||||
ddhhccppdd - Dynamic Host Configuration Protocol server
|
dhcpd - Dynamic Host Configuration Protocol server
|
||||||
|
|
||||||
SSYYNNOOPPSSIISS
|
SSYYNNOOPPSSIISS
|
||||||
ddhhccppdd [--pp --ppoorrtt]
|
ddhhccppdd [ --pp _p_o_r_t ]
|
||||||
|
|
||||||
DDEESSCCRRIIPPTTIIOONN
|
DDEESSCCRRIIPPTTIIOONN
|
||||||
dhcpd(8) implements the Dynamic Host Configuration Protocol (DHCP) and
|
dhcpd(8) implements the Dynamic Host Configuration Proto-
|
||||||
the Internet Bootstrap Protocol (BOOTP). DHCP allows hosts on a TCP/IP
|
col (DHCP) and the Internet Bootstrap Protocol (BOOTP).
|
||||||
network to request and be assigned IP addresses, and also to discover in-
|
DHCP allows hosts on a TCP/IP network to request and be
|
||||||
formation about the network to which they are attached. BOOTP provides
|
assigned IP addresses, and also to discover information
|
||||||
similar but much more limited functionality.
|
about the network to which they are attached. BOOTP pro-
|
||||||
|
vides similar but much more limited functionality.
|
||||||
|
|
||||||
OOPPEERRAATTIIOONN
|
OOPPEERRAATTIIOONN
|
||||||
The DHCP protocol allows a host which is unknown to the network adminis-
|
The DHCP protocol allows a host which is unknown to the
|
||||||
trator to be automatically assigned a new IP address out of a pool of IP
|
network administrator to be automatically assigned a new
|
||||||
addresses for its network. In order for this to work, the network ad-
|
IP address out of a pool of IP addresses for its network.
|
||||||
ministrator allocates address pools in each subnet and enters them into
|
In order for this to work, the network administrator allo-
|
||||||
the dhcpd.conf(5) file.
|
cates address pools in each subnet and enters them into
|
||||||
|
the dhcpd.conf(5) file.
|
||||||
|
|
||||||
On startup, dhcpd reads the ddhhccppdd..ccoonnff file and keeps the list of avail-
|
On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and keeps the
|
||||||
able addresses on each subnet in memory. When a host requests an address
|
list of available addresses on each subnet in memory.
|
||||||
using the DHCP protocol, dhcpd allocates an address for it. Each such
|
When a host requests an address using the DHCP protocol,
|
||||||
host is assigned a lease, which expires after an amount of time chosen by
|
dhcpd allocates an address for it. Each such host is
|
||||||
the administrator (by default, one day). As leases expire, the hosts to
|
assigned a lease, which expires after an amount of time
|
||||||
which they are assigned are expected to renew the leases if they wish to
|
chosen by the administrator (by default, one day). As
|
||||||
continue to use the addresses. Once a lease has expired, the host to
|
leases expire, the hosts to which they are assigned are
|
||||||
which that lease is assigned is no longer permitted to use the IP address
|
expected to renew the leases if they wish to continue to
|
||||||
assigned to it.
|
use the addresses. Once a lease has expired, the host to
|
||||||
|
which that lease is assigned is no longer permitted to use
|
||||||
|
the IP address assigned to it.
|
||||||
|
|
||||||
In order to keep track of leases across system reboots and server
|
In order to keep track of leases across system reboots and
|
||||||
restarts, ddhhccppdd keeps a list of leases it has assigned in the
|
server restarts, dhcpd keeps a list of leases it has
|
||||||
dhcpd.leases(5) file. Before dhcpd grants a lease to a host, it records
|
assigned in the dhcpd.leases(5) file. Before dhcpd
|
||||||
the lease in this file and makes sure that the contents of the file are
|
grants a lease to a host, it records the lease in this
|
||||||
flushed to disk. This ensures that even in the event of a system crash,
|
file and makes sure that the contents of the file are
|
||||||
ddhhccppdd will not forget about a lease that it has assigned. On startup,
|
flushed to disk. This ensures that even in the event of
|
||||||
after reading the ddhhccppdd..ccoonnff file, ddhhccppdd reads the ddhhccppdd..lleeaasseess file to
|
a system crash, dhcpd will not forget about a lease that
|
||||||
refresh its memory about what leases have been assigned.
|
it has assigned. On startup, after reading the
|
||||||
|
dhcpd.conf file, dhcpd reads the dhcpd.leases file to
|
||||||
|
refresh its memory about what leases have been assigned.
|
||||||
|
|
||||||
New leases are appended to the end of the ddhhccppdd..lleeaasseess file. In order
|
New leases are appended to the end of the dhcpd.leases
|
||||||
to prevent the file from becoming arbitrarily large, from time to time
|
file. In order to prevent the file from becoming arbi-
|
||||||
ddhhccppdd creates a new ddhhccppdd..lleeaasseess file from its in-core lease database.
|
trarily large, from time to time dhcpd creates a new
|
||||||
Once this file has been written to disk, the old file is renamed
|
dhcpd.leases file from its in-core lease database. Once
|
||||||
ddhhccppdd..lleeaasseess~~, and the new file is renamed ddhhccppdd..lleeaasseess. If the system
|
this file has been written to disk, the old file is
|
||||||
crashes in the middle of this process, whichever ddhhccppdd..lleeaasseess file re-
|
renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed
|
||||||
mains will contain all the lease information, so there is no need for a
|
dhcpd.leases. If the system crashes in the middle of
|
||||||
special crash recovery process.
|
this process, whichever dhcpd.leases file remains will
|
||||||
|
contain all the lease information, so there is no need for
|
||||||
|
|
||||||
BOOTP support is also provided by this server. Unlike DHCP, the BOOTP
|
|
||||||
protocol requires that the server know the hardware address of the client
|
|
||||||
that is to be booted. The network administrator must determine that ad-
|
|
||||||
dress, allocate an IP address for the client, and enter that information
|
|
||||||
into the ddhhccppdd..ccoonnff file.
|
|
||||||
|
|
||||||
Whenever changes are made to the ddhhccppdd..ccoonnff file, ddhhccppdd must be restart-
|
|
||||||
ed. To restart ddhhccppdd, send a SIGTERM (signal 15) to the process ID con-
|
1
|
||||||
tained in //vvaarr//rruunn//ddhhccppdd..ppiidd, and then re-invoke ddhhccppdd.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
dhcpd(8) dhcpd(8)
|
||||||
|
|
||||||
|
|
||||||
|
a special crash recovery process.
|
||||||
|
|
||||||
|
BOOTP support is also provided by this server. Unlike
|
||||||
|
DHCP, the BOOTP protocol requires that the server know the
|
||||||
|
hardware address of the client that is to be booted. The
|
||||||
|
network administrator must determine that address, allo-
|
||||||
|
cate an IP address for the client, and enter that informa-
|
||||||
|
tion into the dhcpd.conf file.
|
||||||
|
|
||||||
|
Whenever changes are made to the dhcpd.conf file, dhcpd
|
||||||
|
must be restarted. To restart dhcpd, send a SIGTERM
|
||||||
|
(signal 15) to the process ID contained in _/_d_h_c_p_d_._p_i_d, and
|
||||||
|
then re-invoke dhcpd.
|
||||||
|
|
||||||
|
|
||||||
CCOONNFFIIGGUURRAATTIIOONN
|
CCOONNFFIIGGUURRAATTIIOONN
|
||||||
The syntax of the dhcpd.conf(8) file is discussed seperately. This sec-
|
The syntax of the dhcpd.conf(8) file is discussed seper-
|
||||||
tion should be used as an overview of the configuration process, and the
|
ately. This section should be used as an overview of the
|
||||||
dhcpd.conf(8) documentation should be consulted for detailed reference
|
configuration process, and the dhcpd.conf(8) documentation
|
||||||
information.
|
should be consulted for detailed reference information.
|
||||||
|
|
||||||
|
|
||||||
SSuubbnneettss
|
SSuubbnneettss
|
||||||
dhcpd(8) needs to know the subnet numbers and netmasks of all subnets for
|
dhcpd needs to know the subnet numbers and netmasks of all
|
||||||
which it will be providing service. In addition, in order to dynamical-
|
subnets for which it will be providing service. In addi-
|
||||||
ly allocate addresses, it must be assigned one or more ranges of address-
|
tion, in order to dynamically allocate addresses, it must
|
||||||
es on each subnet which it can in turn assign to client hosts as they
|
be assigned one or more ranges of addresses on each subnet
|
||||||
boot. Thus, a very simple configuration providing DHCP support might
|
which it can in turn assign to client hosts as they boot.
|
||||||
look like this:
|
Thus, a very simple configuration providing DHCP support
|
||||||
|
might look like this:
|
||||||
|
|
||||||
subnet 239.252.197.0 netmask 255.255.255.0
|
subnet 239.252.197.0 netmask 255.255.255.0
|
||||||
range 239.252.197.10 239.252.197.250;
|
range 239.252.197.10 239.252.197.250;
|
||||||
|
|
||||||
Multiple address ranges may be specified like this:
|
Multiple address ranges may be specified like this:
|
||||||
|
|
||||||
subnet 239.252.197.0 netmask 255.255.255.0
|
subnet 239.252.197.0 netmask 255.255.255.0
|
||||||
range 239.252.197.10 239.252.197.107
|
range 239.252.197.10 239.252.197.107
|
||||||
range 239.252.197.113 239.252.197.250;
|
range 239.252.197.113 239.252.197.250;
|
||||||
|
|
||||||
|
If a subnet will only be provided with BOOTP service and
|
||||||
|
no dynamic address assignment, the range clause can be
|
||||||
|
left out entirely, but the subnet statement must appear.
|
||||||
|
|
||||||
If a subnet will only be provided with BOOTP service and no dynamic ad-
|
|
||||||
dress assignment, the range clause can be left out entirely, but the sub-
|
|
||||||
net statement must appear.
|
|
||||||
|
|
||||||
LLeeaassee LLeennggtthhss
|
LLeeaassee LLeennggtthhss
|
||||||
DHCP leases can be assigned almost any length from zero seconds to infin-
|
DHCP leases can be assigned almost any length from zero
|
||||||
ity. What lease length makes sense for any given subnet, or for any
|
seconds to infinity. What lease length makes sense for
|
||||||
given installation, will vary depending on the kinds of hosts being
|
any given subnet, or for any given installation, will vary
|
||||||
served.
|
depending on the kinds of hosts being served.
|
||||||
|
|
||||||
For example, in an office environment where systems are added from time
|
For example, in an office environment where systems are
|
||||||
to time and removed from time to time, but move relatively infrequently,
|
added from time to time and removed from time to time, but
|
||||||
it might make sense to allow lease times of a month of more. In a final
|
move relatively infrequently, it might make sense to allow
|
||||||
test environment on a manufacturing floor, it may make more sense to as-
|
|
||||||
sign a maximum lease length of 30 minutes - enough time to go through a
|
|
||||||
simple test procedure on a network appliance before packaging it up for
|
|
||||||
delivery.
|
|
||||||
|
|
||||||
It is possible to specify two lease lengths: the default length that will
|
|
||||||
be assigned if a client doesn't ask for any particular lease length, and
|
|
||||||
a maximum lease length. These are specified as clauses to the subnet
|
|
||||||
command:
|
|
||||||
|
|
||||||
subnet 239.252.197.0 netmask 255.255.255.0
|
|
||||||
range 239.252.197.10 239.252.197.107
|
|
||||||
default-lease-time 600
|
|
||||||
max-lease-time 7200;
|
|
||||||
|
|
||||||
This particular subnet declaration specifies a default lease time of 600
|
2
|
||||||
seconds (ten minutes), and a maximum lease time of 7200 seconds (two
|
|
||||||
hours). Other common values would be 86400 (one day), 604800 (one week)
|
|
||||||
and 2592000 (30 days).
|
|
||||||
|
|
||||||
Each subnet need not have the same lease--in the case of an office envi-
|
|
||||||
ronment and a manufacturing environment served by the same DHCP server,
|
|
||||||
it might make sense to have widely disparate values for default and maxi-
|
|
||||||
mum lease times on each subnet.
|
|
||||||
|
dhcpd(8) dhcpd(8)
|
||||||
|
|
||||||
|
|
||||||
|
lease times of a month of more. In a final test environ-
|
||||||
|
ment on a manufacturing floor, it may make more sense to
|
||||||
|
assign a maximum lease length of 30 minutes - enough time
|
||||||
|
to go through a simple test procedure on a network appli-
|
||||||
|
ance before packaging it up for delivery.
|
||||||
|
|
||||||
|
It is possible to specify two lease lengths: the default
|
||||||
|
length that will be assigned if a client doesn't ask for
|
||||||
|
any particular lease length, and a maximum lease length.
|
||||||
|
These are specified as clauses to the subnet command:
|
||||||
|
|
||||||
|
subnet 239.252.197.0 netmask 255.255.255.0
|
||||||
|
range 239.252.197.10 239.252.197.107
|
||||||
|
default-lease-time 600
|
||||||
|
max-lease-time 7200;
|
||||||
|
|
||||||
|
This particular subnet declaration specifies a default
|
||||||
|
lease time of 600 seconds (ten minutes), and a maximum
|
||||||
|
lease time of 7200 seconds (two hours). Other common
|
||||||
|
values would be 86400 (one day), 604800 (one week) and
|
||||||
|
2592000 (30 days).
|
||||||
|
|
||||||
|
Each subnet need not have the same lease--in the case of
|
||||||
|
an office environment and a manufacturing environment
|
||||||
|
served by the same DHCP server, it might make sense to
|
||||||
|
have widely disparate values for default and maximum lease
|
||||||
|
times on each subnet.
|
||||||
|
|
||||||
BBOOOOTTPP SSuuppppoorrtt
|
BBOOOOTTPP SSuuppppoorrtt
|
||||||
Each BOOTP client must be explicitly declared in the ddhhccppdd..ccoonnff file. A
|
Each BOOTP client must be explicitly declared in the
|
||||||
very basic client declaration will specify the client network interface's
|
dhcpd.conf file. A very basic client declaration will
|
||||||
hardware address and the IP address to assign to that client. If the
|
specify the client network interface's hardware address
|
||||||
client needs to be able to load a boot file from the server, that file's
|
and the IP address to assign to that client. If the
|
||||||
name must be specified. A simple bootp client declaration might look
|
client needs to be able to load a boot file from the
|
||||||
like this:
|
server, that file's name must be specified. A simple
|
||||||
|
bootp client declaration might look like this:
|
||||||
|
|
||||||
host haagen hardware ethernet 08:00:2b:4c:59:23
|
host haagen hardware ethernet 08:00:2b:4c:59:23
|
||||||
fixed-address 239.252.197.9
|
fixed-address 239.252.197.9
|
||||||
filename "/tftpboot/haagen.boot";
|
filename "/tftpboot/haagen.boot";
|
||||||
|
|
||||||
OOppttiioonnss
|
OOppttiioonnss
|
||||||
DHCP (and also BOOTP with Vendor Extensions) provide a mechanism whereby
|
DHCP (and also BOOTP with Vendor Extensions) provide a
|
||||||
the server can provide the client with information about how to configure
|
mechanism whereby the server can provide the client with
|
||||||
its network interface (e.g., subnet mask), and also how the client can
|
information about how to configure its network interface
|
||||||
access various network services (e.g., DNS, IP routers, and so on).
|
(e.g., subnet mask), and also how the client can access
|
||||||
|
various network services (e.g., DNS, IP routers, and so
|
||||||
|
on).
|
||||||
|
|
||||||
These options can be specified on a per-subnet basis, and, for BOOTP
|
These options can be specified on a per-subnet basis, and,
|
||||||
clients, also on a per-client basis. In the event that a BOOTP client
|
for BOOTP clients, also on a per-client basis. In the
|
||||||
declaration specifies options that are also specified in its subnet dec-
|
event that a BOOTP client declaration specifies options
|
||||||
laration, the options specified in the client declaration take prece-
|
that are also specified in its subnet declaration, the
|
||||||
dence. An reasonably complete DHCP configuration might look something
|
options specified in the client declaration take
|
||||||
like this:
|
|
||||||
|
|
||||||
subnet 239.252.197.0 netmask 255.255.255.0
|
|
||||||
range 239.252.197.10 239.252.197.250
|
|
||||||
default-lease-time 600 max-lease-time 7200
|
|
||||||
option subnet-mask 255.255.255.0
|
|
||||||
option broadcast-address 239.252.197.255
|
|
||||||
option routers 239.252.197.1
|
|
||||||
option domain-name-servers 239.252.197.2, 239.252.197.3
|
|
||||||
option domain-name "isc.org";
|
|
||||||
|
|
||||||
A bootp host on that subnet that needs to be in a different domain and
|
|
||||||
use a different name server might be declared as follows:
|
|
||||||
|
|
||||||
host haagen hardware ethernet 08:00:2b:4c:59:23
|
3
|
||||||
fixed-address 239.252.197.9
|
|
||||||
filename "/tftpboot/haagen.boot"
|
|
||||||
option domain-name-servers 192.5.5.1
|
|
||||||
option domain-name "vix.com";
|
|
||||||
|
|
||||||
A complete list of DHCP Options and their syntaxes is provided in
|
|
||||||
dhcpd.conf(5).
|
|
||||||
|
|
||||||
|
|
||||||
|
dhcpd(8) dhcpd(8)
|
||||||
|
|
||||||
|
|
||||||
|
precedence. An reasonably complete DHCP configuration
|
||||||
|
might look something like this:
|
||||||
|
|
||||||
|
subnet 239.252.197.0 netmask 255.255.255.0
|
||||||
|
range 239.252.197.10 239.252.197.250
|
||||||
|
default-lease-time 600 max-lease-time 7200
|
||||||
|
option subnet-mask 255.255.255.0
|
||||||
|
option broadcast-address 239.252.197.255
|
||||||
|
option routers 239.252.197.1
|
||||||
|
option domain-name-servers 239.252.197.2, 239.252.197.3
|
||||||
|
option domain-name "isc.org";
|
||||||
|
|
||||||
|
A bootp host on that subnet that needs to be in a differ-
|
||||||
|
ent domain and use a different name server might be
|
||||||
|
declared as follows:
|
||||||
|
|
||||||
|
host haagen hardware ethernet 08:00:2b:4c:59:23
|
||||||
|
fixed-address 239.252.197.9
|
||||||
|
filename "/tftpboot/haagen.boot"
|
||||||
|
option domain-name-servers 192.5.5.1
|
||||||
|
option domain-name "vix.com";
|
||||||
|
|
||||||
|
A complete list of DHCP Options and their syntaxes is pro-
|
||||||
|
vided in dhcpd.conf(5).
|
||||||
|
|
||||||
FFIILLEESS
|
FFIILLEESS
|
||||||
//eettcc//ddhhccppdd..ccoonnff, //eettcc//ddhhccppdd..lleeaasseess, //vvaarr//rruunn//ddhhccppdd..ppiidd,
|
//eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,,
|
||||||
//eettcc//ddhhccppdd..lleeaasseess~~.
|
//vvaarr//ddbb//ddhhccppdd..lleeaasseess~~..
|
||||||
|
|
||||||
SSEEEE AALLSSOO
|
SSEEEE AALLSSOO
|
||||||
dhcpd.conf(5), dhcpd.leases(5)
|
dhcpd.conf(5), dhcpd.leases(5)
|
||||||
|
|
||||||
AAUUTTHHOORR
|
AAUUTTHHOORR
|
||||||
dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
|
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
|
||||||
Vixie Labs. Funding for this project was provided by the Internet Soft-
|
contract with Vixie Labs. Funding for this project was
|
||||||
ware Corporation. Information about the Internet Software Consortium can
|
provided by the Internet Software Corporation. Informa-
|
||||||
be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
|
tion about the Internet Software Consortium can be found
|
||||||
|
at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
4
|
||||||
|
|
||||||
|
|
||||||
March 16, 1996 3
|
|
||||||
|
|||||||
Reference in New Issue
Block a user