Hello Darren,in the meantime i have found a solution for my problem which is a kind of workaround inspired by this article:
https://kb.isc.org/docs/redefining-standard-options
In the global section i inserted:
"hooks-libraries": [
{
"library": "libdhcp_flex_option.so",
"parameters": {
"options": [
{
"code": 51,
"supersede": "4294967295",
"client-class": "InfiniteLease"
}
]
}
}
],
Now all members of InfiniteLease get the right valid-lifetime. We can
also see from this, that the class membership of the client selected as
indended. Since the problem only exists for valid-lifetime (oher options
work as expected) i believe this is a bug in kea which treats this
special option differently at this point.
I understand that this solution is somewhat ugly, because the value is overwritten at the end after processing the request. So the kea-server registers a different valid-lifetime (the default) in its lease-database and will expire the lease thereafter, while the client could still be using it.
I think for me this is ok anyway, because the intended purpose for this class are devices (printers, iot-devices, ...) with a broken dhcp-client, which ask once for a lease and never renew it when it expires. They will have reservations with fixed ip-addresses, so they won't be given to other clients when they expire.
The "infinite" value in the valid-lifetime is necessary for our network-switches, which use so-called layer2-security. This means they cut the network-connection when a client uses its ip-address longer than its lease allows it.
Best regards Kurt Am 04.02.26 um 15:54 schrieb Kesper Kurt:
Hello Darren,i send the requested files attached to this mail. You can switch between the two scenarios (with or without shared-subnets) by commenting out the lines marked with "###" in the file kea-dhcp4.conf.Please bear in mind that the global default for the option "domain-name- servers" is never selected. It is always set in the class "InfiniteLease".Thank you very much, Kurt Kesper ------------------------ > Date: Sun, 1 Feb 2026 10:38:06 -0500 > From: Darren Ankney <[email protected]> > To: "Kea user's list" <[email protected]> > Subject: Re: [Kea-users] Problem with setting "valid-lifetime" in a > client-class > Message-ID: > <CAKabWHgHiAsK=zosu5uqp86la4vc+jamn83ndrgeiytotq8...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Kesper, > > At this point I would need to see your full configuration (with > sensitive data, such as database passwords, redacted), additionally, > I'd need to see debuglevel 99 logs, and finally, I would also need to > see a pcap of a DORA for the client in question. Then I would be in a > better position to explain. > > Thank you, > Darren Ankney > > On Thu, Jan 29, 2026 at 6:12?AM kesper via Kea-users > <[email protected]> wrote: >> >> -------- 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 <[email protected]> >> An: Darren Ankney <[email protected]> >> >> 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 >>> <[email protected]> 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
smime.p7s
Description: Kryptografische S/MIME-Signatur
-- 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]
