KEA DHCP lease allocation and reclamation
-
I recently switched to the
KeaDHCP server on CE 2.8.1 and observed that the lease duration is only 2h.I therefore updated the (custom) config to match the
ISCDHCP lease times (minimum 2h, maximum 24h, default 24h).{ "min-valid-lifetime": 7200, "valid-lifetime": 86400, "max-valid-lifetime": 86400 }However, after reading https://redmine.pfsense.org/issues/15934, I'm not sure if this will help to mimic the
ISCbehaviour in terms of lease allocation and reclamation. Do I understand correctly thatKeawill assign a new (numerically lower available) IP after a lease expiry (includingKealease affinity) even if the client is requesting its old/preferred IP (and the preferred IP is still available in the pool)? -
@cybis
These are the values I have right now :
that said, I use Plus, so 26.03.1. I'm pretty sure that if CE doesn't uses these values, it will do so very soon - next update.
The "min-valid-lifetime" is, imho, very optional, as every wifi device will renew way more often as that, as their radio connection comes and goes, and every time the wifi comes back, a DHCP sequence is initiated anyway.
Cheap devices (look to the east) won't give a d*mn anyway, and do what they want to do.@cybis said in KEA DHCP lease allocation and reclamation:
Do I understand correctly that Kea will assign a new (numerically lower available) IP after a lease expiry (including Kea lease affinity) even if the client is requesting its old/preferred IP (and the preferred IP is still available in the pool)?
Without reading the manual - and fact-checking the thing (as I have kea, and some LAN devices, so easy to check) : if a lease expires - was not renewed in time - and the device comes back, and the IP is still avaible, and it was previously assigned to the same MAC device, then the same device (MAC) will get the same lease = IPv4 back.
After all : why not ^^ this seem logic to me.
I can imagine that a kea option (not present in the GUI, but kea has it, see manual) exists that randomizes IP assignment as, after all, again : why not. There are surely people out their that find that useful.
And our wifi devices these days love to rotate their MAC address, so the DHCPv4 server can't recognize the device and will assign another lease (= IPv4) every time the device reconnects and asks a lease. -
Kea uses the lease affinity settings to determine how long to hold onto a MAC/IP association and runs a lease file cleanup routine regularly to remove those associations for good. ISC retains a MAC/IP association until the IP is reused, often months or years for lightly used systems. With Kea, once an IP looses "affinity", the same MAC connection to Kea DHCP will get a new IP address unless specifically requesting an available IP through the DORA sequence (rare). This is great, just set the lease affinity value to a long time (weeks, month, etc) if you want the same IP for a CP authenticated MAC. See: Kea documentation.
Unfortunately a restart or repowering of Kea will retain affinity settings (as in "Configured Leases" under Status, DHCP Leases) BUT....... all leases that were active prior to the restart will no longer have any affinity once they time out and all timed out leases are no longer associated with a MAC through affinity. This means, under CP, that if you rely on a device "going to lunch" with a 2 hr lease and 1 week lease affinity, returning and reconnecting to the CP after the lease has timed out, it will only get the same IP if the power stayed on and Kea was not reset. If there was a restart of Kea, due to power or deliberately, Kea's internal state logic starts assigning IPs from the lowest number upwards and ignores any remaining lease affinity time on all expired leases. If your device was unlucky enough to have a low numbered lease and something else connects before you return from lunch, you don't get your IP back. If you are lucky and Kea has not yet reused that IP, there is a probability, but not certainty, that you will get the same IP. Kea will continue to assign the next lowest numbered lease until two or so matched and available MAC/IP pairs are set in sequence, then it will start issuing leases above that value. It is a total mess.
Now of course, not a problem, the login is set to expire before the lease expires because that is what is recommended? Yes, that is the official position but in the real world for convenience and in part to ensure sufficient leases are available, many CP setups rely on ISC's retention of affinity association to reduce the frequency of logins, often once for the entire duration of the voucher or session duration variables. These CPs will break under Kea and both the old MAC association in CP and the New MAC association that now shares the same IP will not work. This is only a problem if you want fewer logins and "normal" lease durations. Lease Affinity set to a high value can make this possible in Kea but it breaks on a restart of Kea. ISC, no problem until the lease pool is exhausted and ISC will re-allocate from the oldest expired lease to the most recent so under ISC you can run days, weeks, months or years on some systems while still retaining affinity, including power losses and restarts of ISC.
See Kea for their status on this: https://gitlab.isc.org/isc-projects/kea/-/issues/3352
See https://redmine.pfsense.org/issues/15904 if you would like a way to manage CPs authentication by MAC address rather than IP. The intent is to detect an authorized MAC and check the current IP against that stored in CP and update the database if it has changed. It also sets an orphaned MAC in CP to NOIP as a holder until that MAC reconnects at which time it will re-associate an IP in the database without loosing the authenticated state in CP. This is compatible with the KEA bug above but very CPU intensive, especially at a reboot if you have a lot of authenticated clients in CP that are getting different IPs from KEA after the reboot.
Sticking with ISC in the short term is a simpler solution until Kea fixes the restart issue with lease affinity.
-
@Gertjan said in KEA DHCP lease allocation and reclamation:
that said, I use Plus, so 26.03.1. I'm pretty sure that if CE doesn't uses these values, it will do so very soon - next update.
I can confirm thast those are the default values on CE as well.
@EDaleH said in KEA DHCP lease allocation and reclamation:
Sticking with ISC in the short term is a simpler solution until Kea fixes the restart issue with lease affinity.
Thanks a lot for the detailed explanation and the additional links. As
unboundkept resarting quite often withISCwhich affected user experience, I had to switch toKea. WithpfBlockerupdating its feeds once a day, there's also a dailyKearestart. So based on the technical details you provided, the only short term solution I see would be to further increase the lease time (provided the DHCP pool supports the overall number of clients) so that none of the clients lose their leases. Another solution would be to use static mappings for the clients that require a "static" IP, which is more effort in my case due to some home automation integration. -
@cybis
Just keep in mind that Captive Portal keeps track of authentication by MAC address but requires the same IP as the MAC had at the time of authentication to work/reconnect. If you are using static mappings, one has to question the need for a captive portal at all.The solution in https://redmine.pfsense.org/issues/15904 might be more viable. You simply use the index.php (for 2.8.1 it is INDEX-2411-DEC17.PHP) and RFC8910.php files attached to that redmine. They typically go into /usr/local/captiveportal. They check if the IP has changed from the CP database copy and update the database, keeping the old MAC and changing the IP to the static string "OFFLINE". If you have multiple portals and want to know which one the IP was originally authenticated on, the code changes below will list the cpzone as well so you can easily see the status by CP zone on the Webconfigurator captive portal page. Always make a backup of the original files first please.
The code changes for this are:
Comparing files index-281S-mod.php and INDEX-2411-DEC17.PHP
***** index-281S-mod.php
$updt_field = 'ip';
$new_value_tmp = "NOIP-" . $cpzone;
$new_value = "'{$new_value_tmp}'";
***** INDEX-2411-DEC17.PHP
$updt_field = 'ip';
$new_value_tmp = "OFFLINE";
$new_value = "'{$new_value_tmp}'";
***** index-281S-mod.php
$updt_field = "ip";
$unassignip = "NOIP-" . $cpzone;
$new_value = "'{$unassignip}'";
***** INDEX-2411-DEC17.PHP
$updt_field = "ip";
$unassignip = 'OFFLINE';
$new_value = "'{$unassignip}'";
You will only notice a small increase in load if only one changes at a time but on a reboot where they reconnect randomly and overwrite each other's prior IP, your cpu will bog down as it has to reindex CP for each change. It is all over quickly after a reboot and just keeps purring along. Leases that haven't yet expired on the restart do not have to be changed so if the power down is brief, there will only be a few that change right away.
This code will also let you switch between ISC and Kea without having to disconnect any users first as it just sorts the new IPs out.
It also lets you set the timeout value for the voucher or user account to a value longer than the DHCP lease, drastically reducing or even eliminating the need to log in more than once per CP authentication. CP will expire the user independent of the value of the IP because it uses the MAC to do that.
-
@EDaleH said in KEA DHCP lease allocation and reclamation:
@cybis
Just keep in mind that Captive Portal keeps track of authentication by MAC address but requires the same IP as the MAC had at the time of authentication to work/reconnect. If you are using static mappings, one has to question the need for a captive portal at all.Thanks again for your inputs. I don't use captive portals, I'm just interested in getting
Keato behave as close as possible toISCin terms of DHCP lease allocation and reclamation. -
@cybis The referenced index.php and rfc8910.php only apply to captive portal so they won't help.
It will be a while before the lease affinity issue is fixed in Kea and they likely have to fix it before pfSense adopts it. Even then, it will only be in the most recent release of pfSense so if you want to run CE, be prepared for a long delay. The longer you keep Kea running without a restart, the closer you are to a solution. Every Kea restart is a do over for IP allocation. You could also ensure your clients keep their leases active as in the static lease suggestion or long lease times that will survive the reboot but again, if they do ever timeout after a reboot, they have no affinity protection any more, even weeks later.
