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 > >> -- > >> 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] -- 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]
