<div dir="ltr">Thanks. So would this syntax be correct on the secondary?<br><br>failover peer "dhcp-failover" {<br>        secondary; # declare this to be the secondary server<br>        address <server IP address>;<br>        port 647;<br>        peer address <A-master>;<br>        peer address <B-master>;<br>        peer port 647;<br>        max-response-delay 30;<br>        max-unacked-updates 10;<br>        load balance max seconds 5;<br>}<br><br><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 9:35 AM Bob Harold <<a href="mailto:rharolde@umich.edu">rharolde@umich.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div dir="ltr" class="m_-7465720298562550308gmail_signature" data-smartmail="gmail_signature"><br></div></div><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 10:14 AM project722 <<a href="mailto:project722@gmail.com" target="_blank">project722@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks for the feedback guys!<br><br><br></div><div>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? <br><br></div><div>Also, I'm starting to think aboout ip helper addresses. Seems like the flow would be:<br><br></div><div>Add an IP helper address on the router for server B's subnets to also point to A-failover<br></div><div>Once they are completely in sync then remove the IP helper for server B altogether and add another for A-master<br><br></div><div>Does that sound about right?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-- </div><div>Bob Harold</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 8:36 AM Bob Harold <<a href="mailto:rharolde@umich.edu" target="_blank">rharolde@umich.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 9:33 AM Sten Carlsen <<a href="mailto:stenc@s-carlsen.dk" target="_blank">stenc@s-carlsen.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFCC">
    <br>
    <br>
    <div class="m_-7465720298562550308m_7606099521293897175m_3709826948411586589m_-3438562484079552256moz-cite-prefix">On 29/08/2018 14.28, project722 wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>
          <div>Hey All, <br>
            <br>
          </div>
          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)<br>
        </div>
      </div>
    </blockquote>
    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.<br>
    <br>
    Others should confirm or reject this idea.<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
          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. <br>
          <br>
        </div>
        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? </div></blockquote></div></blockquote><div><br></div><div>The benefit of a failover pair is that we can upgrade/repair/replace one server at a time without any interruption in service. </div><div>Let's call the failover pair A-master and A-failover. </div><div>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.</div><div><br></div><div>-- </div><div>Bob Harold</div><div> </div></div></div>
_______________________________________________<br>
dhcp-users mailing list<br>
<a href="mailto:dhcp-users@lists.isc.org" target="_blank">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
</blockquote></div>
_______________________________________________<br>
dhcp-users mailing list<br>
<a href="mailto:dhcp-users@lists.isc.org" target="_blank">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
</blockquote></div></div>
_______________________________________________<br>
dhcp-users mailing list<br>
<a href="mailto:dhcp-users@lists.isc.org" target="_blank">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
</blockquote></div>