[Kea-users] Dropping the packets in load balancing

[Darren Ankney]

Hi Kraishak,

While you are in the testing phase, you may want to consider adding
the kea-dhcp4.ha-hooks logger at debug level which will give you a lot
of detail about what is going on:

"loggers": [
        {
            "name": "kea-dhcp4.ha-hooks",
            "output_options": [
                {
                    "output": "/var/log/kea-dhcp4-ha-hooks.log"
                }
            ],
            "severity": "DEBUG",
            "debuglevel": 99
        }
]


On Wed, May 10, 2023 at 11:27 AM Kraishak Mahtha <kraishak.edu at gmail.com> wrote:
>
> Hi Peter,
>
> I am using a kea-HA in load balancing but before I deploy it in my production environment, I am testing all the cases in my local lab to understand the flow of kea-dhcp.
>
> Initially, I send the discover packets to both the primary and failover and it worked fine, later I tried the following cases:
> Case 1) Primary and failover are live but somehow failover server is not granting the leases or packets not reaching to failover
>
> --> At this point logically the primary has to handle all the requests but when I test few of the client packets got dropped as part of the explanation you suggested that based on the hash value it will decide and they get dropped, so I decided to test a case where my kea-servers are in load balancing and because of some reason if the failover box is down.
>
> Case 2) Primary and failover in load balance but failover server is down(Network issue or Power failure for that failover box some unexpected cases) ----->This is a general valid use case
> In order to achieve this case I manually stopped the kea-dhcp service on the failover box which is equivalent to my case and now I want to see what happens for all the requests
>  --> Logically now all the requests are to be handled by the primary till the failover comes up, so now I send the requests to the primary server but still the packets get dropped so while I am debugging I found that the failover state is in communication-recovery state --(output of status-get command), for the primary to take the full control it has to be in partner down state, so I am waiting for the status to get an update as partner down.
>
> To get into partner downstate here we have two deciding parameters as per my config (to my understanding please correct me if I am wrong)
> i)max-response-delay: 60000 milliseconds-> After the completion of this duration it has to be set it to partner-down automatically, so even after this duration I still see the state as a communication-recovery state.
> ii)max-unacked-clients: 13 --> After this count the primary has to set into partner -down, I found that this param value can be seen from the status-get command and while I am testing I can see that at one point it reached 14 and in my config, it is 13 but still the state is in the communication-recovery state so why did the primary didn't change its state to partner down?
> if my understanding of the above parameters is wrong correct me
>
> Now I have the following questions:
> 1)Doesn't primary grant a lease to a client whose hash value says that it has to grant by failover even if the DISCOVER packet has max-ack-delay greater than the value specified in the config?
> --> Generally in ISC DHCP apart from hash value calculation the server checks the Load Balance Max Secs parameter in the client discover packet and if the value exceeds the given value in the config, even if the hash value says that the lease has to be granted by failover the primary assumes that failover box might have some issue while granting so let me grant a lease... So do we have a similar concept in kea? If so, what is the equivalent parameter of Load Balance Max Secs in kea?
>
> 2) When doesn't the primary server change its state to partner-down automatically in my case? Do we have any other deciding factor to get it changed?
>
> Thanks
> Kraishak
>
>
> On Wed, May 10, 2023 at 7:35 PM Peter Davies <peterd at isc.org> wrote:
>>
>> Hi Kraishak,
>>     Why would you want to stop the secondary HA server? What
>> are you trying to achieve?
>>
>> In answer to your questions:
>> 1/2) When a HA server loses its connection to its partner, it starts a "failure
>> detection" process. When the value of max-unacked-clients is not "0", the server
>> uses the values of the "max-ack-delay" and "max-unacked-clients" to discover if
>> it should take over processing its partner's clients' requests.
>> Your settings are:
>>    "max-ack-delay": 10000,
>>    "max-unacked-clients": 13
>>
>> This means that after communication has been interrupted for "max-response-delay"
>> (10000 milisecs), the primary will start the "failure detections" process. The
>> process will wait until it has "seen" 13 DHCP packets that have a "secs" field
>> with a value of 10000 or greater before starting to process the partners' client
>> requests.
>>
>> see: https://kea.readthedocs.io/en/kea-2.3.7/arm/hooks.html#load-balancing-configuration
>>
>> 3) There are commands to manipulate the state the servers are in. See the "host-
>> ha-maintenance" commands at:
>> https://kea.readthedocs.io/en/kea-2.3.7/arm/hooks.html#control-commands-for-high-availability
>>
>> But why would you want to do this? Supposing you want all client requests to be processed by
>> one server and have the secondary active only when the primary is unavailable. In that case,
>> you should consider using the "hot-standby" HA configuration.
>>
>> Kind Regards Peter
>
> --
> 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