[Kea-users] **SPAM** Re: Load-Balancing Network issue between Relay and Kea

[Mathias Aichinger]

>> Surely, if you misconfigure a relay agent in that way, around half your 
>> clients will initially be unable to renew their leases, but eventually 
>> will get serviced by the available server once their active lease has 
>> expired ? That would mean the clients would drop their network config 
>> momentarily before setting up a new one - meaning that active 
>> connections would drop, but new ones would connect just fine once the 
>> new settings are in place.
That's exactly how it tested it. I removed one relay and even the DISCOVER got dropped. I have checked the code and instead of some round robin, it's using a hashed hwaddress (or client id) and modulo function to always select the same server. If this server is not reachable, the customer has bad luck.

> In my network with Kea in load-balancing mode, there seems to be some sort of algorithm involved even for DHCP DISCOVER, where only one of the two servers responds with DHCP OFFER even though they are both running in a normal state. It has been my assumption (untested) up to this point that Kea is using the client's identifier (MAC address, DUID, etc.) to choose one or the other of the active servers to respond to that DISCOVER. If that's true, and both servers are in normal operation (neither is in partner-down), then that algorithm would continue telling the second server to *not* respond to requests from that client because it believes the other server will do so... even if the other server is not receiving the client's requests.
That's the case.

> To summarize, that's what I assumed (against untested) 'max-unacked-clients' is for; if the second server assumes the first server will respond to those clients, but it does not (no leases are offered to them), it could notice the situation and decide that the first server is unhealthy or partitioned and force it into a 'down' state.
I also assumed that.

> So it would seem that an alternative to a load balancer is to script detection of the problem and handle it according to the automation level desired by the admin - at one extreme, simply alert it so manual intervention can be done; at the other extreme, automatically put a server into partner-down state.
That would be my Plan-B.