Catastrophic failure and recovery
Gregory Sloop
gregs at sloop.net
Mon Jun 25 17:29:59 UTC 2018
So, in the case I'm interested in here, I've got a pair of peers [failover].
[ISC/We really should pick a different name than failover, because it's essentially load-balancing with redundancy, but I digress :) ]
Now while I'm using two peers, I think the question I'm asking about will be the same regardless of peers or a single server...
So, lets assume the DHCP server [or a peer] dies. Assume we lost a disk.
Assume I've got configs, but no leases file.
What's the best recovery method?
---
I assume we'll simply put the configurations back on a "new" server. [or peer]
Turn it on and bring it up. [In the peer setup, let it communicate with the other peer.]
Since it won't have a record of any leases [that the dead-peer/old-server actually leased] we'll have a bit of a mess.
But, we'd hope that most machines would already have a lease, and would ask for renewal of that lease.
The server, I think, would generally grant that lease renewal on the same IP. [Even though it has no record of it initially.]
"New" machines just powered up, may/will ask for new addresses, and may "steal" a lease from an active client. ...BUT...
However, if the DHCP server can [and is set to use ping-check] AND the station isn't firewalled or otherwise prevented from receiving/responding to the ping-check, then the DHCP server will realize there's an active client using the address and will avoid leasing that address.
If the active lease is on a machine that's off and returns to the network [before the end of the lease] I'm not sure of the result. I *think* it will attempt to confirm the lease when it comes back on, will get a NAK and be forced to get a new lease.
Thus, generally, using best practices, the result of a catastrophic loss of a DHCP server shouldn't be too disruptive.
[Provided it can be replaced fairly quickly before too many machines lose their current lease.]
The above setup will be a lot cleaner if there's not much/any IP address churn - in that, for a particular pool, there's enough addresses to give every machine an address simultaneously. If there's a lot of churn it will be substantially more messy, but machines will see far less stability in IP address assignment [But there wasn't a lot of stability to start with, so we've probably only increased the churn rate some.]
Does that sound about right?
I'm sure there's use cases I'm not considering because I don't have those configurations - but am I missing anything serious?
---
On a side note - is it worth capturing [backing up] the leases file, say at a rate of 0.5 times the lease length? [The idea would be to have a reasonably current leases file that might be 80%+ right. Or is this likely to cause more problems than no leases file at all.]
Pointers to FAQ/Docs etc gladly accepted!
TIA
-Greg.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20180625/69f3cce7/attachment.html>
More information about the dhcp-users
mailing list