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

[Thomas Markwalder]

On 11/15/16 7:27 AM, Thomas Markwalder wrote:
> 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
>
If you're feeling adventurous, I believe this patch would solve the
problem for you:

diff --git a/src/lib/dhcpsrv/alloc_engine.cc
b/src/lib/dhcpsrv/alloc_engine.cc
index bc37eeb..c87af16 100644
--- a/src/lib/dhcpsrv/alloc_engine.cc
+++ b/src/lib/dhcpsrv/alloc_engine.cc
@@ -2841,6 +2841,10 @@
AllocEngine::allocateUnreservedLease4(ClientContext4& ctx) {
             new_lease = allocateOrReuseLease4(candidate, ctx);
             if (new_lease) {
                 return (new_lease);
+            } else {
+                if (ctx.callout_handle_->getStatus() ==
CalloutHandle::NEXT_STEP_SKIP) {
+                    break;
+                }
             }
         }
     }

There are other variations and this may not be the prettiest, and it has
NOT been tested.
>
>
>
>
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users