Seeking advice on migratrating leases from 1.0.2 server to 3.0.3 servers

Simon Hobson dhcp1 at
Tue Dec 2 07:46:43 UTC 2008

Shannon Cooper wrote:

>We are looking to decommission an old failing server that has dhcpd 1.0.2
>installed, and replace it with two newer servers, pre-built with 3.0.3.
>This old server services several large subnets, with large numbers of static
>assignments and leases (close to 4,000).  Our desire is to split the subnets
>across the two newer servers, whilst retaining all current assignments and
>One smaller subnet was migrated to one of the newer servers earlier this
>year, however, it was done one PC at a time.  This was labour intensive.  We
>do not believe that migrating the remaining leases in this fashion is
>plausible, simply due to the numbers.  It has been discussed within our
>group that copying leases data from the old server to the new servers will
>be enough to retain all leases.  This was tested in an isolated lab-like
>environment using one PC.  It worked, but due to the scale of the test, it
>is unclear if this a reliable method.
>So, my question is: Can we simply copy leases data from the older server to
>the newer servers, and retain all current leases?

I was under the impression that the leases file format has changed at 
least once - but if the new server will read the old leases file 
without complaint then perhaps it's not changed too much.

For your statically defined hosts, you can simply copy the host 
definitions over and all will be fine. For the rest there are several 
strategies you could use (plus the one you've already tried).

1) The big bang. Simply turn off the old server and turn on the new 
one(s). You may get a few abandoned leases, but in most cases (at 
least with Windows) the client will come up and ask to renew it's 
existing lease - the server will oblige as long as it hasn't given it 
to anyone else. Where the client doesn't ask for an existing address, 
or where the address has been given out to another client, then a new 
address will be allocated.

2) An alternative is to shuffle clients over in a dribble - run both 
servers on a subnet with non-overlapping pools. Keep reducing the 
size of the pool on the old server, allow the leases to expire, and 
then add this address space to the new server (it helps to reduce the 
lease time in advance). As the old server won't have enough 
addresses, clients will end up taking a new address from the new 
server, and when this process is complete then you can turn off the 
old server.

In both cases, there is a small chance that a client will change 
address during the working day. If this happens then all IP 
connections will be broken.

You mention running TWO new servers. Are these a failover pair ? If 
so then I have two comments :
1) I would do the migration without failover - there's less to debug 
if a problem occurs. Once the migration is complete, then add the 
failover (I would test it on one subnet first !). You can run 
failover on just selected subnets.
2) 3.0.3 is ancients, and this is especially important with failover. 
Watching this list, it's clear that there have been many major 
changes, improvements, and serious bug fixes in failover since that 
was current - you would be well advised to run 3.1.
Simon Hobson

Visit for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

More information about the dhcp-users mailing list