Re: [Kea-users] from isc dhcp classes -> kea 3.0
Hi Gregor,
You can safely use either one. When Kea encounters a subnet/pool for
which 10.0.0.2 is not relevant, it will not assign the address. The
client will instead receive a pool address.
Thank you,
Darren Ankney
On Mon, Nov 24, 2025 at 3:52 AM Gregor Kling wrote:
>
> Hi Darren,
>
> On 11/21/25 4:38 PM, Darren Ankney wrote:
> > Hello Gregor,
> >
> >> Hi Darren,
> >>
> >> Deciding the reservation model
> >>
> >> 9.3.9. Global Reservations in DHCPv4 describes in general our
> >> setup. Clients generally can roam in our network based on the
> >> attributed "pool class" to the specific mac address and the
> >> "accessability" of the specific network.
> >>
> >> The following section:
> >>
> >> #+begin_quote 9.3.9. Global Reservations in DHCPv4:
> >> An address assigned via global host reservation must be feasible for the
> >> subnet the server selects for the client. In other words, the address
> >> must lie within the subnet; otherwise, it is ignored and the server will
> >> attempt to dynamically allocate an address. If the selected subnet
> >> belongs to a shared network, the server checks for feasibility against
> >> the subnet's siblings, selecting the first in-range subnet. If no such
> >> subnet exists, the server falls back to dynamically allocating the address.
> >> #+END_quote
> > This is generally true, but you are not (as far as I understood)
> > assigning an address to the clients in the reservation and instead are
> > selecting a pool for them to use for a dynamic address with the
> > reservation (by adding the client to one or more classes and using a
> > class guard on the pools).
>
> Generally true - yes - but with the following exception.
>
> Again given the following setup. When the host with the
> mac "a1:bb:cc:dd:ee:ff" visits his "homebase",
>
> subnet id 1 it should be given the "ip-address": "10.0.0.2" and not a
> pool address.
>
> Should this host however visit, for example subnet id 2, it should be
> given a pooladdress.
>
> So the the question remains (on this blurry monday morning) - which
> reservation model should i use?
>
> #+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
>
>
> --
>
> 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]
Re: [Kea-users] from isc dhcp classes -> kea 3.0
Hi Darren,
On 11/21/25 4:38 PM, Darren Ankney wrote:
Hello Gregor,
Hi Darren,
Deciding the reservation model
9.3.9. Global Reservations in DHCPv4 describes in general our
setup. Clients generally can roam in our network based on the
attributed "pool class" to the specific mac address and the
"accessability" of the specific network.
The following section:
#+begin_quote 9.3.9. Global Reservations in DHCPv4:
An address assigned via global host reservation must be feasible for the
subnet the server selects for the client. In other words, the address
must lie within the subnet; otherwise, it is ignored and the server will
attempt to dynamically allocate an address. If the selected subnet
belongs to a shared network, the server checks for feasibility against
the subnet's siblings, selecting the first in-range subnet. If no such
subnet exists, the server falls back to dynamically allocating the address.
#+END_quote
This is generally true, but you are not (as far as I understood)
assigning an address to the clients in the reservation and instead are
selecting a pool for them to use for a dynamic address with the
reservation (by adding the client to one or more classes and using a
class guard on the pools).
Generally true - yes - but with the following exception.
Again given the following setup. When the host with the
mac "a1:bb:cc:dd:ee:ff" visits his "homebase",
subnet id 1 it should be given the "ip-address": "10.0.0.2" and not a
pool address.
Should this host however visit, for example subnet id 2, it should be
given a pooladdress.
So the the question remains (on this blurry monday morning) - which
reservation model should i use?
#+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
--
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]
Re: [Kea-users] from isc dhcp classes -> kea 3.0
Hello Gregor,
> Hi Darren,
>
> Deciding the reservation model
>
> 9.3.9. Global Reservations in DHCPv4 describes in general our
> setup. Clients generally can roam in our network based on the
> attributed "pool class" to the specific mac address and the
> "accessability" of the specific network.
>
> The following section:
>
> #+begin_quote 9.3.9. Global Reservations in DHCPv4:
> An address assigned via global host reservation must be feasible for the
> subnet the server selects for the client. In other words, the address
> must lie within the subnet; otherwise, it is ignored and the server will
> attempt to dynamically allocate an address. If the selected subnet
> belongs to a shared network, the server checks for feasibility against
> the subnet's siblings, selecting the first in-range subnet. If no such
> subnet exists, the server falls back to dynamically allocating the address.
> #+END_quote
This is generally true, but you are not (as far as I understood)
assigning an address to the clients in the reservation and instead are
selecting a pool for them to use for a dynamic address with the
reservation (by adding the client to one or more classes and using a
class guard on the pools).
>
> with the given example:
>
> #+begin_quote
> "Dhcp4": {
> # This specifies global reservations.
> # They will apply to all subnets that
> # have global reservations enabled.
>
> "reservations": [
> {
> "hw-address": "aa:bb:cc:dd:ee:ff",
> "hostname": "hw-host-dynamic"
> },
> {
> "hw-address": "01:02:03:04:05:06",
> "hostname": "hw-host-fixed",
>
> # Use of IP addresses in global reservations is risky.
> # If used outside of a matching subnet, such as 192.0.1.0/24,
> # it will result in a broken configuration being handed
> # to the client.
> "ip-address": "192.0.1.77"
> },
> {
> "duid": "01:02:03:04:05",
> "hostname": "duid-host"
> },
> {
> "circuit-id": "'charter950'",
> "hostname": "circuit-id-host"
> },
> {
> "client-id": "01:11:22:33:44:55:66",
> "hostname": "client-id-host"
> }
> ],
> "valid-lifetime": 600,
> "subnet4": [
> {
> "id": 1,
> "subnet": "10.0.0.0/24",
> # Specify if the server should look up global reservations.
> "reservations-global": true,
> # Specify if the server should look up in-subnet reservations.
> "reservations-in-subnet": false,
> # Specify if the server can assume that all reserved addresses
> # are out-of-pool. It can be ignored because "reservations-in-subnet"
> # is false.
> # "reservations-out-of-pool": false,
> "pools": [ { "pool": "10.0.0.10-10.0.0.100" } ]
> }
> ]
> }
> #+end_quote
>
> contradicts (at least at my current understanding) with:
>
> https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#host-reservations-in-dhcpv4
> (9.3. Host Reservations in DHCPv4)
> #+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.
> #+end_quote
>
> that wants a reservation at the subnet level.
There are multiple ways to do it. The advice shown in the example:
"Use of IP addresses in global reservations is risky." Is no longer
correct as explained in the "Note" just above this example:
"Prior to release 2.3.5, the server did not perform feasibility checks
on globally reserved addresses, which allowed the server to be
configured to hand out nonsensical leases for arbitrary address
values. Later versions of Kea perform these checks."
The current stable releases of Kea are 2.6.4 and 3.0.2 both of which
are fully capable of assigning an address globally with the
reservation mechanism. It is no longer possible for Kea to assign an
address in a subnet that doesn't actually match that address because
of a global assignment. However, global reservations are ignored by
default (for performance reasons) and must be enabled with
`"reservations-global": true` as noted previously.
>
> Then there is also the part:
> #+begin_quote
> # Specify if the server should look up global reservations.
> "reservations-global": true,
> # Specify if the server should look up in-subnet reservations.
> "reservations-in-subnet": false,
> #+end_quote
>
>
> where in
> https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation
>
>
> (9.3.8. Fine-Tuning DHCPv4 Host Reservation) it is explained
> that in the setup using resertations-global deactivates the use of
> reservations-in-subnet anyway (so why is it even defin
Re: [Kea-users] from isc dhcp classes -> kea 3.0
Hi Darren,
Deciding the reservation model
9.3.9. Global Reservations in DHCPv4 describes in general our
setup. Clients generally can roam in our network based on the
attributed "pool class" to the specific mac address and the
"accessability" of the specific network.
The following section:
#+begin_quote 9.3.9. Global Reservations in DHCPv4:
An address assigned via global host reservation must be feasible for the
subnet the server selects for the client. In other words, the address
must lie within the subnet; otherwise, it is ignored and the server will
attempt to dynamically allocate an address. If the selected subnet
belongs to a shared network, the server checks for feasibility against
the subnet's siblings, selecting the first in-range subnet. If no such
subnet exists, the server falls back to dynamically allocating the address.
#+END_quote
with the given example:
#+begin_quote
"Dhcp4": {
# This specifies global reservations.
# They will apply to all subnets that
# have global reservations enabled.
"reservations": [
{
"hw-address": "aa:bb:cc:dd:ee:ff",
"hostname": "hw-host-dynamic"
},
{
"hw-address": "01:02:03:04:05:06",
"hostname": "hw-host-fixed",
# Use of IP addresses in global reservations is risky.
# If used outside of a matching subnet, such as 192.0.1.0/24,
# it will result in a broken configuration being handed
# to the client.
"ip-address": "192.0.1.77"
},
{
"duid": "01:02:03:04:05",
"hostname": "duid-host"
},
{
"circuit-id": "'charter950'",
"hostname": "circuit-id-host"
},
{
"client-id": "01:11:22:33:44:55:66",
"hostname": "client-id-host"
}
],
"valid-lifetime": 600,
"subnet4": [
{
"id": 1,
"subnet": "10.0.0.0/24",
# Specify if the server should look up global reservations.
"reservations-global": true,
# Specify if the server should look up in-subnet reservations.
"reservations-in-subnet": false,
# Specify if the server can assume that all reserved addresses
# are out-of-pool. It can be ignored because
"reservations-in-subnet"
# is false.
# "reservations-out-of-pool": false,
"pools": [ { "pool": "10.0.0.10-10.0.0.100" } ]
}
]
}
#+end_quote
contradicts (at least at my current understanding) with:
https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#host-reservations-in-dhcpv4
(9.3. Host Reservations in DHCPv4)
#+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.
#+end_quote
that wants a reservation at the subnet level.
Then there is also the part:
#+begin_quote
# Specify if the server should look up global reservations.
"reservations-global": true,
# Specify if the server should look up in-subnet reservations.
"reservations-in-subnet": false,
#+end_quote
where in
https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation
(9.3.8. Fine-Tuning DHCPv4 Host Reservation) it is explained
that in the setup using resertations-global deactivates the use of
reservations-in-subnet anyway (so why is it even defined):
#+begin_quote 9.3.8. Fine-Tuning DHCPv4 Host Reservation
{
"Dhcp4": {
"reservations-global": true,
"reservations-in-subnet": false
}
}
#+end_quote
Right this mail is already to big, so i will postpone my questions on
the decision diagram in 9.3.8. Fine-Tuning DHCPv4 Host Reservation.
gg
On 11/20/25 9:52 AM, Gregor Kling wrote:
Hi Darren,
On 11/19/25 3:58 PM, Darren Ankney wrote:
Hi Gregor,
That *should* work, but you don't have to do it that way. You could
specify the reservation globally, set `"reservations-global": true`
(https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation)
and specify whatever classes are necessary in "client-classes" so that
you would only need to have one entry per client. This may reduce
performance but see here: https://reports.kea.isc.org/ for Kea
performance numbers, perhaps it is not a concern?
Actually this is the part where i am right now trying to wrap my head
around.
It is totally unclear to me if reservations-in-subnet or
reservations-global is what i should use.
I guess you will hear from me for this one as well :)
gg
Thank you,
Darren Ankney
On Wed, Nov 19, 2025 at 4:16 AM Gregor Kling
wrote:
Hello,
On 11/18/25 10:13 AM, Gregor Kling wrote:
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
Re: [Kea-users] from isc dhcp classes -> kea 3.0
Hi Darren, On 11/19/25 3:58 PM, Darren Ankney wrote: Hi Gregor, That *should* work, but you don't have to do it that way. You could specify the reservation globally, set `"reservations-global": true` (https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation) and specify whatever classes are necessary in "client-classes" so that you would only need to have one entry per client. This may reduce performance but see here: https://reports.kea.isc.org/ for Kea performance numbers, perhaps it is not a concern? Actually this is the part where i am right now trying to wrap my head around. It is totally unclear to me if reservations-in-subnet or reservations-global is what i should use. I guess you will hear from me for this one as well :) gg Thank you, Darren Ankney On Wed, Nov 19, 2025 at 4:16 AM Gregor Kling wrote: Hello, On 11/18/25 10:13 AM, Gregor Kling wrote: 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? To answer myself: https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#host-reservations-in-dhcpv4 is clear about 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. #+end_quote 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]
Re: [Kea-users] from isc dhcp classes -> kea 3.0
Hi Gregor, That *should* work, but you don't have to do it that way. You could specify the reservation globally, set `"reservations-global": true` (https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation) and specify whatever classes are necessary in "client-classes" so that you would only need to have one entry per client. This may reduce performance but see here: https://reports.kea.isc.org/ for Kea performance numbers, perhaps it is not a concern? Thank you, Darren Ankney On Wed, Nov 19, 2025 at 4:16 AM Gregor Kling wrote: > > Hello, > > > On 11/18/25 10:13 AM, Gregor Kling wrote: > > > > 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? > > > To answer myself: > > https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#host-reservations-in-dhcpv4 > > > is clear about 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. > #+end_quote > > > 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]
Re: [Kea-users] from isc dhcp classes -> kea 3.0
Hello, On 11/18/25 10:13 AM, Gregor Kling wrote: 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? To answer myself: https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#host-reservations-in-dhcpv4 is clear about 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. #+end_quote gg -- 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]
Re: [Kea-users] from isc dhcp classes -> kea 3.0
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 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:
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" ]
Re: [Kea-users] from isc dhcp classes -> kea 3.0
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 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:
>
>
>
> 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]
