[Kea-users] from isc dhcp classes -> kea 3.0

[Darren Ankney]

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 <gregor.kling at its.thm.de> 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: gregor.kling at its.thm.de
>
> --
> 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.
> Kea-users at lists.isc.org