Hello Marcin, I've set "max-unacked-clients" to 0 as you told me, and it works flawlessly. Thanks!
With regards Alex Le lun. 9 oct. 2023 à 13:52, Marcin Siodelski <mar...@isc.org> a écrit : > > Hello Alex, > > Your configuration includes `max-unacked-clients` parameter set to 5. It > means that when the communication between the two servers is interrupted > the surviving server starts checking if the other server responds to the > DHCP queries. It assumes that the other server doesn't respond to the > queries when the `secs` field value the clients set in the discover or > rebind messages exceed the value of `max-ack-delay` (5 seconds in your > case). It must find at least 5 distinct clients retransmitting with > bumped `secs` field value before it may assume that the partner is dead > and take over. > > This process can take a while depending on the lease lifetime (rebind > time), number of new or rebinding clients etc. > > You can read more about the parameters controlling the failover process > in the Kea ARM: > > https://kea.readthedocs.io/en/kea-2.4.0/arm/hooks.html#load-balancing-configuration > > In your failover scenario, please make sure that after the communication > failure the clients properly set the `secs` field value upon > retransmissions. If you want to bypass this mechanism, you can set the > `max-unacked-clients` to 0. > > Marcin Siodelski > Senior Software Engineer > ISC > > On 9.10.2023 19:37, Alexandre Lessard wrote: > > Hello everyone, > > > > I'm new here! I'm working for an ISP as a network administrator. > > Furthermore, I got about 7 years of experience doing all sort of IT > > stuff for this company. I've been using and configuring Kea DHCP for > > about 2 weeks now. Prior to that, I was using ISC DHCP, but since it's > > now deprecated, I'm preparing two new servers to migrate all customers > > on them. > > > > The setup: > > The setup is DHCP relay with two Kea servers in HA hot-standby. There > > is three particularity that I want to mention right now. > > > > First, because I couldn't find an out-of-the-box solution, I made a > > script that replicate the configuration through the API on both server > > when they are restarted. I don't think it interferes with the service > > as it is run prior to the service startup, but I don't want to > > overlook it either. > > > > Second, they both have an IP configured on their loop back interface > > to be use kind of like an any cast address. That being said, I don't > > use them for the HA, it's only used by the Relay agents. > > > > Third, they are Proxmox containers. I don't think it's problematic but > > tell me if I'm wrong, I will make VMs for them. > > > > My problem: > > When I simulated an outage by stopping the server1, only 2 (test2 and > > test3) of the 4 subnets recover eventually. Even if they recover, it > > takes about 5 minutes. As much as I understand, it's supposed to be > > configured at 1 minute. The two other subnets never recovers. > > Why some subnets never recover? > > Why the 2 that recover take so long? > > > > I observed that the state of server2 stays to "hot-standby" even if > > the remote communication is interrupted. > > > > I have been working on fixing that for more than 10 hours now. > > Likewise, I really don't know what to look for anymore. > > > > The config: > > The Control Agents have almost default configuration, except for the > > http-host that is set to the IP interface that receive the request > > (eth0). > > > > The Dhcp6 server is disabled. > > > > Has for the Dhcp4 config, it has been saved through the API, so it is > > massive! All default configs have been written in the config file. For > > this reason, I won't post it here if not required to avoid sending a > > wall of config. I've put it on a public repository of GitHub: > > https://github.com/AlexTargo/Kea-Dhcp > > > > If I'm missing anything, let me know, and I'll share it as soon as possible. > > > > I hope someone have good pointers for me. > > > > Regards > > Alex > -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
