Hi Gregor, You almost have it I think. Remove the test lines from your classes, and set class guards on your pools similar to your allow statements in ISC DHCP (see here: https://kea.readthedocs.io/en/kea-2.6.4/arm/dhcp4-srv.html#pool-selection-with-class-reservations4).
Thank you, Darren Ankney On Fri, Oct 31, 2025 at 5:32 AM Gregor Kling <[email protected]> wrote: > > Hello, > > Maybe someof you can help out, or have a similar setup.. > > * isc dhcp subclass handling -> kea (3.0) > > in isc dhcp we are using class membership to control pool access. > For example: > #+begin_quote > for net a1: > subnet 10.xxx.yyy.0 netmask 255.255.255.0 { > option routers 10.xxx.yyy.1; > option domain-name-servers 1.2.2.3; > > //// the following include "a1.sub" contains list of: > //// <subclass "pool_name_1" [mac_addr_1];> > //// <subclass "pool_name_etc" [mac_addr_1];> > //// <subclass "pool_name_1" [mac_addr_2];> > include "a1.sub"; > > > pool { > > allow members of "pool_name_1"; > allow members of "pool_name_etc"; > > range 10.xxx.yyy.123; > range 10.xxx.yyy.152; > range 10.xxx.yyy.154; > > } > } > #+end_quote > > so, the question is, would the following be equivalent to the above isc > dhcp setup (leaving the shared-network out, assuming that part would make > no difference)? > #+begin_quote > { > "Dhcp4": { > "client-classes": [{ > "name": "pool_name_1", > "test": "member('pool_name1')", // <- will reservations do? > "valid-lifetime": 3600 > }, > { > "name": "pool_name_etc", > "test": "member('pool_name_etc')", > "valid-lifetime": 3600 > }, > ], > "subnet4": [ > { > "id": 1, > "subnet": "10.0.0.0/24", > "pools": [ { "pool": "10.0.0.10-10.0.0.100" } ], > "reservations": [ > { > "hw-address": "a1:bb:cc:dd:ee:ff", > "client-classes": [ "pool_name_1", "pool_name_etc" ] > > }, > { > "hw-address": "a2:bb:cc:dd:ee:ff", > "client-classes": [ "pool_name_etc" ] > > } > > ] > }] > > } > > } > > #+end_quote > > the <"test": "member('pool_name1')"> could be a problem regards to the > documentation: > https://kea.readthedocs.io/en/kea-3.0.1/arm/classify.html#client-classification-overview > > -> > member('foobar') checks whether the packet belongs to the client class > foobar. To avoid dependency loops, the configuration file parser > verifies whether client classes were already defined or are built-in, > i.e., beginning with VENDOR_CLASS_, AFTER_ (for the to-come "after" > hook) and EXTERNAL_ or equal to ALL, KNOWN, UNKNOWN, etc. > known and unknown are shorthand for member('KNOWN') and not > member('KNOWN'). > > Note that the evaluation of any expression using the KNOWN class > (directly or indirectly) is deferred after the host reservation lookup > (i.e. when the KNOWN or UNKNOWN partition is determined). > <- > > gg > > -- > Gregor Kling > > Abteilung ITS, Sachgebiet ITS-N > Technische Hochschule Mittelhessen > University of Applied Sciences > Tel: 0641/309-1292 > E-Mail: [email protected] > > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > [email protected] -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. [email protected]
