Failover concept clarification

[pat]

Well i think i found what the problem is

it's the version i was using am i right Mr. David ?

Regards
Pat

On Thu, Jul 9, 2009 at 11:58 PM, pat <patkumar82 at gmail.com> wrote:

> Hi David.
>
> I tested the below scenario with 3.0.5 version
>
> Pool range of 192.168.10.10 to 192.168.10.50 as soon as i enabled the
> failover with split 255 and started the dhcpd service, in the syslog
> messages the state of the servers turned to normal with "free=21 and backup
> =20"
>
>  Meanwhile in the primary & secondary lease file was updated with the ip
> address from 192.168.10.31 to 192.168.10.50 with binding state as backup.
>
> *Question :* should both the servers be updated with free state as well
> isn't it ? why it is not happening ?
>
>    I then simulated the 31 clients to send a discover, and as expected all
> offer were given by primary and acknowledged , at this point the syslog was
> reading "free=4 and backup=5 "
>   i tried to check the ipaddress in free state and backup which where not
> allocated so far and those are.
>
> *free:*
> 192.168.10.10, 192.168.10.12, 192.168.10.37, 192.168.10.38
>
> *Backup:*
> 192.168.10.32,192.168.10.33,192.168.10.34,192.168.10.35,192.168.10.36
>
> Now at this state i stopped the service in primary and made my state
> partner-down in the secondary. (at this time STOS for secondary was
> 08:09:30, configured mclt was 100)
>
> again i simulated 40 clients after 8Hr:11min:10sec (STOS +MCLT) what i
> observed is the secondary offered only 36 clients discover and discarding
> the rest.
>
> when i checked what all ip's was not offered and it was all the IP i
> mentioned in free: 192.168.10.10, 192.168.10.12, 192.168.10.37,
> 192.168.10.38
>
> *Question:*
> why the lease in "free=4" state are not allocated by secondary even after
> STOS+MCLT expired. should it allocate or not ?
> Secondary renewed the lease that are already allocated by primary, it's
> confusing if it can renew the primary allocated lease why not the ip address
> from free state to new clients ?
>
> Can you please let me know is this the expected behavior from the failover
> scenario?
>
> Regards
> Pat
>
>
> On Wed, Jul 8, 2009 at 1:20 AM, Nicholas F Miller <
> Nicholas.Miller at colorado.edu> wrote:
>
>> I have a question about failover behavior. If one of the DHCP servers goes
>> offline does the server that is still up handle the existing leases for the
>> down server? I know the server that is still up cannot offer leases from the
>> downed server's free leases pool. But when a client, with an existing lease
>> from the down server, asks to renew the lease will the server that is still
>> up handle the renewal?
>> _________________________________________________________
>> Nicholas Miller, ITS, University of Colorado at Boulder
>>
>>
>>
>>
>> On Jul 7, 2009, at 12:04 PM, David W. Hankins wrote:
>>
>>   On Tue, Jul 07, 2009 at 04:49:54PM +0530, pat wrote:
>>>
>>>> What will be the time to expire before my secondary responds to all the
>>>> clients request?
>>>>
>>>
>>> Load balancing is only engaged in 'normal' state.  In all other
>>> operating states, the server will always answer as best it can.
>>>
>>> is it 00hr:09min:41sec + 1800 sec = 00hr:39min:41sec so my secondary
>>>> server
>>>> will wait for 39min and 41 sec before answering all my clients request.
>>>>
>>>> how do i calculate the STOS+MCLT time.
>>>>
>>>
>>> You got this right.  This time effectively determines when the
>>> partner's free lease pool will be available for allocation to new
>>> clients, although this is actually a case-by-case basis on each
>>> individual lease.  The actual time is TSFP+MCLT or STOS+MCLT,
>>> whichever is further in the future.  Generally free leases have a
>>> TSFP that is in the past, so STOS+MCLT is the effective measure.
>>>
>>> However, expired leases, or leases reaching expiry, may have a
>>> TSFP that is still in the future (the TSFP lags ahead of lease
>>> expiration so that leases may be extended to lease-times greater
>>> than MCLT).
>>>
>>> STOS+MCLT doesn't affect LBA.
>>>
>>> --
>>> David W. Hankins        "If you don't do it right the first time,
>>> Software Engineer                    you'll just have to do it again."
>>> Internet Systems Consortium, Inc.               -- Jack T. Hankins
>>> _______________________________________________
>>> dhcp-users mailing list
>>> dhcp-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090710/fe841c94/attachment.html>