best practice for moving subnets?

[Tom Schmitt]

> Datum: Wed, 17 Nov 2010 21:29:18 +1100
> Von: Glenn Satchell <glenn.satchell at uniq.com.au>
> Betreff: Re: best practice for moving subnets?

I have now moved the first subnet (only one to see if all is working as expected)

> >> change the config for the relevant subnets on the old pair to 
> >> if option dhcp-message-type = 1 {
> >> deny booting;
> >> }
This I did as you suggested. Additional I made the dhcpd for this subnet not authorative to avoid problems.


> >> deny after 4 2010/12/28 16:00:00;
According to dhcpd -t this is not an acceptable syntax.


> >> The thing is, even if you change helper address, the clients will
> >> continue to use the old dhcp serves if there are
> >> network connectivity.
This problem I avoided by adding a next server statement to the old dhcpd pointing to the new dhcpd.




> 
> Shutdown the old servers. 
> Make a copy of the leases files off each partner (remember which is 
> primary).
I grepped all the lease-statements from the leasefile without stopping the old dhcpd. Only these I appended to the database of the new server. This way I had no downtime and much less logfiles on the new servers to check.


>  
> and remove the range statements, so that no renewals will be done. This 
> forces the clients to do a DHCPDISCOVER for a new server.
> 
This I will do as a second step after I checked which clients are left on the old server. One question for my better understanding: What do you thing is the advantage for deleting the ranges instead of deleting the complete subnet?


 
> Shut down the new servers. 
> Add the new subnets to dhcpd.conf. 
> Concatenate the corresponding leases files from the old primary onto the 
> end of the new primary. 
Did as suggested.

 
> Same for the secondary.
Before I stopped the new dhcpd, I set the primary into partner-down-mode. By that I didn't have to add anything to the leasedatabase of the second dhcpd. I only started it again and it got the updates from the primary.


> If you use dynamic DNS updates I think you'll be ok, as the TXT record 
> is a hash of the client-id, nothing to do with the server. SO even if 
> the old server removes the entry, the new server can create an identical 
> one, or will recognise that there is a valid ddns entry already.
Here is the weakest part in the procedere: When the client gets a lease from the new dhcpd, the dhcpd will try to renew the DNS-entry, but it's already there. No harm so far. But after a time the old lease given by the old dhcpd is running out of time and the old dhcpd server is deleting the DNS-entry for this lease.
Now the client has no DNS-entry at all.
When the client renews its lease the next time, the DNS-entry will be entered again and the problem will be gone. But there is a timeframe in which the client has no DNS-resolution.

Unfortunately we have some applications in use which don't react well to a missing DNS-entry.

I reduced the timeframe (and so the problem) by reducing the leasetime on the new dhcpd, but thats no real solution.

I thought a bit about the possibilities. What do you thing, would the following approach work?
+After starting up the new dhcpd I modify all dynamic leases on the old servers
+I set the end-time of the lease to a point in the past
+Now the old dhcpd will never come to the point were the lease is timimg out and so he won't try to delete the DNS entry.

Would this work? Or would the dhcpd delete the DNS-entry immediately when I modify the end-time of the lease? Or would I create problems in the internal leasedatabase of the dhcpd because now he has a lot of leases he can never get rid of?

 

-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome