dhcp server IP pool monitoring
jw354 at cornell.edu
Fri Mar 14 19:27:31 UTC 2014
If you refer to the delay-commit function, it is
the responses to the client that are delayed so
that committing disk writes can be batched,
so the disk is still up to date by the
time the client gets the lease info,
i.e., according to the spec.
There wouldn't be any few-second delay.
I trust Linux a bit less though:
interactively, I've closed a file with vi, then
ran a program that appeared to miss the change.
Would vi(m) manage to exit without any synch
happening? (I've never noticed anything
equivalent with dhcpd lease file handling.)
We do parse the lease file and compare with
an external description of our pools to monitor.
The "pool-label" idea is very interesting, but
not enough for me to re-implement right now.
A "check-leasefile" program that could efficiently
output current leases in trivial-to-parse format
would be a neat addition to the isc dhcp bundle.
If it could read the config and do all the pool
assembly/monitoring work, that would be neat
Cornell University IT
On Mar 13, 2014, at 5:54 AM, Simon Hobson wrote:
> "Capriccio, Peter" <peter.capriccio at hp.com> wrote:
>> All of the solutions that parse the lease file can never be 100%
>> accurate because the real "stuff" is taking place in memory, is it
> No, for any RFC compliant package, the leases file (or equivalent)
> on disk will accurately reflect any leases before they are offered
> to the client. This is certainly the case with the ISC DHCP server -
> all lease information is written to the leases file and synced to
> disk before the lease is offered to the client*
> Worst case is that the lease file lags in-memory information by a
> few seconds.
> * Though I believe the current version has a config option to delay
> this a little for performance ?
> dhcp-users mailing list
> dhcp-users at lists.isc.org
More information about the dhcp-users