<div dir="ltr">Hi Kevin, <div>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,</div><div><br></div><div>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.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 22, 2023 at 8:26 PM Kevin P. Fleming <<a href="mailto:lists.kea-users@kevin.km6g.us">lists.kea-users@kevin.km6g.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6637870461311146424"><u></u><div><div>On Thu, Jun 22, 2023, at 10:42, Kraishak Mahtha wrote:<br></div><blockquote type="cite" id="m_-6637870461311146424qt"><div dir="ltr"><div>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 <br></div><div><div><br></div><div>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<br></div><div><br></div><div>and is not considered as un-ackedclient, so back to square when can we consider a client request as unacked ?<br></div></div></div></blockquote><div><br></div><div><div>From the Kea ARM:<br></div><div><br></div><code class="gmail-notranslate"><span>max-ack-delay</span></code> - 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.<br><br>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.<br><br>If the clients do not increase the "secs" field when re-transmitting their DISCOVER packets, the HA logic will never consider them 'unacked'.<br></div><div><br></div></div>-- <br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
To unsubscribe visit <a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/kea-users</a>.<br>
<br>
Kea-users mailing list<br>
<a href="mailto:Kea-users@lists.isc.org" target="_blank">Kea-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/kea-users</a><br>
</div></blockquote></div>