Catastrophic failure and recovery

perl-list perl-list at network1.net
Tue Jun 26 08:18:04 UTC 2018


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!


More information about the dhcp-users mailing list