Insert delay in dhcp3-relay ?

José Queiroz zekkerj at gmail.com
Tue May 10 21:29:27 UTC 2011


2011/5/8 Benjamin <hexor38 at gmail.com>

> Le 05/05/2011 09:05, dhcp-users-request at lists.isc.org a écrit :
>
>  You may care to look at the min-secs statement. Adding this to the
>> subnet declaration for the 'remote' subnet on each server should
>> achieve what you want.
>>
>>         The min-secs statement
>>
>>            min-secs seconds;
>>
>>            Seconds should be the minimum number of seconds since a client
>> began
>>            trying to acquire a new lease before the DHCP server will
>> respond to
>>            its  request.   The  number  of  seconds is based on what the
>> client
>>            reports, and the maximum value that the client  can  report  is
>>  255
>>            seconds.    Generally,  setting  this to one will result in the
>> DHCP
>>            server not responding to the  client's  first  request,  but
>>  always
>>            responding to its second request.
>>
>>            This  can  be  used  to  set  up a secondary DHCP server which
>> never
>>            offers an address to a client until  the  primary  server  has
>>  been
>>            given a chance to do so.   If the primary server is down, the
>> client
>>            will bind to the secondary  server,  but  otherwise  clients
>>  should
>>            always  bind  to  the primary.   Note that this does not, by
>> itself,
>>            permit a primary server and a secondary server to share  a
>>  pool  of
>>            dynamically-allocatable addresses.
>>
>> -- Simon Hobson
>>
> Hello,
> This is the function I need ! but ... I have test it, and it don't work, I
> put the min-secs in my range but the DHCP send an offer without delay
> (min-secs delay).
> Have you got an idea  why the delay don't work ? ( I have tested out of the
> range (at the start of dhcpd.conf) but it's the same result...)
>
> Thanks.
>
>
Shouldn't the clients still be bound to the secondary server when they
reboot with a valid lease? If I understood the documentation, in this case,
instead of broadcasting to find a new lease (and server), they'll unicast to
the last server...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20110510/32a21ea0/attachment.html>


More information about the dhcp-users mailing list