[Kea-users] Dropping the packets in load balancing

[Kraishak Mahtha]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230510/2a89937f/attachment.htm>