[Kea-users] Need help assigning subnets by class with host reservations

[Thomas Markwalder]

On 11/15/16 6:49 AM, Thomas Markwalder wrote:
> On 11/14/16 5:05 PM, MRob wrote:
>>>>> 3. Is using "lease.decline(0)" the best (only) way, at least in this
>>>>> hook point, to turn away unknown clients? That's what I've done and
>>>>> it works, though the lease is still processed and sent to the
>>>>> client, but with what I think is a lease for zero seconds.
>>>>  Declining a lease is intended to be a client initiated action, so I
>>>> don't really think this is direction to go.  If you set the
>>>> lease4_select next step action to SKIP before returning from your
>>>> lease4_select hook:
>>>>
>>>> "NEXT STEP STATUS: If any callout installed on the "lease4_select"
>>>> hook sets the next step action to SKIP, the server will not assign any
>>>> lease and the callouts become responsible for the lease assignment. If
>>>> the callouts fail to provide a lease, the packet processing will
>>>> continue, but client will not get an address."
>>>>
>>>> If your callout does not then assign a lease using its own decision
>>>> making,  the server will generate a NAK to your client.
>>> This works much better (though again, would have not needed to bother
>>> you if I had been able to find the docs you quote here). Thanks again
>>> for all your help, it's working quite nicely now.
>> Caveat: when a lease is skipped, the server immediately tries again to
>> allocate another lease for the client, and does this many more times
>> in the same second, so much so that there are nearly 2000 lines of
>> logging at maximum verbosity before a NAK is sent. Then it keeps
>> trying many times per second for another few seconds.
>>
>> This seems quite excessive. Shouldn't the server send the NAK and stop
>> retrying after a lease is denied? At a minimum, retries should be rate
>> limited or limited to X number of retries.
> This does not sound like the intended outcome, we'll need to look into
> this. An excerpt of your log file would helpful.
>

Hi:

Nevermind the log excerpt,  after examining the code this quite clearly
a bug on our part.  I have created the following ticket to track this:

http://kea.isc.org/ticket/5070#ticket

You'll need to register with our Trac site to follow it and to report
issues as well.   The basic issue is that the skip is not being
propagated upward far enough for the allocation engine to realize why
the allocation is resulting in no lease.  If you're curious,
The lease4_select hook is executed within AllocEngine::createLease4().
This method sees the skip and returns an empty lease pointer to
AllocEngine::allocateOrReuseLease4() which returns it to
AllocEngine::allocateUnreservedLease4().  This method sees the empty
lease pointer and simply tries again until max attempts is reached.  The
skip needs to be acknowledged in this method rather than retrying. 

Sorry for the inconvenience may cause you.

Thomas