combining lease files

project722 project722 at gmail.com
Wed Aug 29 21:07:17 UTC 2018


good to know. Ive been searching google much of the day and have yet to
find an example of having two pairing on a single secondary server. Thanks
so much!



On Wed, Aug 29, 2018 at 3:37 PM Bob Harold <rharolde at umich.edu> wrote:

>
> On Wed, Aug 29, 2018 at 10:41 AM project722 <project722 at gmail.com> wrote:
>
>> Thanks. So would this syntax be correct on the secondary?
>>
>> failover peer "dhcp-failover" {
>>         secondary; # declare this to be the secondary server
>>         address <server IP address>;
>>         port 647;
>>         peer address <A-master>;
>>         peer address <B-master>;
>>         peer port 647;
>>         max-response-delay 30;
>>         max-unacked-updates 10;
>>         load balance max seconds 5;
>> }
>>
>
> I don't configure by hand any more, we bought IPAM software, but looking
> at what it produces, I see:
> On mine the peer port is different than the other port (647 vs 847), and
> reversed on the other end.
>
> But more importantly, you need a whole separate "failover peer" section
> for each pairing, with a different name:
>
> failover peer "pairA" {
> ...
> }
>
> failover peer "pairB" {
> ...
> }
>
> Then in each pool use the correct failover peer name:
>
> subnet 10.0.30.0 netmask 255.255.255.0
> {
>     option subnet-mask 255.255.255.0;
>     option broadcast-address 10.0.30.255;
>     ddns-rev-domainname "in-addr.arpa.";
>     ddns-updates false;
>     option netbios-node-type 8;
>     option netbios-name-servers 141.211.21.102, 141.211.76.103;
>     option routers 10.0.30.1;
>     pool
>     {
>         failover peer "pairB";
>         range 10.0.30.128 10.0.30.245;
>     }
> }
>
> --
> Bob Harold
>
>
>>
>>
>> On Wed, Aug 29, 2018 at 9:35 AM Bob Harold <rharolde at umich.edu> wrote:
>>
>>>
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20180829/223d6335/attachment-0001.html>


More information about the dhcp-users mailing list