1dhcpd(8)                    System Manager's Manual                   dhcpd(8)
2
3
4

NAME

6       dhcpd - Dynamic Host Configuration Protocol Server
7

SYNOPSIS

9       dhcpd  [  -p port ] [ -f ] [ -d ] [ -q ] [ -t | -T ] [ -4 | -6 ] [ -4o6
10       port ] [ -s server ] [ -cf config-file ] [ -lf lease-file ] [ -pf  pid-
11       file  ]  [ --no-pid ] [ -user user ] [ -group group ] [ -chroot dir ] [
12       -tf trace-output-file ] [ -play trace-playback-file ] [ if0 [ ...ifN  ]
13       ]
14
15       dhcpd --version
16

DESCRIPTION

18       The  Internet  Systems  Consortium  DHCP  Server, dhcpd, implements the
19       Dynamic Host Configuration Protocol (DHCP) and the  Internet  Bootstrap
20       Protocol (BOOTP).  DHCP allows hosts on a TCP/IP network to request and
21       be assigned IP addresses, and also to discover  information  about  the
22       network to which they are attached.  BOOTP provides similar functional‐
23       ity, with certain restrictions.
24

OPERATION

26       The DHCP protocol allows a host which is unknown to the network  admin‐
27       istrator to be automatically assigned a new IP address out of a pool of
28       IP addresses for its network.  In order for this to work,  the  network
29       administrator  allocates  address  pools in each subnet and enters them
30       into the dhcpd.conf(5) file.
31
32       There are two versions of the DHCP  protocol  DHCPv4  and  DHCPv6.   At
33       startup  the  server  may be started for one or the other via the -4 or
34       -6 arguments.
35
36       On startup, dhcpd reads the dhcpd.conf file and stores a list of avail‐
37       able  addresses  on  each  subnet in memory.  When a client requests an
38       address using the DHCP protocol, dhcpd allocates  an  address  for  it.
39       Each  client is assigned a lease, which expires after an amount of time
40       chosen by the administrator  (by  default,  one  day).   Before  leases
41       expire,  the clients to which leases are assigned are expected to renew
42       them in order to continue to use  the  addresses.   Once  a  lease  has
43       expired,  the client to which that lease was assigned is no longer per‐
44       mitted to use the leased IP address.
45
46       In order to keep track of  leases  across  system  reboots  and  server
47       restarts,  dhcpd  keeps  a  list  of  leases  it  has  assigned  in the
48       dhcpd.leases(5) file.  Before dhcpd  grants  a  lease  to  a  host,  it
49       records  the lease in this file and makes sure that the contents of the
50       file are flushed to disk.  This ensures that even in  the  event  of  a
51       system crash, dhcpd will not forget about a lease that it has assigned.
52       On  startup,  after  reading  the  dhcpd.conf  file,  dhcpd  reads  the
53       dhcpd.leases  file  to  refresh  its memory about what leases have been
54       assigned.
55
56       New leases are appended to the end of the dhcpd.leases file.  In  order
57       to  prevent the file from becoming arbitrarily large, from time to time
58       dhcpd creates a new dhcpd.leases file from its in-core lease  database.
59       Once  this  file  has  been  written  to  disk, the old file is renamed
60       dhcpd.leases~, and the new file is renamed dhcpd.leases.  If the system
61       crashes  in  the  middle  of  this process, whichever dhcpd.leases file
62       remains will contain all the lease information, so there is no need for
63       a special crash recovery process.
64
65       BOOTP  support is also provided by this server.  Unlike DHCP, the BOOTP
66       protocol does  not  provide  a  protocol  for  recovering  dynamically-
67       assigned  addresses once they are no longer needed.  It is still possi‐
68       ble to dynamically assign addresses to BOOTP clients, but some adminis‐
69       trative  process  for  reclaiming  addresses  is required.  By default,
70       leases are granted to BOOTP clients in perpetuity, although the network
71       administrator  may set an earlier cutoff date or a shorter lease length
72       for BOOTP leases if that makes sense.
73
74       BOOTP clients may also be served in the old standard way, which  is  to
75       simply  provide  a  declaration  in  the dhcpd.conf file for each BOOTP
76       client, permanently assigning an address to each client.
77
78       Whenever changes are  made  to  the  dhcpd.conf  file,  dhcpd  must  be
79       restarted.  To restart dhcpd, send a SIGTERM (signal 15) to the process
80       ID contained in /var/run/dhcpd.pid, and then re-invoke dhcpd.   Because
81       the  DHCP  server  database  is not as lightweight as a BOOTP database,
82       dhcpd does not automatically restart itself when it sees  a  change  to
83       the dhcpd.conf file.
84
85       Note:  We get a lot of complaints about this.  We realize that it would
86       be nice if one could send a SIGHUP to the server and have it reload the
87       database.   This  is not technically impossible, but it would require a
88       great deal of work, our resources are extremely limited, and  they  can
89       be  better spent elsewhere.  So please don't complain about this on the
90       mailing list unless you're prepared to fund a project to implement this
91       feature, or prepared to do it yourself.
92

