[Kea-users] max-unacked-clients definition

[Kraishak Mahtha]

Hi Frey,

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
--->Thus I doubt why the client is not being considered as an unacked client
The other possibility may be that both clients have not exceeded
max-ack-delay of 10 seconds at the same time.
---> Sorry I didn't get this. Does the client need to be exceeded at the
same time, as both are different clients it could be different right?
But again I totally stopped the kea-service on the primary and waited for
almost 40 minutes and we have been trying from that instant trying
restarting laptops and enabling and disabling all adapters, but nothing
seems to work. and in traffic also we can see that many of the discover
packets have crossed the time lapse of 10 seconds (yes even though it is
two mac address in the current give packet capture) but it did cross the 10
seconds


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
---> Can we handle this in any other way because this vendor class-id of
MSFT is getting by default, we didn't configure any vendor class manually
for the devices.

And also one last question, is it suggested to go with
un-acked-clients value as zero both in hot-stand-by mode and load balance
mode?

Thanks
Kraishak

On Fri, Jun 23, 2023 at 8:52 AM Frey, Rick E via Kea-users <
kea-users at lists.isc.org> wrote:

> 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.
>
>
> --
> 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/20230623/5b041bdb/attachment.htm>