*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->OpenBSD man pages -> dhcpd (8)              



NAME    [Toc]    [Back]

     dhcpd - Dynamic Host Configuration Protocol Server

SYNOPSIS    [Toc]    [Back]

     dhcpd [-df] [-c config-file] [-l lease-file] [if0 [... ifN]]

DESCRIPTION    [Toc]    [Back]

     The  Internet Software Consortium DHCP Server, dhcpd, 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  information
about the network
     to  which  they  are attached.  BOOTP provides similar functionality, with
     certain restrictions.

     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
  allocates  address pools in each subnet and enters
them into the
     dhcpd.conf(5) file.

     On startup, dhcpd reads the dhcpd.conf  file  and  stores  a
list of available
  addresses on each subnet in memory.  When a client requests an address
 using the DHCP protocol, dhcpd  allocates  an  address
for it.  Each
     client is assigned a lease, which expires after an amount of
time chosen
     by the administrator (by default, one day).   Before  leases
expire, the
     clients  to  which leases are assigned are expected to renew
them in order
     to continue to use the addresses.  Once a lease has expired,
the client
     to  which  that lease was assigned is no longer permitted to
use the leased
     IP address.

     In order to keep track of leases across system  reboots  and
     restarts,  dhcpd  keeps  a list of leases it has assigned in
     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.

     BOOTP support is also provided by this server.  Unlike DHCP,
     protocol does not provide a protocol for recovering  dynamically-assigned
     addresses  once they are no longer needed.  It is still possible to dynamically
 assign addresses to BOOTP clients, but some  administrative process
     for  reclaiming  addresses  is required.  By default, leases
are granted to
     BOOTP clients in perpetuity, although the  network  administrator may set
     an  earlier  cutoff date or a shorter lease length for BOOTP
leases if that
     makes sense.

     BOOTP clients may also be served in the  old  standard  way,
which is simply
     to  provide  a  declaration  in the dhcpd.conf file for each
BOOTP client,
     permanently assigning an address to each client.

     Whenever changes are made to the dhcpd.conf file, dhcpd must
be restarted.
   Because the DHCP server database is not as lightweight
as a BOOTP
     database, dhcpd does not automatically restart  itself  when
it sees a
     change to the dhcpd.conf file.

     DHCP  traffic  always bypasses IPsec.  Otherwise there could
be situations
     when a server has an IPsec  SA  for  the  client  and  sends
replies over that,
     which a newly booted client would not be able to grasp.

COMMAND LINE    [Toc]    [Back]

     The  names  of  the network interfaces on which dhcpd should
listen for
     broadcasts may be  specified  on  the  command  line.   This
should be done on
     systems  where dhcpd is unable to identify non-broadcast interfaces, but
     should not be required on other systems.   If  no  interface
names are specified
  on  the command line, dhcpd will identify all network
     which are up, eliminating non-broadcast interfaces if possible, and listen
 for DHCP broadcasts on each interface.

     The options are as follows:

     -c config-file
             Use  an  alternate  configuration file, config-file.
Because of the
             importance of using the same lease database  at  all
times when
             running  dhcpd  in production, this option should be
used only for
             testing database files in a non-production  environment.

     -d       Force  dhcpd  to log to stderr.  This can be useful
for debugging,
             and also at sites where a complete log of  all  dhcp
activity must
             be kept, but syslogd(8) is not reliable or otherwise
cannot be
             used.  Normally, dhcpd will log all output using the
             function with the log facility set to LOG_DAEMON.

     -f       Run  dhcpd as a foreground process, rather than allowing it to run
             as a daemon in the background.  This is useful  when
running dhcpd
             under  a debugger, or when running it out of inittab
on System V

     -l lease-file
             Use an alternate lease file, lease-file.  Because of
the importance
  of using the same lease database at all times
when running
             dhcpd in production, this option should be used only
for testing
             lease files in a non-production environment.

CONFIGURATION    [Toc]    [Back]

     The  syntax of the dhcpd.conf(5) file is discussed separately.  This section
 should be used as an overview of the configuration process, and the
     dhcpd.conf(5) documentation should be consulted for detailed

          dhcpd needs to know the subnet numbers and netmasks  of
all subnets
          for  which  it will be providing service.  In addition,
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 netmask {

          Multiple address ranges may be specified like this:

                subnet netmask {

          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.

     Lease Lengths
          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 assign 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 netmask {
                  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.

     BOOTP Support
          Each  BOOTP  client  must be explicitly declared in the
          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;
                  filename "haagen.boot";

          DHCP (and also BOOTP with Vendor Extensions) provides a
          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.,
          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
          client declaration  specifies  options  that  are  also
specified in its
          subnet declaration, the options specified in the client
          take precedence.  A reasonably complete DHCP configuration might
          look something like this:

                subnet netmask {
                  default-lease-time 600 max-lease-time 7200;
                  option subnet-mask;
                  option broadcast-address;
                  option routers;
                  option    domain-name-servers,;
                  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

                host haagen {
                  hardware ethernet 08:00:2b:4c:59:23;
                  filename "haagen.boot";
                  option domain-name-servers;
                  option domain-name "vix.com";

     A more complete description of the dhcpd.conf file syntax is
provided in

FILES    [Toc]    [Back]

     /etc/dhcpd.conf          DHCPD configuration file.
     /var/db/dhcpd.leases     DHCPD lease file.

SEE ALSO    [Toc]    [Back]

     dhcpd.conf(5), dhcpd.leases(5), dhclient(8), dhcp(8), dhcrelay(8),

AUTHORS    [Toc]    [Back]

     dhcpd was written by Ted Lemon <mellon@vix.com> under a contract with
     Vixie Labs.

     The current implementation was reworked by
     Henning Brauer <henning@openbsd.org>.

BUGS    [Toc]    [Back]

     We  realize that it would be nice if one could send a SIGHUP
to the server
     and have it reload the database.  This  is  not  technically
impossible, but
     it would require a great deal of work, our resources are extremely limited,
 and they can be better spent elsewhere.  So please don't
     about  this  on  the  mailing list unless you're prepared to
fund a project
     to implement this feature, or prepared to do it yourself.

OpenBSD     3.6                         January      1,      1995
[ Back ]
 Similar pages
Name OS Title
dhcpclient HP-UX Client for Dynamic Host Configuration Protocol Server
dhcp_bootp IRIX proclaim server for Dynamic Host Configuration Protocol
dhcpv6d HP-UX Dynamic Host Configuration Protocol Server daemon for IPv6
dhcp-options OpenBSD Dynamic Host Configuration Protocol options
dhclient Linux Dynamic Host Configuration Protocol Client
dhcp-options FreeBSD Dynamic Host Configuration Protocol options
dhclient FreeBSD Dynamic Host Configuration Protocol Client
dhcp-options-dhclient Linux Dynamic Host Configuration Protocol options
proclaim IRIX client for Dynamic Host Configuration Protocol (DHCP)
dhclient OpenBSD Dynamic Host Configuration Protocol (DHCP) Client
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service