COMMAND LINE

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

COMMAND LINE OPTIONS

103       -4     Run as a DHCP server. This is the default and cannot be combined
104              with -6.
105
106       -6     Run as a DHCPv6 server. This cannot be combined with -4.
107
108       -4o6 port
109              Participate in the DHCPv4 over DHCPv6 protocol specified by  RFC
110              7341.  This associates a DHCPv4 and a DHCPv6 server to allow the
111              v4 server to receive v4 requests that were encapsulated in a  v6
112              packet.  Communication between the two servers is done on a pair
113              of UDP sockets bound to ::1 port and port + 1. Both servers must
114              be launched using the same port argument.
115
116       -p port
117              The  UDP  port number on which dhcpd should listen.  If unspeci‐
118              fied dhcpd uses the default port of 67.  This is  mostly  useful
119              for debugging purposes.
120
121       -s address
122              Specify  an  address  or  host  name  to which dhcpd should send
123              replies rather than  the  broadcast  address  (255.255.255.255).
124              This option is only supported in IPv4.
125
126       -f     Force  dhcpd to run as a foreground process instead of as a dae‐
127              mon in the background.  This is useful when running dhcpd  under
128              a  debugger,  or when running it out of inittab on System V sys‐
129              tems.
130
131       -d     Send log messages to the standard error descriptor.  This can be
132              useful  for debugging, and also at sites where a complete log of
133              all dhcp activity must be kept but syslogd is  not  reliable  or
134              otherwise  cannot  be used.  Normally, dhcpd will log all output
135              using the syslog(3)  function  with  the  log  facility  set  to
136              LOG_DAEMON.   Note  that -d implies -f (the daemon will not fork
137              itself into the background).
138
139       -q     Be quiet at startup.  This suppresses the printing of the entire
140              copyright  message during startup.  This might be desirable when
141              starting dhcpd from a system startup script (e.g., /etc/rc).
142
143       -t     Test the configuration file.  The server tests the configuration
144              file  for  correct  syntax,  but will not attempt to perform any
145              network operations.  This can be used to test a  new  configura‐
146              tion file automatically before installing it.
147
148       -T     Test  the  lease file.  The server tests the lease file for cor‐
149              rect syntax, but will not attempt to perform any network  opera‐
150              tions.   This can be used to test a new lease file automatically
151              before installing it.
152
153       -user user
154              Setuid to user after completing privileged operations,  such  as
155              creating  sockets  that  listen  on privileged ports.  This also
156              causes the lease file to be owned by user.  This option is  only
157              available  if  the  code  was  compiled  with the PARANOIA patch
158              (./configure --enable-paranoia).
159
160       -group group
161              Setgid to group after completing privileged operations, such  as
162              creating  sockets  that  listen  on privileged ports.  This also
163              causes the lease file to use group.  This option is only  avail‐
164              able if the code was compiled with the PARANOIA patch (./config‐
165              ure --enable-paranoia).
166
167       -chroot dir
168              Chroot to directory.  This may occur before or after reading the
169              configuration  files  depending on whether the code was compiled
170              with the  EARLY_CHROOT  option  enabled  (./configure  --enable-
171              early-chroot).   This  option  is only available if the code was
172              compiled with the  PARANOIA  patch  (./configure  --enable-para‐
173              noia).
174
175       -tf tracefile
176              Specify a file into which the entire startup state of the server
177              and all the transactions it processes are logged.  This  can  be
178              useful  in  submitting  bug  reports - if you are getting a core
179              dump every so often, you can  start  the  server  with  the  -tf
180              option and then, when the server dumps core, the trace file will
181              contain all the transactions that led up to it dumping core,  so
182              that the problem can be easily debugged with -play.
183
184       -play playfile
185              Specify a file from which the entire startup state of the server
186              and all the transactions  it  processed  are  read.   The  -play
187              option must be specified with an alternate lease file, using the
188              -lf switch, so that the DHCP server doesn't wipe out your exist‐
189              ing  lease file with its test data.  The DHCP server will refuse
190              to operate in playback mode  unless  you  specify  an  alternate
191              lease file.
192
193       --version
194              Print version number and exit.
195
196       Modifying  default file locations: The following options can be used to
197       modify the locations dhcpd uses for its files.  Because of  the  impor‐
198       tance  of using the same lease database at all times when running dhcpd
199       in production, these options should be  used  only  for  testing  lease
200       files or database files in a non-production environment.
201
202       -cf config-file
203              Path to alternate configuration file.
204
205       -lf lease-file
206              Path to alternate lease file.
207
208       -pf pid-file
209              Path to alternate pid file.
210
211       --no-pid
212              Option  to  disable  writing  pid files.  By default the program
213              will write a pid file.  If the  program  is  invoked  with  this
214              option it will not check for an existing server process.
215

