combining lease files

[Bob Harold]

On Wed, Aug 29, 2018 at 10:14 AM project722 <project722 at gmail.com> wrote:

> Thanks for the feedback guys!
>
>
> So, in this scenario I'll have 2 masters temporarily - B will become a new
> master and sync to A-failover, and A-master will still be in the picture as
> well? If I try this approach, then, I will have to add the subnets for
> server B to A-failover, then enable failover between B and A-failover?
> Wouldn't A-master have a problem with A-failover having subnets in its conf
> file that A-master doesn't?
>
> Also, I'm starting to think aboout ip helper addresses. Seems like the
> flow would be:
>
> Add an IP helper address on the router for server B's subnets to also
> point to A-failover
> Once they are completely in sync then remove the IP helper for server B
> altogether and add another for A-master
>
> Does that sound about right?
>

That is correct.  A DHCP server can be master for some subnets with
failover 1, and others with failover 2, and still others with no failover.
A DHCP failover server can be failover for some subnets with master 3,
others with master 4, and other subnets that are not using failover.  The
only limitation is that I don't think a server can be master for some
subnets and failover for others.

p.s. Here at U of Michigan we currently have 8 pairs, and have some
experience moving subnets around  :)  The trick is to verify that the dhcp
forwarding on the routers is really working and that there is no firewall
rule or acl somewhere blocking it.

-- 
Bob Harold



> On Wed, Aug 29, 2018 at 8:36 AM Bob Harold <rharolde at umich.edu> wrote:
>
>>
>> On Wed, Aug 29, 2018 at 9:33 AM Sten Carlsen <stenc at s-carlsen.dk> wrote:
>>
>>>
>>>
>>> On 29/08/2018 14.28, project722 wrote:
>>>
>>> Hey All,
>>>
>>> We are consolidating all subnets on server B and moving to an exisitng
>>> failover pair we have, In order to decom server B. I'll need to take the
>>> leases file from server B and combine whats there with the leases file on
>>> both servers in the failover pair. (doing this to make the failover pair
>>> aware of what leases are already out there that were assigned by server B)
>>>
>>> I am not sure, but I think one other way could be to make server B part
>>> of a failover pair with one of the existing failover servers for a period
>>> of time. That way the remaining server will have all the information
>>> transferred from server B. Later that configuration could be changed to
>>> have the other remaining failover server act as the peer, that way the
>>> servers would transfer the data, probably with less risk.
>>>
>>> Others should confirm or reject this idea.
>>>
>>>
>>> I'm thinking just a simple cat on both files should be fine to combine
>>> the data. And, all 3 servers are running the same verison of dhcp
>>> (4.1.1.61) and RHEL so I don't expect and formatting problems.
>>>
>>> However, since failover pairs have more transitional states with the
>>> "binding state" variable, is it possible I will run into any issues doing
>>> this? Is there a better, more preferred way of doing this instead of
>>> merging the leases file?
>>>
>>>
>> The benefit of a failover pair is that we can upgrade/repair/replace one
>> server at a time without any interruption in service.
>> Let's call the failover pair A-master and A-failover.
>> The recommended method is to configure server B as master and the
>> A-failover server as failover for server B's subnets also.  Give it some
>> time (watch the failover messages in the logs) to sync the data from B to
>> A-failover.  Then move the subnets from B to A-master, and A-master will
>> sync the data from A-failover.
>>
>> --
>> Bob Harold
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20180829/d12c68a5/attachment.html>