[Kea-users] Problem with setting "valid-lifetime" in a client-class
Kesper Kurt
kesper at hrz.uni-marburg.de
Wed Mar 4 17:14:46 UTC 2026
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 <darren.ankney at gmail.com>
> > To: "Kea user's list" <kea-users at lists.isc.org>
> > Subject: Re: [Kea-users] Problem with setting "valid-lifetime" in a
> > client-class
> > Message-ID:
> > <CAKabWHgHiAsK=ZOsu5uqp86La4VC+Jamn83NDRGeiYTotq8ktQ at 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
> > <kea-users at lists.isc.org> 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 <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
>
-------------- 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/20260304/47c4a7c4/attachment.p7s>
More information about the Kea-users
mailing list