mirror of
https://gitlab.isc.org/isc-projects/dhcp
synced 2025-08-30 22:05:23 +00:00
Newly generated from dhcpd.8
This commit is contained in:
354
dhcpd.cat8
354
dhcpd.cat8
@@ -1,182 +1,264 @@
|
||||
dhcpd(8) NetBSD System Manager's Manual dhcpd(8)
|
||||
|
||||
|
||||
|
||||
dhcpd(8) dhcpd(8)
|
||||
|
||||
|
||||
NNAAMMEE
|
||||
ddhhccppdd - Dynamic Host Configuration Protocol server
|
||||
dhcpd - Dynamic Host Configuration Protocol server
|
||||
|
||||
SSYYNNOOPPSSIISS
|
||||
ddhhccppdd [--pp --ppoorrtt]
|
||||
ddhhccppdd [ --pp _p_o_r_t ]
|
||||
|
||||
DDEESSCCRRIIPPTTIIOONN
|
||||
dhcpd(8) implements the Dynamic Host Configuration Protocol (DHCP) and
|
||||
the Internet Bootstrap Protocol (BOOTP). DHCP allows hosts on a TCP/IP
|
||||
network to request and be assigned IP addresses, and also to discover in-
|
||||
formation about the network to which they are attached. BOOTP provides
|
||||
similar but much more limited functionality.
|
||||
dhcpd(8) implements the Dynamic Host Configuration Proto-
|
||||
col (DHCP) and the Internet Bootstrap Protocol (BOOTP).
|
||||
DHCP allows hosts on a TCP/IP network to request and be
|
||||
assigned IP addresses, and also to discover information
|
||||
about the network to which they are attached. BOOTP pro-
|
||||
vides similar but much more limited functionality.
|
||||
|
||||
OOPPEERRAATTIIOONN
|
||||
The DHCP protocol allows a host which is unknown to the network adminis-
|
||||
trator to be automatically assigned a new IP address out of a pool of IP
|
||||
addresses for its network. In order for this to work, the network ad-
|
||||
ministrator allocates address pools in each subnet and enters them into
|
||||
the dhcpd.conf(5) file.
|
||||
The DHCP protocol allows a host which is unknown to the
|
||||
network administrator to be automatically assigned a new
|
||||
IP address out of a pool of IP addresses for its network.
|
||||
In order for this to work, the network administrator allo-
|
||||
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-
|
||||
able addresses on each subnet in memory. When a host requests an address
|
||||
using the DHCP protocol, dhcpd allocates an address for it. Each such
|
||||
host is assigned a lease, which expires after an amount of time chosen by
|
||||
the administrator (by default, one day). As leases expire, the hosts to
|
||||
which they are assigned are expected to renew the leases if they wish to
|
||||
continue to 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.
|
||||
On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and keeps the
|
||||
list of available addresses on each subnet in memory.
|
||||
When a host requests an address using the DHCP protocol,
|
||||
dhcpd allocates an address for it. Each such host is
|
||||
assigned a lease, which expires after an amount of time
|
||||
chosen by the administrator (by default, one day). As
|
||||
leases expire, the hosts to which they are assigned are
|
||||
expected to renew the leases if they wish to continue to
|
||||
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
|
||||
restarts, ddhhccppdd keeps a list of leases it has assigned in the
|
||||
dhcpd.leases(5) file. Before dhcpd grants a lease to a host, it records
|
||||
the lease in this file and makes sure that the contents of the file are
|
||||
flushed to disk. This ensures that even in the event of a system crash,
|
||||
ddhhccppdd will not forget about a lease that it has assigned. On startup,
|
||||
after reading the ddhhccppdd..ccoonnff file, ddhhccppdd reads the ddhhccppdd..lleeaasseess file to
|
||||
refresh its memory about what leases have been assigned.
|
||||
In order to keep track of leases across system reboots and
|
||||
server restarts, dhcpd keeps a list of leases it has
|
||||
assigned in the dhcpd.leases(5) file. Before dhcpd
|
||||
grants a lease to a host, it records the lease in this
|
||||
file and makes sure that the contents of the file are
|
||||
flushed to disk. This ensures that even in the event of
|
||||
a system crash, dhcpd will not forget about a lease that
|
||||
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
|
||||
to prevent the file from becoming arbitrarily large, from time to time
|
||||
ddhhccppdd creates a new ddhhccppdd..lleeaasseess file from its in-core lease database.
|
||||
Once this file has been written to disk, the old file is renamed
|
||||
ddhhccppdd..lleeaasseess~~, and the new file is renamed ddhhccppdd..lleeaasseess. If the system
|
||||
crashes in the middle of this process, whichever ddhhccppdd..lleeaasseess file re-
|
||||
mains will contain all the lease information, so there is no need for a
|
||||
special crash recovery process.
|
||||
New leases are appended to the end of the dhcpd.leases
|
||||
file. In order to prevent the file from becoming arbi-
|
||||
trarily large, from time to time dhcpd creates a new
|
||||
dhcpd.leases file from its in-core lease database. Once
|
||||
this file has been written to disk, the old file is
|
||||
renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed
|
||||
dhcpd.leases. If the system crashes in the middle of
|
||||
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-
|
||||
tained in //vvaarr//rruunn//ddhhccppdd..ppiidd, and then re-invoke ddhhccppdd.
|
||||
|
||||
1
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
The syntax of the dhcpd.conf(8) file is discussed seperately. This sec-
|
||||
tion should be used as an overview of the configuration process, and the
|
||||
dhcpd.conf(8) documentation should be consulted for detailed reference
|
||||
information.
|
||||
The syntax of the dhcpd.conf(8) file is discussed seper-
|
||||
ately. This section should be used as an overview of the
|
||||
configuration process, and the dhcpd.conf(8) documentation
|
||||
should be consulted for detailed reference information.
|
||||
|
||||
|
||||
SSuubbnneettss
|
||||
dhcpd(8) needs to know the subnet numbers and netmasks of all subnets for
|
||||
which it will be providing service. In addition, in order to dynamical-
|
||||
ly allocate addresses, it must be assigned one or more ranges of address-
|
||||
es on each subnet which it can in turn assign to client hosts as they
|
||||
boot. Thus, a very simple configuration providing DHCP support might
|
||||
look like this:
|
||||
dhcpd needs to know the subnet numbers and netmasks of all
|
||||
subnets for which it will be providing service. In addi-
|
||||
tion, in order to dynamically allocate addresses, it must
|
||||
be assigned one or more ranges of addresses on each subnet
|
||||
which it can in turn assign to client hosts as they boot.
|
||||
Thus, a very simple configuration providing DHCP support
|
||||
might look like this:
|
||||
|
||||
subnet 239.252.197.0 netmask 255.255.255.0
|
||||
range 239.252.197.10 239.252.197.250;
|
||||
subnet 239.252.197.0 netmask 255.255.255.0
|
||||
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
|
||||
range 239.252.197.10 239.252.197.107
|
||||
range 239.252.197.113 239.252.197.250;
|
||||
subnet 239.252.197.0 netmask 255.255.255.0
|
||||
range 239.252.197.10 239.252.197.107
|
||||
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
|
||||
DHCP leases can be assigned almost any length from zero seconds to infin-
|
||||
ity. What lease length makes sense for any given subnet, or for any
|
||||
given installation, will vary depending on the kinds of hosts being
|
||||
served.
|
||||
DHCP leases can be assigned almost any length from zero
|
||||
seconds to infinity. What lease length makes sense for
|
||||
any given subnet, or for any given installation, will vary
|
||||
depending on the kinds of hosts being served.
|
||||
|
||||
For example, in an office environment where systems are added from time
|
||||
to time and removed from time to time, but move relatively infrequently,
|
||||
it might make sense to allow lease times of a month of more. In a final
|
||||
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.
|
||||
For example, in an office environment where systems are
|
||||
added from time to time and removed from time to time, but
|
||||
move relatively infrequently, it might make sense to allow
|
||||
|
||||
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).
|
||||
2
|
||||
|
||||
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
|
||||
Each BOOTP client must be explicitly declared in the ddhhccppdd..ccoonnff file. A
|
||||
very basic client declaration will specify the client network interface's
|
||||
hardware address and the IP address to assign to that client. If the
|
||||
client needs to be able to load a boot file from the server, that file's
|
||||
name must be specified. A simple bootp client declaration might look
|
||||
like this:
|
||||
Each BOOTP client must be explicitly declared in the
|
||||
dhcpd.conf file. A very basic client declaration will
|
||||
specify the client network interface's hardware address
|
||||
and the IP address to assign to that client. If the
|
||||
client needs to be able to load a boot file from the
|
||||
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
|
||||
fixed-address 239.252.197.9
|
||||
filename "/tftpboot/haagen.boot";
|
||||
host haagen hardware ethernet 08:00:2b:4c:59:23
|
||||
fixed-address 239.252.197.9
|
||||
filename "/tftpboot/haagen.boot";
|
||||
|
||||
OOppttiioonnss
|
||||
DHCP (and also BOOTP with Vendor Extensions) provide a mechanism whereby
|
||||
the server can provide the client with information about how to configure
|
||||
its network interface (e.g., subnet mask), and also how the client can
|
||||
access various network services (e.g., DNS, IP routers, and so on).
|
||||
DHCP (and also BOOTP with Vendor Extensions) provide a
|
||||
mechanism whereby the server can provide the client with
|
||||
information about how to configure its network interface
|
||||
(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
|
||||
clients, also on a per-client basis. In the event that a BOOTP client
|
||||
declaration specifies options that are also specified in its subnet dec-
|
||||
laration, the options specified in the client declaration take prece-
|
||||
dence. An reasonably complete DHCP configuration might look something
|
||||
like this:
|
||||
These options can be specified on a per-subnet basis, and,
|
||||
for BOOTP clients, also on a per-client basis. In the
|
||||
event that a BOOTP client declaration specifies options
|
||||
that are also specified in its subnet declaration, the
|
||||
options specified in the client declaration take
|
||||
|
||||
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
|
||||
fixed-address 239.252.197.9
|
||||
filename "/tftpboot/haagen.boot"
|
||||
option domain-name-servers 192.5.5.1
|
||||
option domain-name "vix.com";
|
||||
3
|
||||
|
||||
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
|
||||
//eettcc//ddhhccppdd..ccoonnff, //eettcc//ddhhccppdd..lleeaasseess, //vvaarr//rruunn//ddhhccppdd..ppiidd,
|
||||
//eettcc//ddhhccppdd..lleeaasseess~~.
|
||||
//eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,,
|
||||
//vvaarr//ddbb//ddhhccppdd..lleeaasseess~~..
|
||||
|
||||
SSEEEE AALLSSOO
|
||||
dhcpd.conf(5), dhcpd.leases(5)
|
||||
dhcpd.conf(5), dhcpd.leases(5)
|
||||
|
||||
AAUUTTHHOORR
|
||||
dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
|
||||
Vixie Labs. Funding for this project was provided by the Internet Soft-
|
||||
ware Corporation. Information about the Internet Software Consortium can
|
||||
be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
|
||||
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
|
||||
contract with Vixie Labs. Funding for this project was
|
||||
provided by the Internet Software Corporation. Informa-
|
||||
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
|
||||
ddhhccppdd - Dynamic Host Configuration Protocol server
|
||||
dhcpd - Dynamic Host Configuration Protocol server
|
||||
|
||||
SSYYNNOOPPSSIISS
|
||||
ddhhccppdd [--pp --ppoorrtt]
|
||||
ddhhccppdd [ --pp _p_o_r_t ]
|
||||
|
||||
DDEESSCCRRIIPPTTIIOONN
|
||||
dhcpd(8) implements the Dynamic Host Configuration Protocol (DHCP) and
|
||||
the Internet Bootstrap Protocol (BOOTP). DHCP allows hosts on a TCP/IP
|
||||
network to request and be assigned IP addresses, and also to discover in-
|
||||
formation about the network to which they are attached. BOOTP provides
|
||||
similar but much more limited functionality.
|
||||
dhcpd(8) implements the Dynamic Host Configuration Proto-
|
||||
col (DHCP) and the Internet Bootstrap Protocol (BOOTP).
|
||||
DHCP allows hosts on a TCP/IP network to request and be
|
||||
assigned IP addresses, and also to discover information
|
||||
about the network to which they are attached. BOOTP pro-
|
||||
vides similar but much more limited functionality.
|
||||
|
||||
OOPPEERRAATTIIOONN
|
||||
The DHCP protocol allows a host which is unknown to the network adminis-
|
||||
trator to be automatically assigned a new IP address out of a pool of IP
|
||||
addresses for its network. In order for this to work, the network ad-
|
||||
ministrator allocates address pools in each subnet and enters them into
|
||||
the dhcpd.conf(5) file.
|
||||
The DHCP protocol allows a host which is unknown to the
|
||||
network administrator to be automatically assigned a new
|
||||
IP address out of a pool of IP addresses for its network.
|
||||
In order for this to work, the network administrator allo-
|
||||
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-
|
||||
able addresses on each subnet in memory. When a host requests an address
|
||||
using the DHCP protocol, dhcpd allocates an address for it. Each such
|
||||
host is assigned a lease, which expires after an amount of time chosen by
|
||||
the administrator (by default, one day). As leases expire, the hosts to
|
||||
which they are assigned are expected to renew the leases if they wish to
|
||||
continue to 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.
|
||||
On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and keeps the
|
||||
list of available addresses on each subnet in memory.
|
||||
When a host requests an address using the DHCP protocol,
|
||||
dhcpd allocates an address for it. Each such host is
|
||||
assigned a lease, which expires after an amount of time
|
||||
chosen by the administrator (by default, one day). As
|
||||
leases expire, the hosts to which they are assigned are
|
||||
expected to renew the leases if they wish to continue to
|
||||
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
|
||||
restarts, ddhhccppdd keeps a list of leases it has assigned in the
|
||||
dhcpd.leases(5) file. Before dhcpd grants a lease to a host, it records
|
||||
the lease in this file and makes sure that the contents of the file are
|
||||
flushed to disk. This ensures that even in the event of a system crash,
|
||||
ddhhccppdd will not forget about a lease that it has assigned. On startup,
|
||||
after reading the ddhhccppdd..ccoonnff file, ddhhccppdd reads the ddhhccppdd..lleeaasseess file to
|
||||
refresh its memory about what leases have been assigned.
|
||||
In order to keep track of leases across system reboots and
|
||||
server restarts, dhcpd keeps a list of leases it has
|
||||
assigned in the dhcpd.leases(5) file. Before dhcpd
|
||||
grants a lease to a host, it records the lease in this
|
||||
file and makes sure that the contents of the file are
|
||||
flushed to disk. This ensures that even in the event of
|
||||
a system crash, dhcpd will not forget about a lease that
|
||||
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
|
||||
to prevent the file from becoming arbitrarily large, from time to time
|
||||
ddhhccppdd creates a new ddhhccppdd..lleeaasseess file from its in-core lease database.
|
||||
Once this file has been written to disk, the old file is renamed
|
||||
ddhhccppdd..lleeaasseess~~, and the new file is renamed ddhhccppdd..lleeaasseess. If the system
|
||||
crashes in the middle of this process, whichever ddhhccppdd..lleeaasseess file re-
|
||||
mains will contain all the lease information, so there is no need for a
|
||||
special crash recovery process.
|
||||
New leases are appended to the end of the dhcpd.leases
|
||||
file. In order to prevent the file from becoming arbi-
|
||||
trarily large, from time to time dhcpd creates a new
|
||||
dhcpd.leases file from its in-core lease database. Once
|
||||
this file has been written to disk, the old file is
|
||||
renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed
|
||||
dhcpd.leases. If the system crashes in the middle of
|
||||
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-
|
||||
tained in //vvaarr//rruunn//ddhhccppdd..ppiidd, and then re-invoke ddhhccppdd.
|
||||
|
||||
1
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
The syntax of the dhcpd.conf(8) file is discussed seperately. This sec-
|
||||
tion should be used as an overview of the configuration process, and the
|
||||
dhcpd.conf(8) documentation should be consulted for detailed reference
|
||||
information.
|
||||
The syntax of the dhcpd.conf(8) file is discussed seper-
|
||||
ately. This section should be used as an overview of the
|
||||
configuration process, and the dhcpd.conf(8) documentation
|
||||
should be consulted for detailed reference information.
|
||||
|
||||
|
||||
SSuubbnneettss
|
||||
dhcpd(8) needs to know the subnet numbers and netmasks of all subnets for
|
||||
which it will be providing service. In addition, in order to dynamical-
|
||||
ly allocate addresses, it must be assigned one or more ranges of address-
|
||||
es on each subnet which it can in turn assign to client hosts as they
|
||||
boot. Thus, a very simple configuration providing DHCP support might
|
||||
look like this:
|
||||
dhcpd needs to know the subnet numbers and netmasks of all
|
||||
subnets for which it will be providing service. In addi-
|
||||
tion, in order to dynamically allocate addresses, it must
|
||||
be assigned one or more ranges of addresses on each subnet
|
||||
which it can in turn assign to client hosts as they boot.
|
||||
Thus, a very simple configuration providing DHCP support
|
||||
might look like this:
|
||||
|
||||
subnet 239.252.197.0 netmask 255.255.255.0
|
||||
range 239.252.197.10 239.252.197.250;
|
||||
subnet 239.252.197.0 netmask 255.255.255.0
|
||||
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
|
||||
range 239.252.197.10 239.252.197.107
|
||||
range 239.252.197.113 239.252.197.250;
|
||||
subnet 239.252.197.0 netmask 255.255.255.0
|
||||
range 239.252.197.10 239.252.197.107
|
||||
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
|
||||
DHCP leases can be assigned almost any length from zero seconds to infin-
|
||||
ity. What lease length makes sense for any given subnet, or for any
|
||||
given installation, will vary depending on the kinds of hosts being
|
||||
served.
|
||||
DHCP leases can be assigned almost any length from zero
|
||||
seconds to infinity. What lease length makes sense for
|
||||
any given subnet, or for any given installation, will vary
|
||||
depending on the kinds of hosts being served.
|
||||
|
||||
For example, in an office environment where systems are added from time
|
||||
to time and removed from time to time, but move relatively infrequently,
|
||||
it might make sense to allow lease times of a month of more. In a final
|
||||
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.
|
||||
For example, in an office environment where systems are
|
||||
added from time to time and removed from time to time, but
|
||||
move relatively infrequently, it might make sense to allow
|
||||
|
||||
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).
|
||||
2
|
||||
|
||||
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
|
||||
Each BOOTP client must be explicitly declared in the ddhhccppdd..ccoonnff file. A
|
||||
very basic client declaration will specify the client network interface's
|
||||
hardware address and the IP address to assign to that client. If the
|
||||
client needs to be able to load a boot file from the server, that file's
|
||||
name must be specified. A simple bootp client declaration might look
|
||||
like this:
|
||||
Each BOOTP client must be explicitly declared in the
|
||||
dhcpd.conf file. A very basic client declaration will
|
||||
specify the client network interface's hardware address
|
||||
and the IP address to assign to that client. If the
|
||||
client needs to be able to load a boot file from the
|
||||
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
|
||||
fixed-address 239.252.197.9
|
||||
filename "/tftpboot/haagen.boot";
|
||||
host haagen hardware ethernet 08:00:2b:4c:59:23
|
||||
fixed-address 239.252.197.9
|
||||
filename "/tftpboot/haagen.boot";
|
||||
|
||||
OOppttiioonnss
|
||||
DHCP (and also BOOTP with Vendor Extensions) provide a mechanism whereby
|
||||
the server can provide the client with information about how to configure
|
||||
its network interface (e.g., subnet mask), and also how the client can
|
||||
access various network services (e.g., DNS, IP routers, and so on).
|
||||
DHCP (and also BOOTP with Vendor Extensions) provide a
|
||||
mechanism whereby the server can provide the client with
|
||||
information about how to configure its network interface
|
||||
(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
|
||||
clients, also on a per-client basis. In the event that a BOOTP client
|
||||
declaration specifies options that are also specified in its subnet dec-
|
||||
laration, the options specified in the client declaration take prece-
|
||||
dence. An reasonably complete DHCP configuration might look something
|
||||
like this:
|
||||
These options can be specified on a per-subnet basis, and,
|
||||
for BOOTP clients, also on a per-client basis. In the
|
||||
event that a BOOTP client declaration specifies options
|
||||
that are also specified in its subnet declaration, the
|
||||
options specified in the client declaration take
|
||||
|
||||
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
|
||||
fixed-address 239.252.197.9
|
||||
filename "/tftpboot/haagen.boot"
|
||||
option domain-name-servers 192.5.5.1
|
||||
option domain-name "vix.com";
|
||||
3
|
||||
|
||||
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
|
||||
//eettcc//ddhhccppdd..ccoonnff, //eettcc//ddhhccppdd..lleeaasseess, //vvaarr//rruunn//ddhhccppdd..ppiidd,
|
||||
//eettcc//ddhhccppdd..lleeaasseess~~.
|
||||
//eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,,
|
||||
//vvaarr//ddbb//ddhhccppdd..lleeaasseess~~..
|
||||
|
||||
SSEEEE AALLSSOO
|
||||
dhcpd.conf(5), dhcpd.leases(5)
|
||||
dhcpd.conf(5), dhcpd.leases(5)
|
||||
|
||||
AAUUTTHHOORR
|
||||
dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
|
||||
Vixie Labs. Funding for this project was provided by the Internet Soft-
|
||||
ware Corporation. Information about the Internet Software Consortium can
|
||||
be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
|
||||
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
|
||||
contract with Vixie Labs. Funding for this project was
|
||||
provided by the Internet Software Corporation. Informa-
|
||||
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