[Kea-users] max-unacked-clients definition

[Frey, Rick E]

Apologies, I listed incorrect state of server to begin counting unack'd clients (should have said communication-interrupted instead of partner-down) and I missed first part of thread where Kraishak listed that state of server was indeed communication-interrupted and had counted 1 unack'd client.

Earlier in thread, Kraishak's config listed max-unacked-clients = 2.  If I understand correctly, the standby host would need to exceed 2 unacked clients before transitioning to partner-down.  This seems to bear out with earlier status output of "unacked-clients = 1" and "unacked-clients-left = 2" (where total unacked clients must be 3 to exceed configured max-unacked-clients).  If I'm caught up correctly, question remains why additional requests were not counted as unacked.

In looking at earlier packet capture, I only see two MAC addresses with DHCP requests:
34:98:b5:dc:1f:99
08:6a:c5:82:de:a8
If the server is only seeing request from two clients, the configured "max-unacked-clients" setting of "2" will never be exceeded.

There is also some question as to why Kraishak is only seeing status of 1 "unacked-clients" even when there are requests from two clients that exceed 10 seconds.   The packet capture shows requests from 08:6a:c5:82:de:a8 using little endian encoding for seconds elapsed.  I believe this is bad behavior of Windows clients (packet has Vendor class ID of MSFT 5.0).  Wondering if the bad encoding of seconds field may be tripping Kea up.   The other possibility may be that both clients have not exceeded max-ack-delay of 10 seconds at the same time.




________________________________
From: Kea-users <kea-users-bounces at lists.isc.org> on behalf of Kevin P. Fleming <lists.kea-users at kevin.km6g.us>
Sent: Thursday, June 22, 2023 2:58 PM
Cc: kea-users at lists.isc.org <kea-users at lists.isc.org>
Subject: Re: [Kea-users] max-unacked-clients definition

On Thu, Jun 22, 2023, at 13:58, Frey, Rick E wrote:

The server needs to see its partner down before it will consider requests as un-acked and begin responding such requests.  If your standby server does not see the other server as partner-down, the requests are not tracked as un-acked even though they are not being processed by the primary server.  If you are testing failover, you'll need to disrupt communication between servers so standby host sees primary as partner-down.  See previous thread<https://lists.isc.org/mailman/htdig/kea-users/2023-January/003794.html> on this topic.

This does not match the documentation. In the ARM it says that if max-unacked-clients is non-zero, then the server must notice at least that many unacked clients before it will transition its peer to the partner-down state. Disrupting communications is not sufficient to force that transition unless max-unacked-clients is set to zero.

For the OP's configuration, using hot-standby, I'd probably just set max-unacked-clients to zero. This should be safe as long as the Kea servers are communicating with each other over the same path as the clients are communicating with them. The ARM explicitly suggests this too.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230623/274f95b2/attachment.htm>