Update procedure

[Glenn Satchell]

>From: David Coulthart <davec at columbia.edu>
>To: Users of ISC DHCP <dhcp-users at lists.isc.org>
>Subject: Re: Update procedure
>Date: Fri, 27 Mar 2009 08:54:54 -0400
>
>On Mar 26, 2009, at 5:33 PM, David W. Hankins wrote:
>> On Thu, Mar 26, 2009 at 04:18:36PM -0400, David Coulthart wrote:
>>> What would the update procedure look like if you need to do an  
>>> upgrade from
>>> 3.0.x to 4.1.x?  If I upgrade one server to 4.1.x without taking  
>>> down the
>>> second one still running 3.0.x (so I don't cause an outage for my  
>>> users)
>>> will dhcpd recognize that they're trying to speak incompatible  
>>> versions of
>>> the failover protocol and just refuse to talk to one another?  Or  
>>> could
>>> this result in some form of lease file corruption so I have to take  
>>> both
>>> servers down before bringing them up on 4.1.x (causing a brief  
>>> outage for
>>> users)?
>>
>> There's no risk to the lease database.  Older versions would log very
>> odd looking errors, newer versions more gently explain the problem.
>>
>> I usually recommend faulting the lease database with the 3.0->3.1+
>> upgrade (because a lot of bugs throughout development would cause
>> lease database inconsistency) "just to be sure," but that's up to you.
>
>Based on this message:
>
>https://lists.isc.org/pipermail/dhcp-users/2008-September/007051.html
>
>faulting the lease database seems to mean moving the existing  
>dhcpd.leases file out of the way and allowing it to re-sync using the  
>failover protocol.
>
>Are you suggesting the same thing as you did in that message -- to  
>fault just the secondary's database?  So the procedure to upgrade  
>would look something like:
>
>1) Stop old dhcpd on primary (secondary continues answering users)
>2) Start new dhcpd on primary w/existing dhcpd.leases (no failover  
>sync will take place b/c of protocol mismatch)
>3) Stop old dhcpd on secondary
>4) Move dhcpd.leases on secondary out of the way
>5) Start up new dhcpd on secondary w/empty dhcpd.leases (relying on  
>failover to sync w/primary)
>
>If this is what you are suggesting, won't that mean that any leases  
>given out by the secondary b/w steps 1 & 3 are lost?  If planned  
>properly the time b/w steps 1 & 3 should be minimal, but I just want  
>to make sure I'm understanding the full picture.
>
>Thanks,
>Dave Coulthart

You're right, so you probably want to stop it on the secondary first,
then stop the primary and go from there. Remember it's only clients
that are doing DHCPDISCOVER that will be impacted, any client renewing
will just keep on retrying.

regards,
-glenn