option dhcp-server-identifier

[John Ratliff]

<quote who="Simon Hobson">
> 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.

Thanks to the both of you. Yes, the configuration directive is working.
And yes, we didn't think it should actually be a problem, but you see a
lot of broken DHCP clients working for an ISP, so I prefer to guard
against them as much as possible.

--John