>> 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. -- 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 [email protected] https://lists.isc.org/mailman/listinfo/kea-users
