dhcpd.leases question

[Glenn Satchell]

> On 06/05/2012 10:28 AM, Glenn Satchell wrote:
>> On 06/05/12 23:10, Glenn Satchell wrote:
>>> On 06/05/12 22:26, Nicolás Valera wrote:
>>>> Hi, sorry about my ignorance but, what does it means "rewind binding
>>>> state free;" in dhcpd.leses file?
>>>> Thanks in advance!
>>>> Nix.
>>>
>>> Hi Nicolás
>>>
>>> The dhcpd.leases man age describes the format of the leases file.
>>>
>>> binding state state; next binding state state;
>>>
>>> The binding state statement declares the lease's binding
>>> state. When the DHCP server is not configured to use the
>>> failover protocol, a lease's binding state will be either
>>> active or free. The failover protocol adds some additional
>>> transitional states, as well as the backup state, which
>>> indicates that the lease is available for allocation by the
>>> failover secondary.
>>>
>>> A binding state of "active" means there is a client using this
>>> particular lease now.
>>>
>>> A state of "free" means there is no client using this lease at the
>>> moment and it is available to be given out by the server.
>>>
>>
>> Sorry about that - it would be helpful if I read the question a bit
>> more closely!
>>
>> Rewind binding state is used in failover. If the two servers go into
>> communications-interrupted mode where they lose contact with each
>> other, normally a particular server can only hand out new leases from
>> it's share of the free pool. The idea is to allow it to reset the
>> binding state of a lease so that it can re-issue the IP address. This
>> is a fairly complex optimisation of the failover conditions which
>> would not occur in normal operation and only rarely if failover
>> situations, so it is something you shouldn't worry about too much.
>>
> Thanks for the answer!
> but i'm not using the failover option, why my leases file contains that?
>
> Thanks again and sorry about my English!

This is a comment from the source code in server/failover.c

         * In failover rules, a server is permitted to work forward in
certain
         * directions from a given lease's state; active leases may be
         * extended, so forth.  There is an 'optimization' in the failover
         * draft that permits a server to 'rewind' any work they have not
         * informed the peer.  Since we can't know if the peer received our
         * update but was unable to acknowledge it, we make this change on
         * transmit rather than upon receiving the acknowledgement.

rewind_lease_state is mentioned in a few other source files. It seems to
be default behaviour to include it in the leases file, even when failover
is not configured.

regards,
-glenn