moving subnet to another server

[Simon Hobson]

Dana Huggard <dana.huggard at cohodata.com> wrote:

> The subnet is 10.x.x.0/18 and it is very busy. Its a subnet devoted to a test harness of servers that go up and down a lot putting a big load on dhcpd and named (using ddns).

That last bit is the tricky one.
I think that if you just delete the subnet from one server and add it to the other then you'll find yourself with "stale"DNS entries that you'll have to remove manually.

As Patrick suggests, one way is to add the subnet to the new server while leaving it on the old server. You can slowly reduce the size of the pool available on the old server, allow time for any leases to expire, then add the addresses into the range on the new server. As the leases expire on the old server, it will delete the DNS entries, and the new server will be able to add them in again.

If you can manage some downtime, then progressively shorten the lease time for the subnet to be moved. Say you currently have it set to 2 weeks, 2 weeks before switch you need to reduce it to no more than (say) 1 week. Keep going do that by some point in time there cannot be any leases extended more than a short period (say 1/2 hour) into the future.
You can now add "deny booting" to the range on the old server. It will refuse to renew leases and they will expire - with DNS entries being removed. Once they've all expired, add the subnet to the new server and the clients will get new leases, with the DNS being correctly updated.


Other approaches that come to mind include :

Add the new server as a failover partner. It'll sync the leases (and I think the DDNS information), and then you can remove the old server.

Kill the subnet on the old server, manually edit the DNS to remove all the DDNS entries, add the subnet to the new server. As above, if you progressively reduce the lease time beforehand, you can avoid the problems of the new server offering addresses that are already in use.