---
title: "Kea HA timer settings"
slug: "kea-ha-timer-settings"
description: "Kea High Availability server pairs continuously exchange heartbeat messages. There are two tuning parameters."
tags: ["high availability", "dhcp failover", "heartbeat", "ha timers", "failover", "open source", "dhcp timers", "kea dhcp", "ha"]
updated: 2020-10-20T18:53:51Z
published: 2020-10-20T18:53:51Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Kea HA timer settings

Kea HA timer settings coordination

Kea High Availability server pairs continuously exchange heartbeat messages to learn the status of the partner and to verify it is operational.  There are two tuning parameters that must be coordinated. 

:::(Info) (Summary)
The ```max-response-delay``` parameter should be configured as a multiple of the ```heartbeat-delay``` 
:::

### Setting the Heartbeat Interval
The ```heartbeat-delay``` parameter indicates a length in milliseconds between sending the last heartbeat (or any other command to the partner) and the next heartbeat.  The default value of this parameter is 10000 ms.

### Detecting a Communication Failure
The ```max-response-delay``` parameter specifies a duration in milliseconds since the last effective correspondence with the partner, after which the server assumes that communication with the partner has been interrupted.  The default value of this parameter is 60000 ms, which is equal to 6 heartbeats at the default delay ```heartbeat-delay``` setting.

#### What happens when both settings have the same value?
The propagation time taken in sending and receiving heartbeats has the effect of adding a small amount of time to the value of the heart-beat delay. Therefore when ```max-response-delay``` is configured at the same value as the ```heartbeat-delay``` a small window of time opens when a secondary Kea server may enter the **communication interrupted** state.

This of course would be a false-positive error, because the secondary Kea server is not actually experiencing a communication failure. This may cause spurious warning messages on the secondary caused by dhcp clients that do not receive an offer or do not accept an offered lease.  The solution is to configure the timers so that the ```max-response-delay``` is a multiple of the ```heartbeat-delay```.