PORTS

217       During operations the server may use multiple UDP and TCP ports to pro‐
218       vide different functions.  Which ports are opened depends on  both  the
219       way  you compiled your code and the configuration you supply.  The fol‐
220       lowing should provide you an idea of what ports may be in use.
221
222       Normally a DHCPv4 server will open a raw UDP socket to receive and send
223       most  DHCPv4  packets.   It also opens a fallback UDP socket for use in
224       sending unicast packets.  Normally these will both use the  well  known
225       port number for BOOTPS.
226
227       For  each DHCPv4 failover peer you list in the configuration file there
228       will be a TCP socket listening for connections on the  ports  specified
229       in  the  configuration  file.   When  the  peer  connects there will be
230       another socket for the established  connection.   For  the  established
231       connection  the side (primary or secondary) opening the connection will
232       use a random port.
233
234       For  DHCPv6  the  server  opens  a  UDP  socket  on  the   well   known
235       dhcpv6-server port.
236
237       The  server  opens  an  icmp socket for doing ping requests to check if
238       addresses are in use.
239
240       If you have included an omapi-port statement in your configuration file
241       then the server will open a TCP socket on that port to listen for OMPAI
242       connections.  When something connects another port will be used for the
243       established connection.
244
245       When  DDNS  is enabled at compile time (see includes/site.h) the server
246       will open both a v4 and a v6 UDP socket on random  ports,  unless  DDNS
247       updates  are  globally disabled by setting ddns-update-style to none in
248       the configuration file.
249

CONFIGURATION

251       The syntax of the dhcpd.conf(5) file  is  discussed  separately.   This
252       section should be used as an overview of the configuration process, and
253       the dhcpd.conf(5) documentation should be consulted for detailed refer‐
254       ence information.
255

Subnets

