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