dhcp1 at thehobsons.co.uk
Wed Oct 12 12:50:35 UTC 2016
John Ratliff <jratliff at bluemarble.net> wrote:
> It seems that the running server always sends packets from the primary IP
> on the NIC, and sets the dhcp-server-identifier option to this IP. So when
> a DHCP client tries to renew, if the server has changed, it takes quite a
> while before the client realizes this.
Thomas has already given the fix for the address used (and I always prefer a proper fix to a workaround), but without this there should be no impact whatsoever on the clients. They may take a while to find the other server, but they will not lose their current lease - if they do then you have other issues to investigate.
The default behaviour (at least for the ISC client, I think most are pretty similar) is to renew (by unicast to the server) the lease at half time. So if you use (say) 8 hours leases, the client will attempt to renew it when there's 4 hours left - at this point it will get no reply if the original server is down but that will not in any way affect client operation.
The client will continue at decreasing intervals until (by default) 7/8 of the lease is expired - so when there is still 1 hour of an 8 hours lease left. Then it will switch to broadcasting renewal requests - at which point, the other server will pick up the packet and renew the lease, and the client can then carry on as normal without any network interruption.
Any client that breaks network connections under this condition is broken.
Only if the lease completely expires should the client drop it's IP address and break any network connections that are open.
I hope that's clear.
More information about the dhcp-users