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

Thomas Markwalder tmark at isc.org
Tue Nov 15 11:44:32 UTC 2016


On 11/14/16 4:30 PM, MRob wrote:
>>> When an inbound packet is received things happen in this order:
>>>
>>> 1. The packet is classified by evaluating it against the test
>>> expression for defined classes
>>>
>>> 2. Subnet matching is conducted based on packet content.  This
>>> includes comparing the classes matched to the packet in step 1
>>> against
>>> the classes specified by the subnet's "client-class" list.
>>>
>>> 3. Look for host reservations
>
> It might be nice to add a flow diagram to the docs or some
> explanations of the current limitations of host reservations.
>
That's a good idea.  More doc is always better.

>>> Now, I read briefly about user-chk. Reading a text file upon each
>>> packet arrival doesn't sound efficient, regardless our requirement
>>> is using a database. Would it be possible to:
>>> 1. remove "client-class" from the subnet so all clients can
>>> initially be assigned to the subnet just for purposes of working
>>> around the chicken/egg problem you mentioned
>>> 2. assign class names to known clients using the existing database
>>> reservations system (note, class would be defined in config file
>>> with no "test" expression and our reservations have NULL for the IP
>>> address)
>>> 3. have the user-chk hook library inspect the assigned class and
>>> deny or reassign if the class is empty (not having been assigned in
>>> step 2)
>>>
>>> What
>>> you are proposing is doable, but not with 1.0 as it does not support
>>>
>>> client-classes in the host reservations.
>>>
>>> If you look at the lease4_select hook point arguments:
>>>
>>> * ARGUMENTS:
>>>
>>> * name: QUERY4, type: isc::dhcp::Pkt4Ptr [1], direction: IN
>>> * name: SUBNET4, type: isc::dhcp::Subnet4Ptr [2], direction: IN
>>>
>>> * name: FAKE_ALLOCATION, type: bool, direction: IN
>>> * name: LEASE4, type: isc::dhcp::Lease4Ptr [3], direction:
>>> IN/OUT
>>
>> I had looked earlier myself, but was not able to find a list of hook
>> points. Can you please provide a link to where that is?
>
> I'm still interested if you could provide a link to a list of hooks
> and hook explanations?
>
> The hook developer guide says "Please consult hook API documentation"
> but doesn't seem to tell me where that is.
>

https://jenkins.isc.org/job/Kea_doc/doxygen/de/df3/dhcpv4Hooks.html
lists all of DHCPv4 hook points, their arguments, and descriptive text.  


>> 1. FYI, on a Debian-based system, the include and lib directories for
>> compiling the hook library were somewhat different (especially the
>> lib) than the example in the docs:
>>
>> -I /usr/local/include/kea
>> -L /usr/local/lib
>>
>>  Our apologies. Could you point us to the specific reference?
>
> https://jenkins.isc.org/job/Kea_doc/doxygen/df/d46/hooksdgDevelopersGuide.html#hooksdgBuild
>

I'll open a ticket to address this, thank you.
>
>>> 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.
Glad to hear it's working for you.
FYI, the Developer's guide can be built from the source tar ball or repo
too:

$ cd <kea source tree>/doc/
$ make devel

The guide ends up in <kea source tree>/doc/html.

You may need a few build dependencies installed like doxygen, that are
not required otherwise.

Thomas
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users





More information about the Kea-users mailing list