Failover concept clarification

[pat]

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/20090709/f99a5466/attachment.html>