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....@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 <pet...@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
--
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
