moving subnet to another server
ptrapp at nex-tech.com
Fri Jan 9 19:22:02 UTC 2015
I'm not going to claim to being an expert, that was just a concern that I think you will want to consider.
I think you can have both servers online at the same time as long as they are not handing out the same addresses at the same time. Or as long as the IP helpers - if that's how the servers find their DHCP server - are not making both servers available at the same time.
I'm not sure if it's possible to migrate the leases file from the old server to the new server in some fashion, so what I've done in the past is to 1) move to a new subnet on the new server so that as the clients get their addresses from the new server, they leave the old subnet. Both DHCP servers are in production at the same time, serving different address pools, so there are not conflicts, and it's just a matter of informing the clients where to go to get their addresses and letting the leases expire and be renewed (on the new server) naturally. Or 2) if we were not able to move to a new subnet for some reason, I've been fortunate enough to work with a subnet large enough to support more than twice the number of clients, so I went onto the old server and reduced the address scope by half (let's say it retains the high half) and configured the new server to serve up the other half (so it gets the lower half). From there, the idea is the same as #1 - tell the clients that they now need to get their addresses from the new server and let them move over of their own accord. Eventually, the old server is getting none of these client requests and you can increase the scope on the new server to the full desired subnet.
Reiterating that I'm no expert and both approaches may have constraints that prevent you from using them, but with a 10-minute lease time, either process could resolve itself very quickly. Why do you have such a tight lease time, by the way? Even for a test bed, that churn seems extreme. Or is that just for the transition period?
From: dhcp-users-bounces at lists.isc.org [dhcp-users-bounces at lists.isc.org] on behalf of Dana Huggard [dana.huggard at cohodata.com]
Sent: Friday, January 09, 2015 1:12 PM
To: Users of ISC DHCP
Subject: Re: moving subnet to another server
Thanks Patrick. I don't know how to handle that. Not sure how smart dhcp is to detect such a condition or how long it would take for things to sort itself out.
The default-lease-time in the subnet declaration is 600. Is there a preferred way to handle this?
On Fri, Jan 9, 2015 at 10:59 AM, Patrick Trapp <ptrapp at nex-tech.com<mailto:ptrapp at nex-tech.com>> wrote:
How are you planning to prevent the new server from handing out addresses already assigned by the old server?
From: dhcp-users-bounces at lists.isc.org<mailto:dhcp-users-bounces at lists.isc.org> [dhcp-users-bounces at lists.isc.org<mailto:dhcp-users-bounces at lists.isc.org>] on behalf of Dana Huggard [dana.huggard at cohodata.com<mailto:dana.huggard at cohodata.com>]
Sent: Friday, January 09, 2015 12:33 PM
To: dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>
Subject: moving subnet to another server
I'm planning on moving a subnet over to another server and am not sure what kind of devil hides in the details.
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).
Along with the dhcpd change the new dhcp server will also serve as a dns server for a new domain.
To implement the move I have a new dhcp server I plan to remove the subnet declaration from dhcpd.conf off the old server, add it to the new server, then restart dhcpd on the old server, and start dhcpd on the new server.
What I am wondering about is what to expect for the behaviour of the dhcp clients. How disruptive might this be?
dhcp-users mailing list
dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>
778.724.0761 ext 117
dana.huggard at cohodata.com<mailto:dana.huggard at cohodata.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users