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 <[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]
-- Gregor Kling Abteilung ITS, Sachgebiet ITS-N Technische Hochschule Mittelhessen University of Applied Sciences Tel: 0641/309-1292 E-Mail: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
-- 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]
