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

[Gregor Kling]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4684 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20251031/aed34dc8/attachment.p7s>