[Kea-users] Problem with setting "valid-lifetime" in a client-class
kesper
kesper at hrz.uni-marburg.de
Thu Jan 29 11:12:25 UTC 2026
-------- Weitergeleitete Nachricht --------
Betreff: Re: [Kea-users] Problem with setting "valid-lifetime" in a
client-class
Datum: Wed, 28 Jan 2026 16:36:51 +0100
Von: Kesper Kurt <kesper at hrz.uni-marburg.de>
An: Darren Ankney <darren.ankney at gmail.com>
Hello Darren,
thanks a lot for your explanation. There is still a thing that i don't
understand.
In my class-defintiton i set a special value for "valid-lifetime" and
for the option "domain-name-servers". In case i have the
shared-networks[] around the subnet i observe no special
"valid-lifetime" but "domain-name-servers" is changet according to the
class definition.
How can this happen, if the class membership is not even considered?
What i try to achieve is, to have reservations for all my clients, but
with the possibility to have reservations for the same client
(MAC-address) in more than one subnet. The DHCP-communication is relayed
by the routers, which have an IP-Interface in the subnets.
Therefore i don't think i can do it with global reservations. I'm not
sure, if shared-networks[] are neccessary for this. In case of many
subnets inside of a shared-network a broadcast DHCPDISCOVER could be
relayed by any of the router-interfaces, so that we cannot determine the
subnet without the shared-network information (of course a host
reservertion should only occur once in a shared-network).
Best regards
Kurt
Am 22.01.26 um 18:04 schrieb Darren Ankney:
> Hi Kurt,
>
> This is intentional behavior as noted here:
> https://gitlab.isc.org/isc-projects/kea/-/issues/4003 The ARM was
> changed in 3.1.2 to clarify this behavior. See here:
> https://kea.readthedocs.io/en/latest/arm/classify.html#classification-steps
> where it says:
>
> "If there is a matching reservation from the selected subnet and that
> subnet belongs to a shared-network, then the assignment of any classes
> specified in the reservation is deferred until after lease allocation.
> This is done to account for the possibility that the subnet selection
> may change during lease allocation and that would negate and possibly
> replace the original reservation match."
>
> So your client's lease has already been finalized before the class
> membership is considered. A global reservation would work here,
> however. But, if you don't need the shared network, then you should
> use just a bare subnet as the right way.
>
> Thank you,
> Darren Ankney
>
> On Wed, Jan 21, 2026 at 11:38 AM kesper via Kea-users
> <kea-users at lists.isc.org> wrote:
>>
>> Hello,
>>
>> i'm trying to set a special value for "valid-lifetime" with a globally
>> defined client-class:
>>
>>
>> "valid-lifetime" : 3333,
>> ...
>> "client-classes" : [
>> {
>> "name" : "InfiniteLease",
>> "valid-lifetime": 4294967295,
>> "option-data" : [
>> {
>> "code" : 6,
>> "data" : "1.2.3.4",
>> "name" : "domain-name-servers"
>> }
>> ]
>> }
>>
>> later on in the configuration i have
>>
>> "shared-networks" : [
>> {
>> "name" : "DHCP-Test",
>> "subnet4" : [
>> {
>> "id" : 1,
>> "option-data" : [
>> {
>> "data" : "9.8.7.6",
>> "name" : "domain-name-servers"
>> },
>>
>> ...
>>
>> ],
>> "reservations" : [
>>
>> {
>> "client-classes" : [
>> "InfiniteLease",
>> ],
>> "hostname" : "testpc-kea",
>> "hw-address" : "00:17:C3:C2:73:E3",
>> "ip-address" : "5.6.7.8",
>> "option-data" : [
>> {
>> "data" : "testpc-kea",
>> "name" : "host-name"
>> },
>> {
>> "data" : "example.org",
>> "name" : "domain-name"
>> }
>> ] #option-data
>> } #testpc-kea
>>
>> ] #reservations
>> } #subnet4
>> } #DHCP-Test
>> ] #shared-networks
>>
>>
>>
>> In this scenario the client testpc-kea doesn't get the expected
>> valid-lifetime of 4294967295, but instead the default of 3333. But it
>> _does_ get domain-name-servers="1.2.3.4", so i can tell that it is
>> associated with the client-class=InfiniteLease".
>>
>> In a second test i removed the shared-networks[] from the configuration.
>> When i have only the subnet4-declaration the clients gets
>> "valid-lifetime"= 4294967295 as intended (and also
>> domain-name-servers="1.2.3.4"). The only difference is the removal of
>> shared-networks.
>>
>> This seems a bit confusing to me. Is this a bug in kea or is the
>> shared-networks-declaration changing the scope of valid-lifetime in an
>> (for me) unexpected way?
>>
>> Any help or explanation is appreciated.
>>
>> Thanks,
>> Kurt
>>
>> --
>> Kurt Kesper
>> Abteilung Kommunikation
>> Hochschulrechenzentrum (HRZ)
>>
>> Philipps-Universität Marburg
>> Hans-Meerwein-Straße 6
>> 35032 Marburg
>>
>> https://www.uni-marburg.de/de/hrz
>> --
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4688 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20260129/5a98d856/attachment.p7s>
More information about the Kea-users
mailing list