Question about leases

[Darren]

David,
Further information.  On the router in question, it appears that it is 
incrementing the secs field rather rapidly (or so an ethereal capture 
suggests).  The value seems to be increasing as if it is usecs instead 
of just secs (as RFC 2131 states it should be).  We saw values like 
11200 to  15689 in a one second time period.

If I set this:

load balance max seconds 30;

to:

load balance max seconds 0;

will that cause the DHCP server to ignore that setting and ignore the 
secs field?


David W. Hankins wrote:

>On Mon, Apr 17, 2006 at 09:46:47AM -0400, Darren wrote:
>  
>
>>We have v.3.0.3 of ISC DHCP in a failover setup. 
>>    
>>
>
>Are you sure one of them isn't running 3.0.2?
>
>			Changes since 3.0.2
>
>- A bug was repaired where failover servers would let stale client identifiers
>  persist on leases that were reallocated to new clients not sending an id.
>
>  
>
>>Between the two servers, all fields match, save the following:
>>
>>     primary                            secondary
>>  tstp 5 2006/04/14 19:34:55;    tstp 3 2006/04/12 21:49:54;
>>    
>>
>
>TSTP is Time Sent To Peer.  These are likely to mismatch.  It's set
>depending on the server's state at that given moment.  It's not set
>when an update is received from a peer and acked (it's rather useless
>to set it, and the mismatches here help us 'breadcrumb' multiple lease
>db entries into a picture of what happened).
>
>  
>
>>  client-hostname "DI-614+";  
>>    
>>
>
>I can't remember if this is synced via the failover channel.  I
>suspect it isn't.  It has (happily) been a few months since I
>have last delved into server/failover.c.  I know it's possible to
>sync this via failover, I just don't think we do that today.
>
>So I don't think that's a bug.
>
>  
>
>>                                 uid "\001\000\024l\227\001\243";
>>    
>>
>
>That's a bug I thought we fixed in 3.0.3.
>
>  
>
>>Any idea why this would be?  A relay agent forwards the discover 
>>messages to the two servers, so they should be exactly the same, should 
>>they not? 
>>    
>>
>
>The output depends on the input.  What information each server was
>acting upon at the time they made the change (which may be different
>if the other server is sending failover protocol binding updates in
>between messages).
>
>The uid thing is a clear bug however.  It's curious that it is
>persisting on your secondary.  When the primary sends a binding
>update to indicate the new ownership of the lease, it should be
>moved to active state, and the uid stripped.
>
>And the secondary certainly should not be NAKing a REQUEST for this
>lease as it is in the free state (it just can't serve that request
>with an ACK since it can only touch active and backup leases).  It
>should only NAK requests for active leases that have a uid binding.
>
>That's how the bug manifested in 3.0.2 and prior.
>
>  
>