Migrating subnets between failover peers

[Andrew Bell]

Hello all;

This is my scenario.

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?

Andrew





--
Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Andrew Bell <[hidden email]> 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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bob Harold]

On Sun, Jul 7, 2019 at 5:32 PM Simon Hobson <[hidden email]> wrote:

Andrew Bell <[hidden email]> 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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Bob Harold <[hidden email]> wrote:

> Set as "authoritative" if desired (probably a good idea).

It's far more than "a good idea" - unless you have a good reason to leave it off, then you should always have your server(s) set as authoritative. I have first hand experience of what can happen if a server is not authoritative with certain clients.
Specifically, Microsoft chose to deal with stability by having the clients be very "clingy" to their address rather than doing it in the server. As a result, if you move a Windows client to a different network then it will persist on trying to use it's lease until expiry - while other clients seem to be better at noticing that the network has changed. If the DHCP server is authoritative, then it will Nack requests from the client and thus force it to ask for a new lease and largely avoid this issue - if it's not authoritative then you are far more in the hands of client behaviour.

Worse than a client trying to use an address from a different subnet (and thus stopping that client from working), would be a client trying to use an address from the same subnet (ie RFC1918 address) but from a different network - and thus causing an address collision that could take out more than just the one client.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bob Harold]

Thanks for clarifying!

On Fri, Jul 12, 2019 at 3:05 PM Simon Hobson <[hidden email]> wrote:

Bob Harold <[hidden email]> wrote:

> Set as "authoritative" if desired (probably a good idea).

It's far more than "a good idea" - unless you have a good reason to leave it off, then you should always have your server(s) set as authoritative. I have first hand experience of what can happen if a server is not authoritative with certain clients.
Specifically, Microsoft chose to deal with stability by having the clients be very "clingy" to their address rather than doing it in the server. As a result, if you move a Windows client to a different network then it will persist on trying to use it's lease until expiry - while other clients seem to be better at noticing that the network has changed. If the DHCP server is authoritative, then it will Nack requests from the client and thus force it to ask for a new lease and largely avoid this issue - if it's not authoritative then you are far more in the hands of client behaviour.

Worse than a client trying to use an address from a different subnet (and thus stopping that client from working), would be a client trying to use an address from the same subnet (ie RFC1918 address) but from a different network - and thus causing an address collision that could take out more than just the one client.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Andrew Bell]

Thank you all for the responses. Everything went swimmingly and I'm all
migrated now.



--
Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users