[Kea-users] from isc dhcp classes -> kea 3.0
Gregor Kling
gregor.kling at its.thm.de
Tue Nov 18 09:13:22 UTC 2025
Hi Darren,
Thanks for the hint.
Now that provokes the next question :)
So here the adopted version, where the "homebase" of the systems with
mac addresses: "a1:bb:cc:dd:ee:ff" and "a2:bb:cc:dd:ee:ff" are in
subnet id "1":
#+begin_quote
{
"Dhcp4": {
"client-classes": [{
"name": "pool_name_1",
"valid-lifetime": 3600
},
{
"name": "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",
"client-classes": ["pool_name_1",
"pool_name_etc"]
}
],
"reservations": [
{
"hw-address": "a1:bb:cc:dd:ee:ff",
"ip-address": "10.0.0.2",
"client-classes": [ "pool_name_1", "pool_name_etc" ]
},
{
"hw-address": "a2:bb:cc:dd:ee:ff",
"ip-address": "10.0.0.3",
"client-classes": [ "pool_name_etc" ]
}
]
},
{
"id": 2,
"subnet": "192.0.3.0/24",
"pools": [
{
"pool": "192.0.3.10-192.0.3.20",
"client-classes": [ "pool_name_1" ]
},
],
"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
https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#address-reservation-types
states that:
#+begin_quote
Making a reservation for a mobile host that may visit multiple subnets
requires a separate host definition in each subnet that host is expected
to visit. It is not possible to define multiple host definitions with
the same hardware address in a single subnet. Multiple host definitions
with the same hardware address are valid if each is in a different subnet.
Adding host reservations incurs a performance penalty. In principle,
when a server that does not support host reservation responds to a
query, it needs to check whether there is a lease for a given address
being considered for allocation or renewal. The server that does support
host reservation has to perform additional checks: not only whether the
address is currently used (i.e., if there is a lease for it), but also
whether the address could be used by someone else (i.e., if there is a
reservation for it). That additional check incurs extra overhead.
#+end_quote
If i am understanding correctly, i'll have to to put
#+begin_quote
"hw-address": "a1:bb:cc:dd:ee:ff",
"client-classes": [ "pool_name_1", "pool_name_etc" ]
#+end_quote
(without ip-address) in every subnet reservations block where i want
to have the system with the mac address: "a1:bb:cc:dd:ee:ff"
get an address from the "matching" dynamic pool?
gg
On 11/1/25 8:20 PM, Darren Ankney wrote:
> 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
--
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/20251118/4fbf9320/attachment.p7s>
More information about the Kea-users
mailing list