Migrating subnets between failover peers

[Bob Harold]

On Sun, Jul 7, 2019 at 5:32 PM Simon Hobson <dhcp1 at thehobsons.co.uk> wrote:

> Andrew Bell <andrew at poscomp.ca> wrote:
>
> > I have a legacy server, server A, which holds all of my wired subnets
> > (around 200).  I also have a new set of servers, B and C, which hold my
> > wireless subnets and are configured for failover.
> >
> > What I would like to do is migrate all of the wired subnets from server
> A to
> > servers B&C.  I think this will work...
> >
> > Create a failover peer relationship between A&B.
> > Add all subnets from A to B.
> > Update pools on A&B to use failover.
> > Update routers to point to both A&B.
> > Wait a while (days?)
> > Add all wired subnets to C (including failover)
> > Update pools on B to use B/C failover peer
> > Change routers to point to B&C
> > Shutdown A
> >
> > Does this plan make sense?
>
> Mostly - though I am no expert on failover.
>
> Add the subnets to B with failover. When you add failover to A, it will
> then sync it's leases to B and they will enter normal state. This sync
> operation can take some time - watch the logs and/or query state (OMAPI ?).
> Now point your routers (I assume you mean relay agents) to A&B.
> You don't need to wait, the failover sync will have taken care of
> transferring leases. Waiting won't make clients switch from talking to A to
> talking to B.
>
> You can now shut down A and put B into partner down state for this
> partner. B will now handle all clients when they broadcast requests - but
> not when they unicast to renew leases. When clients first try and renew
> leases, they will unicast a request to the server that originally gave them
> the lease. When they don't get a reply, they will eventually broadcast a
> renewal request and that will reach B which (because it is in partner down
> state for peer "A") renew the lease.
> If you don't shutdown A at this point, it will still be answering unicast
> requests from clients when it shouldn't be.
>
> Now add the subnets, with failover, to C; and change failover peer on B to
> C
> Change routers (relay agents) to point to B & C.
>
> Don't forget that you can do this a network (subnet or shared network) at
> a time. In place of "shutdown", change the subnet declaration to empty
> apart from "not authoritative". An empty subnet, especially if marked as
> not authoritative, is effectively "not there" as far as servicing clients.
> If not directly connected, the subnet declaration can be missing
> altogether which achieves the same result.
>

I have done this several times (we currently have 6+ pairs of DHCP servers
in production).  I use a similar set of steps, but I prefer not to have B
be secondary at one point and primary later (our servers have other
subnets, and I don't think one DHCP server can be primary for some and
secondary for others):
- Make sure all servers are not "authoritative" during the transition.
- add dhcp forwarders for all 3 to all subnets.
- verify that you are seeing 'discover' packets at all the servers.  If
there might be different acl's/firewalls/routing on different subnets, you
can check for each subnet (might need a new test client on each subnet).
- turn down the lease time if it is long (I typically reduce it to 1 hour)
- wait for the original lease time so that clients all have the new lease
time.
- add the subnets to C and make A/C a primary/failover pair.  You might
want a shorter "mclt" time during the transition.
- Watch the "failover" messages in the logs for both to be 'normal'.  Will
take at least "mclt".
- Introduce new clients - about half of them should get leases from "C".
If "C" is sending DHCPOFFER, but all the new clients choose "A", something
is wrong.
- Remove subnets from A (or shut down A) and add them to B, with B/C as the
primary/failover pair.
- Watch the "failover" messages in the logs for both to be 'normal'.  Will
take at least "mclt".
- Introduce new clients - about half of them should get leases from "B".
If "B" is sending DHCPOFFER, but all the new clients choose "C", something
is wrong.
- Once things are working, set the lease time (and mclt, if changed) to
normal values.  Set as "authoritative" if desired (probably a good idea).

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20190711/998176a7/attachment.html>