257       dhcpd  needs to know the subnet numbers and netmasks of all subnets for
258       which it will be providing service.  In addition, in order  to  dynami‐
259       cally  allocate  addresses,  it  must be assigned one or more ranges of
260       addresses on each subnet which it can in turn assign to client hosts as
261       they  boot.   Thus,  a very simple configuration providing DHCP support
262       might look like this:
263
264            subnet 239.252.197.0 netmask 255.255.255.0 {
265              range 239.252.197.10 239.252.197.250;
266            }
267
268       Multiple address ranges may be specified like this:
269
270            subnet 239.252.197.0 netmask 255.255.255.0 {
271              range 239.252.197.10 239.252.197.107;
272              range 239.252.197.113 239.252.197.250;
273            }
274
275       If a subnet will only be provided with BOOTP  service  and  no  dynamic
276       address  assignment, the range clause can be left out entirely, but the
277       subnet statement must appear.
278

Lease Lengths

280       DHCP leases can be assigned almost any  length  from  zero  seconds  to
281       infinity.   What  lease length makes sense for any given subnet, or for
282       any given installation, will vary depending on the kinds of hosts being
283       served.
284
285       For example, in an office environment where systems are added from time
286       to time and removed from time  to  time,  but  move  relatively  infre‐
287       quently,  it  might make sense to allow lease times of a month or more.
288       In a final test environment on a manufacturing floor, it may make  more
289       sense  to  assign a maximum lease length of 30 minutes - enough time to
290       go through a simple test procedure on a network appliance before  pack‐
291       aging it up for delivery.
292
293       It  is  possible  to specify two lease lengths: the default length that
294       will be assigned if a client  doesn't  ask  for  any  particular  lease
295       length,  and a maximum lease length.  These are specified as clauses to
296       the subnet command:
297
298            subnet 239.252.197.0 netmask 255.255.255.0 {
299              range 239.252.197.10 239.252.197.107;
300              default-lease-time 600;
301              max-lease-time 7200;
302            }
303
304       This particular subnet declaration specifies a default  lease  time  of
305       600  seconds  (ten  minutes),  and a maximum lease time of 7200 seconds
306       (two hours).  Other common values would be 86400 (one day), 604800 (one
307       week) and 2592000 (30 days).
308
309       Each subnet need not have the same lease—in the case of an office envi‐
310       ronment and a manufacturing environment served by the same DHCP server,
311       it  might  make  sense  to have widely disparate values for default and
312       maximum lease times on each subnet.
313

BOOTP Support

315       Each BOOTP client must be explicitly declared in the  dhcpd.conf  file.
316       A  very basic client declaration will specify the client network inter‐
317       face's hardware address and the IP address to assign  to  that  client.
318       If  the  client  needs  to be able to load a boot file from the server,
319       that file's name must be specified.  A simple bootp client  declaration
320       might look like this:
321
322            host haagen {
323              hardware ethernet 08:00:2b:4c:59:23;
324              fixed-address 239.252.197.9;
325              filename "/tftpboot/haagen.boot";
326            }
327

Options

329       DHCP  (and  also  BOOTP  with  Vendor  Extensions)  provide a mechanism
330       whereby the server can provide the client with information about how to
331       configure  its  network interface (e.g., subnet mask), and also how the
332       client can access various network services (e.g., DNS, IP routers,  and
333       so on).
334
335       These  options  can  be specified on a per-subnet basis, and, for BOOTP
336       clients, also on a per-client basis.  In the event that a BOOTP  client
337       declaration  specifies  options  that  are also specified in its subnet
338       declaration, the options  specified  in  the  client  declaration  take
339       precedence.   A reasonably complete DHCP configuration might look some‐
340       thing like this:
341
342            subnet 239.252.197.0 netmask 255.255.255.0 {
343              range 239.252.197.10 239.252.197.250;
344              default-lease-time 600 max-lease-time 7200;
345              option subnet-mask 255.255.255.0;
346              option broadcast-address 239.252.197.255;
347              option routers 239.252.197.1;
348              option domain-name-servers 239.252.197.2, 239.252.197.3;
349              option domain-name "isc.org";
350            }
351
352       A bootp host on that subnet that needs to be in a different domain  and
353       use a different name server might be declared as follows:
354
355            host haagen {
356              hardware ethernet 08:00:2b:4c:59:23;
357              fixed-address 239.252.197.9;
358              filename "/tftpboot/haagen.boot";
359              option domain-name-servers 192.5.5.1;
360              option domain-name "example.com";
361            }
362
363       A  more  complete description of the dhcpd.conf file syntax is provided
364       in dhcpd.conf(5).
365

