statistics in a dhcp failover pair

David W. Hankins dhankins at isc.org
Fri Jul 24 16:35:53 UTC 2009


On Thu, Jul 23, 2009 at 09:05:25PM +0100, Daniel Duarte wrote:
> > Also expired.  There isn't a reserved state, it's a flag on the
> > lease which may be in any other state, but I can see how it could
> > influence statistics...
> 
> Aren't the expired leases in state "expired" on the lease file? If
> not, what is this state used for?

Expired/released/reset are 'transitional states'.  The lease enters
the state and basically "becomes invisible" for all practical purposes
(it can't be reallocated or renewed) until it is either acknowledged
or declined by the failover peer.

On an ack, all these transitional states send the lease to the 'free'
state, after which MAC/client-id affinity can select to send the lease
to backup state more or less immediately.  NAK's have no effect, but
when we get one of those, presumably the peer has already (or is about
to) send us a binding update indicating its non-transitional state.

> I'm thinking that when I parse each lease, I could validate the "end"
> time, and if it is greater than the present time then I would count it
> as expired instead of counting it for its' displayed state. Any
> thoughts?

You might get some odd results when the failover relationship is not
normal; the peer can extend an active lease while the local system
believes it is expired.  This is a normal condition, so by just
looking at the ends time you might get a strange picture of actual
lease availability.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090724/47efa169/attachment.bin>


More information about the dhcp-users mailing list