Feature #15934
open
Feature #15650: Kea Feature Integration for parity with ISC DHCP
Kea Lease Reclamation and Affinity Options (IPv4 and IPv6)
0%
Description
The lease allocation and reclamation behavior in Kea is more aggressive than that in ISC DHCP. As a consequence, users are being surprised by unexpected IP address changes when users leases had been fairly stable under ISC DHCP.
At the moment the only option users have to influence this is to greatly increase the default lease time (and maximum in certain cases), but Kea has other options to fine-tune its behavior.
See the Kea docs at https://kea.readthedocs.io/en/kea-2.6.1/arm/lease-expiration.html#lease-reclamation
We could use some global GUI options to tweak the behavior using the options listed in https://kea.readthedocs.io/en/kea-2.6.1/arm/lease-expiration.html#lease-reclamation-configuration-parameters -- they appear to be global options, not per-subnet, but it's possible they might work both ways. We could use default values for those which are much more lenient than Kea's own defaults.
As a part of improving the lease allocation behavior, we could also use a global option to drop or ignore DHCP release packets from clients which also trigger Kea to reclaim a lease immediately:
- https://kb.isc.org/docs/using-the-kea-dhcp-drop-class
- https://lists.isc.org/pipermail/kea-users/2021-November/003239.html
Feel free to kick it ahead to the next release if there is not enough time or it ends up being much more complicated.
Updated by Dale Harron 9 months ago
Lease Affinity provides a way to have IP/MAC association persist beyond expiry but it does not survive a reboot.
https://kea.readthedocs.io/en/kea-2.6.1/arm/lease-expiration.html#lease-reclamation-configuration-parameters (see 11.4)
Setting a default affinity value would reduce the concern until a reboot at least.
To observe this, go to /etc/inc/services.inc and add 'expired-leases-processing':
$keaconf['Dhcp4'] = [
'interfaces-config' => [
'interfaces' => []
],
'lease-database' => [
'type' => 'memfile',
'persist' => true,
'name' => $kea_var_lib . '/dhcp4.leases'
],
'expired-leases-processing' => [
'reclaim-timer-wait-time' => 3,
'hold-reclaimed-time' => 86400,
'flush-reclaimed-timer-wait-time' => 5
],
'loggers' => [[
Kea is aware of this and working on a solution, re: https://gitlab.isc.org/isc-projects/kea/-/issues/3352
Updated by
Updated by Jim Pingle 2 months ago
- Plus Target Version changed from 25.07 to 25.11
Updated by Dale Harron 27 days ago
With 2.80 and Plus 25.07, I have identified that the following as an issue and should be easy to correct.
Upon a reboot, the "Show All Configured Leases" list will include all leases, including those that are expired but still protected by "Lease Affinity". Kea's default value for hold-reclaimed-time is 3600 seconds or one hour. During that time a new lease for a new MAC will get an IP that is NOT in the Configured leases list. Once the 3600 seconds expire, Kea will remove the IP from the "Show All Configured Leases" List but typically continue to allocate new leases in a numerically higher value until the pool is fully allocated. Affinity can be further modified by setting hold-reclaimed-time in expired-leases-processing as mentioned above. This is working well and behaves as expected until a reboot.
After a reboot, the "Show All Configured Leases" List looks identical but none of the expired leases are protected by "affinity" as they behave equivalent to the hold-reclaimed-time being zero seconds and any new MAC will receive the lowest numerically available IP from the pool, even if it is in the Configured Leases List. Prior to the reboot it was protected.
Any new leases issued post-reboot will return to the behavior described in the first paragraph above. Because of this drastic change in IP allocation logic, this is a problem for many devices that require the same IP and would normally have been protected by the Affinity setting be it the default 3600 seconds or a value overridden in expired-leases-processing.
As the Configured Leases information survives the reboot intact, it should be relatively simple to configure Kea to respect Affinity as it did prior to the reboot. Simply re-calculate it, all the information needed is in the Configured Leases list.
Until this is fixed, we can not use Plus 25.07 or CE 2.80 in Kea DHCP mode and ISC must remain available. pfSense should not change it's IP allocation strategy just because the server was rebooted.