Catastrophic failure and recovery

Glenn Satchell glenn.satchell at uniq.com.au
Wed Jun 27 06:34:59 UTC 2018


man dhcpd.leases

explains the format of the leases file and what all the different fields are.

regards,
-glenn

On Tue, June 26, 2018 6:18 pm, perl-list wrote:
> starts and ends are the important numbers.  Both peers are aware of when
> the lease starts and ends.
>
> tsfp atsfp and cltt all have to do with failover, I believe, tho I don't
> remember what they were for.  I think you will find that they are all
> offset by the amount of MCLT from your config file.  A search of the
> mailing list archives would probably let you find out what those are for
> as I know its been discussed on here some time in the past.
>
> ----- Original Message -----
>> From: "Greg Sloop" <gregs at sloop.net>
>> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
>> Sent: Monday, June 25, 2018 6:15:31 PM
>> Subject: Re: Catastrophic failure and recovery
>
>> Re: Catastrophic failure and recovery Ok, I do see somewhat similar
>> lease
>> information in each lease file [from each peer.]
>> [I thought each peer essentially only kept track of it's own leases,
>> with some
>> communication/coordination data.]
>
>> Yet the details in the lease records doesn't match exactly.
>
>> So, here's an example:
>
>> [This lease example is from the peer who has not issued the lease.]
>> starts 1 2018/06/25 17:13:25;
>> ends 1 2018/06/25 21:13:25;
>> tstp 6 2018/06/23 04:26:08;
>> tsfp 1 2018/06/25 23:13:25;
>> atsfp 1 2018/06/25 23:13:25;
>> cltt 3 2018/06/06 00:02:22;
>> binding state active;
>> next binding state expired;
>
>> [This lease example is from the peer who *has* issued the lease.]
>> starts 1 2018/06/25 17:13:25;
>> ends 1 2018/06/25 21:13:25;
>> tstp 1 2018/06/25 23:13:25;
>> tsfp 1 2018/06/25 23:13:25;
>> atsfp 1 2018/06/25 23:13:25;
>> cltt 1 2018/06/25 17:13:25;
>> binding state active;
>> next binding state expired;
>
>> So, lets assume the peer that did issue the lease dies and we setup a
>> "new" peer
>> with only the configuration.
>> The fail-over peer who didn't issue the lease will gather enough data,
>> from
>> simply communicating with the still active peer, that it will know that
>> it is
>> the peer responsible for this lease, and the prior lease data and simply
>> come
>> back up and rebuild the lease file properly. Correct?
>
>> [That seems reasonable, given what I see in the leases file - but just
>> wanting
>> to be sure I've not assumed something incorrectly from the response.]
>
>> A few follow-up questions:
>> --Why is: tstp 6 2018/06/23 04:26:08; in one vs tstp 1 2018/06/25
>> 23:13:25; in
>> the other?
>> [The docs I see say that this "indicates what time the peer has been
>> told the
>> lease expires." But this would seem to indicate that the two peers think
>> the
>> lease expires at different times.]
>
>> --I can't find any documentation to describe what the numbers after;
>> starts,
>> ends, tstp, tsfp, atsfp, etc. mean. [1, 6, 3, etc]
>
>> Thanks again!
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>




More information about the dhcp-users mailing list