SV: SV: DISCOVER bursts

Tue Jan 9 18:44:09 UTC 2007

Tanks for the detailed explanation, I am much vicer now ;-)

For a start I just thought it was strange that the server allocated and
offered more than 2 IP leases to the client with a lease limit=2 in a pool.
But off course offered leases are not bound and don’t count as leased as
they are in a pending state, but anyway. Maybe the code should be changed so
that the server don’t offer more than the limit. Makes more sense to novices
like me.

And you are right if a client at any times previously had several different
leases I can understand that the server might try to offer them to the
client.  

And as Simon mentiond previously this behaviour is not that big an issue as
long as the admin can identify and "close" the "malicious" client if needed.

Btw. I don’t get Simons post to the list in my mails, but can read them on
the list ??? Just wundering....

Regards
Lars

> -----Oprindelig meddelelse-----
> Fra: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] På vegne
> af David W. Hankins
> Sendt: 9. januar 2007 18:47
> Til: dhcp-users at isc.org
> Emne: Re: SV: DISCOVER bursts
> 
> 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
> 
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.410 / Virus Database: 268.16.8/621 - Release Date: 09-01-2007
> 13:37