Question about leases

[David W. Hankins]

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.

-- 
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