OMAPI

367       The DHCP server provides the capability to modify some of its  configu‐
368       ration while it is running, without stopping it, modifying its database
369       files, and restarting it.  This capability is currently provided  using
370       OMAPI  - an API for manipulating remote objects.  OMAPI clients connect
371       to the server using TCP/IP, authenticate,  and  can  then  examine  the
372       server's current status and make changes to it.
373
374       Rather  than  implementing the underlying OMAPI protocol directly, user
375       programs should use the dhcpctl API or  OMAPI  itself.   Dhcpctl  is  a
376       wrapper  that  handles  some of the housekeeping chores that OMAPI does
377       not do automatically.  Dhcpctl and OMAPI are documented  in  dhcpctl(3)
378       and omapi(3).
379
380       OMAPI  exports  objects,  which can then be examined and modified.  The
381       DHCP server exports the following objects: lease, host,  failover-state
382       and  group.   Each  object  has  a number of methods that are provided:
383       lookup, create, and destroy.  In addition, it is possible  to  look  at
384       attributes  that  are  stored  on  objects, and in some cases to modify
385       those attributes.
386

THE LEASE OBJECT

388       Leases can't currently be created or destroyed, but they can be  looked
389       up to examine and modify their state.
390
391       Leases have the following attributes:
392
393       state integer lookup, examine
394            1 = free
395            2 = active
396            3 = expired
397            4 = released
398            5 = abandoned
399            6 = reset
400            7 = backup
401            8 = reserved
402            9 = bootp
403
404       ip-address data lookup, examine
405            The IP address of the lease.
406
407       dhcp-client-identifier data lookup, examine, update
408            The  client  identifier  that the client used when it acquired the
409            lease.  Not all clients send client identifiers, so  this  may  be
410            empty.
411
412       client-hostname data examine, update
413            The value the client sent in the host-name option.
414
415       host handle examine
416            the host declaration associated with this lease, if any.
417
418       subnet handle examine
419            the subnet object associated with this lease (the subnet object is
420            not currently supported).
421
422       pool handle examine
423            the pool object associated with this lease (the pool object is not
424            currently supported).
425
426       billing-class handle examine
427            the  handle  to the class to which this lease is currently billed,
428            if any (the class object is not currently supported).
429
430       hardware-address data examine, update
431            the hardware address (chaddr) field sent by  the  client  when  it
432            acquired its lease.
433
434       hardware-type integer examine, update
435            the type of the network interface that the client reported when it
436            acquired its lease.
437
438       ends time examine
439            the time when the lease's current state ends, as understood by the
440            client.
441
442       tstp time examine
443            the time when the lease's current state ends, as understood by the
444            server.
445       tsfp time examine
446            the adjusted time when the lease's current state ends,  as  under‐
447            stood  by  the  failover  peer (if there is no failover peer, this
448            value is undefined).  Generally this value is  only  adjusted  for
449            expired,  released,  or reset leases while the server is operating
450            in partner-down state, and otherwise is simply the value  supplied
451            by the peer.
452       atsfp time examine
453            the actual tsfp value sent from the peer.  This value is forgotten
454            when a lease binding state change is made, to facilitate  retrans‐
455            mission logic.
456
457       cltt time examine
458            The time of the last transaction with the client on this lease.
459

