failover, partner-down state, MCLT and rewind binding
gregs at sloop.net
Tue Nov 10 15:50:05 UTC 2015
SH> Gregory Sloop <gregs at sloop.net> wrote:
>> Fairly quickly, got the secondary back up.
>> It handled all it's assigned leases fine, as far as I can tell. It then handed out all the remaining pool leases it had. Then it ran out of leases.
>> I expected it to start recovering the leases from the peer [primary] at this point, and extend [rewind] the leases the primary had already issued.
>> While I'm not sure how the "rewind" provision worked - we were getting "peer holds all free leases" messages for quite a while.
>> I didn't think this should be happening - but then I looked at the MCLT time and it was set to 1800 [30m]
SH> It is not clear, did you set that server into "partner down" mode ?
I did set the "still up" server in partner-down mode. I verified it was in partner down mode via the OMAPI tool too.
But given what I read in the docs, about MCLT, I think it was operating normally - at least as far as the free address pool, and reclaiming addresses from the "down" server. [i.e. It still has to wait the MCLT time before reclaiming them. Since my MCLT time was as long as my lease time, leases were expiring and the clients unable to get another address for 30m+ because the partner-down server couldn't reclaim the split pool for 30 minutes after going into partner down mode. (And we didn't get the secondary server up and into partner down mode until after most all of the active leases had actually expired. And yes, it is probably an indication that a longer DHCP lease time would be helpful, in addition to shortening the MCLT.)]
I still need/want more information about how the rewind process works, if anyone has it.
[Is there a way, in the log files, to determine if and/or what clients got a "rewind" lease extension? I don't have a copy of the leases file at the time of the problem, so I can't look there for any data. So, I'm hoping there's evidence of "rewind" activity in the log files, which I can retrospectively review.]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users