[Kea-users] max-unacked-clients definition

Kraishak Mahtha kraishak.edu at gmail.com
Thu Jun 22 15:52:20 UTC 2023


Hi Kevin,
Thanks for the explanation. But in a few trials, the clients crossed more
than 10 seconds  but still, I don't see a change and getting an
acknowledgment or server getting updated partner-down,

I am attaching one of the tcpdump packets captured that I have saved. Can
you please have a look? I am checking for the "Seconds elapsed" field in
the DISCOVER packet. I hope that is correct, and correct me if I am wrong.



On Thu, Jun 22, 2023 at 8:26 PM Kevin P. Fleming <
lists.kea-users at kevin.km6g.us> wrote:

> 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'.
>
> --
> 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.
>
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230622/f0a26412/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pcap
Type: application/octet-stream
Size: 179648 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230622/f0a26412/attachment-0001.obj>


More information about the Kea-users mailing list