THE HOST OBJECT

461       Hosts  can be created, destroyed, looked up, examined and modified.  If
462       a host declaration is created or deleted using OMAPI, that  information
463       will be recorded in the dhcpd.leases file.  It is permissible to delete
464       host declarations that are declared in the dhcpd.conf file.
465
466       Hosts have the following attributes:
467
468       name data lookup, examine, modify
469            the name of the host declaration.  This name must be unique  among
470            all host declarations.
471
472       group handle examine, modify
473            the  named group associated with the host declaration, if there is
474            one.
475
476       hardware-address data lookup, examine, modify
477            the link-layer address that will be used to match the  client,  if
478            any.  Only valid if hardware-type is also present.
479
480       hardware-type integer lookup, examine, modify
481            the  type  of the network interface that will be used to match the
482            client, if any.  Only valid if hardware-address is also present.
483
484       dhcp-client-identifier data lookup, examine, modify
485            the dhcp-client-identifier option that will be used to  match  the
486            client, if any.
487
488       ip-address data examine, modify
489            a  fixed  IP  address  which  is  reserved  for a DHCP client that
490            matches this host  declaration.   The  IP  address  will  only  be
491            assigned  to  the client if it is valid for the network segment to
492            which the client is connected.
493
494       statements data modify
495            a list of statements in the format of  the  dhcpd.conf  file  that
496            will  be executed whenever a message from the client is being pro‐
497            cessed.
498
499       known integer examine, modify
500            if nonzero, indicates that a client matching this host declaration
501            will  be  treated  as  known  in  pool permit lists.  If zero, the
502            client will not be treated as known.
503

THE GROUP OBJECT

505       Named groups can be created, destroyed, looked up, examined  and  modi‐
506       fied.   If  a group declaration is created or deleted using OMAPI, that
507       information will be recorded in the dhcpd.leases file.  It is permissi‐
508       ble  to  delete  group declarations that are declared in the dhcpd.conf
509       file.
510
511       Named groups currently can only be associated with hosts - this  allows
512       one  set of statements to be efficiently attached to more than one host
513       declaration.
514
515       Groups have the following attributes:
516
517       name data
518            the name of the group.  All groups that are  created  using  OMAPI
519            must have names, and the names must be unique among all groups.
520
521       statements data
522            a  list  of  statements  in the format of the dhcpd.conf file that
523            will be executed whenever a message from a client whose host  dec‐
524            laration references this group is processed.
525

THE CONTROL OBJECT

527       The  control  object allows you to shut the server down.  If the server
528       is doing failover with another peer, it will make  a  clean  transition
529       into  the  shutdown  state and notify its peer, so that the peer can go
530       into partner down, and then record the "recover"  state  in  the  lease
531       file so that when the server is restarted, it will automatically resyn‐
532       chronize with its peer.
533
534       On shutdown the server will also attempt to cleanly shut down all OMAPI
535       connections.   If  these  connections do not go down cleanly after five
536       seconds, they are shut down preemptively.  It can take as  much  as  25
537       seconds from the beginning of the shutdown process to the time that the
538       server actually exits.
539
540       To shut the server down, open its control  object  and  set  the  state
541       attribute to 2.
542

THE FAILOVER-STATE OBJECT

