[Kea-users] max-unacked-clients definition

Thu Jun 22 14:55:29 UTC 2023

On Thu, Jun 22, 2023, at 10:42, Kraishak Mahtha wrote:
> I thought if the client sends a request and the server is unable to grant a lease then it can consider an unacked client but here when the client is sending the request to the stand-by server then we are seeing in the log as 
> 
> 2023-06-22 13:36:50.943 DEBUG [kea-dhcp4.ha-hooks/17707.140342512834304] HA_BUFFER4_RECEIVE_NOT_FOR_US [hwtype=1 08:6a:c5:82:de:a8], cid=[01:08:6a:c5:82:de:a8], tid=0xaaba6094: dropping query to be processed by another server
> 
> and is not considered as un-ackedclient, so back to square when can we consider a client request as unacked ?

>From the Kea ARM:

`max-ack-delay` - is one of the parameters controlling partner failure-detection. When communication with the partner is interrupted, the server examines the values of the “secs” field (DHCPv4) or “elapsed time” option (DHCPv6), which denote how long the DHCP client has been trying to communicate with the DHCP server. This parameter specifies the maximum time in milliseconds for the client to try to communicate with the DHCP server, after which this server assumes that the client failed to communicate with the DHCP server (is unacknowledged or “unacked”). The default value of this parameter is 10000.

So in your case, with max-ack-delay set to 10000, a client will need to retransmit DISCOVER packets (increasing the "secs" field in the packet each time). When the standby server sees a DISCOVER with "secs" higher than 10000, for a client that is supposed to be handled by the peer server, it will consider that client 'unacked' and increase the unacked-client count.

If the clients do not increase the "secs" field when re-transmitting their DISCOVER packets, the HA logic will never consider them 'unacked'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230622/27c7d313/attachment-0001.htm>