SV: DISCOVER bursts

[David W. Hankins]

Has the OP mentioned what version they're running?  I just saw
Solaris OS details.  I don't think this was a bug fixed in any
particular version, I'm just curious.


On Tue, Jan 09, 2007 at 10:43:35PM +1100, Glenn Satchell wrote:
> Once it has committed the 2 minute lease, that address is in a sort-of
> pending state waiting for a request and can't be re-used?

The lease is left free or backup or whatever state it was in, only
the expiration time is moved so that the lease is sorted later on
the list of available leases.

The uid and hardware address are also updated so later DISCOVERs should
find the same lease.

It stays on the available list, just further down the chain.  This
is a weak assurance that the lease will not be allocated by the time
the client produces a REQUEST - indeed it might be allocated by another
client that requests that lease explicitly, or if there's a race on the
available leases.  If you're down to your last lease, the server will
offer it to every client until one requests it, after which it will
NAK additional requests.


There are two main functions at work here;

	find_lease()
	allocate_lease()

find_lease() looks around for a lease the client 'should have'.  If
there's an active binding for the client, awesome.  If there's a free
lease the server is allowed to reallocate (failover considerations)
which bears the client's mark already (a previous, expired, binding),
also great.  It does this by using lookups into the lease database
by client identifier and hardware address, and then looping through
the resulting chain of results until a lease that is available and
matches the client's shared network is found.

allocate_lease() pulls the next lease off the top of the free list.
Well, it's a little more complicated than that, abandoned leases and
choosing the best lease out of multiple pools on a shared network,
but that's the gist.  The top of the free list is the oldest lease,
so the complication is just in comparing multiple tops of lists.

When the lease is offered, the lease's timestamp is set forward two
minutes.  The timestamp is used to sort the lease into the list it
is a member of (there is a list for each lease state).

This puts that lease on the end of the free list when it's returned
to the database, hence allocate_lease() won't find it if there are
any other free leases.

I believe (this is even further down in the murky depths of
"supersede_lease()", the guts of the in-memory database) another
result is also that any hash table chains the lease is in - by
hardware address or by client identifier for example - are
removed and re-inserted.

The leases are re-inserted, but always at the tail end of the
chain.

Meanwhile, find_lease() will happily stop at the top of the chain
of leases to give out.


So there are roughly two possibilities.

find_lease() fails to find a lease (NULL), so allocate_lease()
iterates the next free one out to the OFFER.  I'm not sure how
this would be possible.  I can't explain how this might happen
at any rate (unless the client supplies a different requested
address on every discover).  If you can reproduce this however,
I'd love to hear about it.

The alternative is that find_lease() is working just fine, but
that there are multiple leases bearing this client's mark in
the database.  You'd need some kind of odd churn for the client
to get multiple leases such as this, but it's possible for
example with icmp ping-check, or with failover servers (where
a lease expires and is not allocable by the LBA server, so the
client will get two 'marked' leases over time, possibly more).

So it's an odd event, but not unheard of, for clients to have
multiple leases bearing their mark.

I think the second scenario is more likely since at least I
can explain it.

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