DHCP restart with bulk lease data

[Surya Teja]

Hi Simon Thanks for reply,
 Periodically, default is every hour, the server will write out a fresh
leases file from it's internal structures  --->
I have a doubt when the server write out a fresh leases file from it's
internal structures will the dhcpd service be in off state at this duration?

this file will contain no duplicate entries --->
Hi I have seen the duplicate entry in my server lease file
 sample  snippet:
==============
lease *192.168.2.52* {

*  starts 5 2019/09/27 07:21:32;  ends 5 2019/09/27 08:21:32;*
  tstp 5 2019/09/27 08:51:32;
  tsfp 5 2019/09/27 08:21:32;
  cltt 5 2019/09/27 07:21:32;
 * binding state active;*
  next binding state expired;
  hardware ethernet 70:bb:e9:37:d9:9e;
  uid "\001p\273\3517\331\236";
  set vendor-class-identifier = "android-dhcp-9";
  client-hostname "RedmiNote6Pro";
}
lease *192.168.2.52* {

* starts 5 2019/09/27 07:21:32;  ends 5 2019/09/27 08:21:32;*
  tstp 5 2019/09/27 08:51:32;
  tsfp 5 2019/09/27 08:51:32;
  atsfp 5 2019/09/27 08:51:32;
  cltt 5 2019/09/27 07:21:32;
  *binding state active;*
  next binding state expired;
  hardware ethernet 70:bb:e9:37:d9:9e;
  uid "\001p\273\3517\331\236";
  set vendor-class-identifier = "android-dhcp-9";
  client-hostname "RedmiNote6Pro";
}
Yes It has same data, I don't see any issue on client side  but want to
make sure that, Is this acceptable in lease file ?
or do we need to add any parameter in the config to avoid such duplicates
in lease file?

Thanks in Advance.




On Thu, Sep 26, 2019 at 10:35 PM Simon Hobson <dhcp1 at thehobsons.co.uk>
wrote:

> Surya Teja <suryateja042 at gmail.com> wrote:
>
> > I have an issue with dhcpd service restart when it handles a bulk lease
> data. As part of testing I have simulated the dhcp server to lease test
> using dhcperf tool to check the performance statistics when the dhcpserver
> handles a huge lease data Ex :300689(3M). It is taking 3 to 4 minutes of
> duration to start up the service, Is this the expected behaviour when we
> have a such large lease file ? (FYI: No memory, disk space problem on the
> system)
> >
> >  When I restarted dhcpd in the log message I have a seen statement like
> >  Wrote 300689 leases to leases file.
> > Does the restart dhcpd will rewrite the lease file again?
> > I also observed  as new lease file with extension ~ at end like after
> restart dhcpd
> > I see two lease file one with dhcpd.leases and other dhcpd.leases~
> >  If it is not expected behaviour can anyone have any reference tool or
> steps to check what is taking time to bring the service up
>
> It is a known issue that the server can take some time to start up when
> there is a large number of potential addresses in the defined pools. The
> reason for this being the way the server builds hashing tables internally.
> It is probably to be expected as well in the situation you've described -
> it must read the leases file and process each lease in turn, updating the
> internal structures as it goes.
>
> The leases file is a log file database - nothing is ever changed, only new
> entries added at the end. Obviously, such a file would grow without bounds
> over time without some sort of cleanup routine. Periodically, default is
> every hour, the server will write out a fresh leases file from it's
> internal structures - this file will contain no duplicate entries. It
> writes this to a new file, moves the existing lease file to a backup name
> (the one with "~" on the end), and moves the new file into place as the
> active leases file. The leases file is ONLY read at server startup and
> never after that - everything is done from in memory structures. In between
> cleanups as detailed above, every time anything changes, a new record is
> appended to the on-disk leases file.
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20190927/b18dcad5/attachment.html>