544       The  failover-state  object  is the object that tracks the state of the
545       failover protocol as it is being managed for  a  given  failover  peer.
546       The failover object has the following attributes (please see dhcpd.conf
547       (5) for explanations about what these attributes mean):
548
549       name data examine
550            Indicates the name of the failover peer relationship, as described
551            in the server's dhcpd.conf file.
552
553       partner-address data examine
554            Indicates the failover partner's IP address.
555
556       local-address data examine
557            Indicates the IP address that is being used by the DHCP server for
558            this failover pair.
559
560       partner-port data examine
561            Indicates the TCP port on which the failover partner is  listening
562            for failover protocol connections.
563
564       local-port data examine
565            Indicates  the  TCP port on which the DHCP server is listening for
566            failover protocol connections for this failover pair.
567
568       max-outstanding-updates integer examine
569            Indicates the number of updates that can be outstanding and  unac‐
570            knowledged at any given time, in this failover relationship.
571
572       mclt integer examine
573            Indicates  the maximum client lead time in this failover relation‐
574            ship.
575
576       load-balance-max-secs integer examine
577            Indicates the maximum value for the secs field in a client request
578            before load balancing is bypassed.
579
580       load-balance-hba data examine
581            Indicates  the  load balancing hash bucket array for this failover
582            relationship.
583
584       local-state integer examine, modify
585            Indicates the present state of the DHCP server  in  this  failover
586            relationship.  Possible values for state are:
587
588                 1   - startup
589                 2   - normal
590                 3   - communications interrupted
591                 4   - partner down
592                 5   - potential conflict
593                 6   - recover
594                 7   - paused
595                 8   - shutdown
596                 9   - recover done
597                 10  - resolution interrupted
598                 11  - conflict done
599                 254 - recover wait
600
601            (Note  that  some  of  the  above  values  have changed since DHCP
602            3.0.x.)
603
604            In general it is not a good idea to make changes  to  this  state.
605            However,  in  the  case  that  the failover partner is known to be
606            down, it can be useful to set the DHCP server's failover state  to
607            partner  down.   At this point the DHCP server will take over ser‐
608            vice of the failover partner's leases as  soon  as  possible,  and
609            will  give  out  normal  leases, not leases that are restricted by
610            MCLT.  If you do put the DHCP server into  the  partner-down  when
611            the other DHCP server is not in the partner-down state, but is not
612            reachable, IP address  assignment  conflicts  are  possible,  even
613            likely.   Once  a  server has been put into partner-down mode, its
614            failover partner must not be brought back online until  communica‐
615            tion is possible between the two servers.
616
617       partner-state integer examine
618            Indicates the present state of the failover partner.
619
620       local-stos integer examine
621            Indicates  the  time  at which the DHCP server entered its present
622            state in this failover relationship.
623
624       partner-stos integer examine
625            Indicates the time at  which  the  failover  partner  entered  its
626            present state.
627
628       hierarchy integer examine
629            Indicates  whether the DHCP server is primary (0) or secondary (1)
630            in this failover relationship.
631
632       last-packet-sent integer examine
633            Indicates the time at which the most recent  failover  packet  was
634            sent by this DHCP server to its failover partner.
635
636       last-timestamp-received integer examine
637            Indicates  the  timestamp  that  was  on the failover message most
638            recently received from the failover partner.
639
640       skew integer examine
641            Indicates the skew between the failover partner's clock  and  this
642            DHCP server's clock
643
644       max-response-delay integer examine
645            Indicates  the  time  in  seconds  after  which,  if no message is
646            received from the failover partner, the partner is assumed  to  be
647            out of communication.
648
649       cur-unacked-updates integer examine
650            Indicates  the  number  of update messages that have been received
651            from the failover partner but not yet processed.
652

FILES

654       /etc/dhcp/dhcpd.conf, /var/lib/dhcpd/dhcpd.leases,  /var/run/dhcpd.pid,
655       /var/lib/dhcpd/dhcpd.leases~.
656

SEE ALSO

658       dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)
659

AUTHOR

661       dhcpd(8)  was  originally  written  by  Ted Lemon under a contract with
662       Vixie Labs.  Funding for this project was provided by Internet  Systems
663       Consortium.   Version  3 of the DHCP server was funded by Nominum, Inc.
664       Information  about  Internet  Systems  Consortium   is   available   at
665       https://www.isc.org/.
666
667
668
669                                                                      dhcpd(8)
Impressum