[Kea-users] HA with TLS
Stefan G. Weichinger
lists at xunil.at
Thu Oct 22 11:08:23 UTC 2026
Today we noticed a failing HA which might hav been failing for a while
already.
I noticed expired certs on the 2 nodes and substituted them with valid
certs (I use the certs and the CA from the Samba-AD-DC daemons that also
run on these two servers).
I also noticed an upgrade to 2.6.0 available, but decided to only go to
kea-2.4.2 to keep the number of moving parts as low as possible.
I couldn't get TLS working, always SSL cert errors etc
* the examples in the docs show IP adresses in the URL parameter. Do I
need to use FQDNs matching the TLS-Certs there?
* unsure about "cert-required": where to place it, if I want to allow
lower security here?
* So far I had control-socket on localhost only, I don't understand if
that was OK or not for HA ...
below parts of the config, currently with TLS disabled.
Could someone point me at what to really look at?
I had thought I had HA over TLS working, but right now I messed it up
somehow.
Thanks in advance!
Ah, I should add:
the 2 nodes:
adc1 10.0.0.231
adc2 10.0.0.230
("wrong" order, somehow misleading, I know)
# cat kea-dhcp4.conf
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eno1" ],
"dhcp-socket-type": "raw",
"service-sockets-require-all": false,
"service-sockets-max-retries": 1000,
"service-sockets-retry-wait-time": 10000
},
"control-sockets": [
# {
# "socket-type": "unix",
# "socket-name": "/var/run/kea/kea4-ctrl-socket"
# },
{
"socket-type": "https",
"socket-address": "10.0.0.231",
"socket-port": 8000,
"trust-anchor": "/etc/kea/ca.crt",
"cert-file": "/etc/kea/server_adc1.crt",
"key-file": "/etc/kea/server_adc1.key",
"cert-required": false
}
],
"sanity-checks": {
"lease-checks": "fix-del"
},
// Global timers specified here apply to all subnets, unless there are
// subnet specific values defined in particular subnets.
// "renew-timer": 900,
// "rebind-timer": 1800,
"min-valid-lifetime": 3600,
"valid-lifetime": 43200,
"max-valid-lifetime": 604800,
# Specify the type of lease database
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases",
"lfc-interval": 3600
},
// Kea will clean up its database of expired leases once per hour.
However, it
// will keep the leases in expired state for 2 days. This greatly
increases the
// chances for returning devices to get the same address again. To
guarantee that,
// use host reservation.
"expired-leases-processing": {
"reclaim-timer-wait-time": 3600,
"hold-reclaimed-time": 172800,
"max-reclaim-leases": 0,
"max-reclaim-time": 0
},
// HA requires two hooks libraries to be loaded:
libdhcp_lease_cmds.so and
// libdhcp_ha.so. The former handles incoming lease updates from
the HA peers.
// The latter implements high availability feature for Kea. Note
the library name
// should be the same, but the path is OS specific.
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so"
},
// The lease_cmds library must be loaded because HA makes use of it to
// deliver lease updates to the server as well as synchronize the
// lease database after failure.
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
},
{
// The HA hooks library should be loaded.
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
// Each server should have the same HA configuration,
except for the
// "this-server-name" parameter.
"high-availability": [ {
// This parameter points to this server instance.
The respective
// HA peers must have this parameter set to their
own names.
"this-server-name": "adc1",
// "trust-anchor": "/etc/kea/ca.crt",
// "cert-file": "/etc/kea/server_adc1.crt",
// "key-file": "/etc/kea/server_adc1.key",
// The HA mode is set to hot-standby. In this mode,
the active server handles
// all the traffic. The standby takes over if the
primary becomes unavailable.
"mode": "hot-standby",
// Heartbeat is to be sent every 10 seconds if no
other control
// commands are transmitted.
"heartbeat-delay": 10000,
// Maximum time for partner's response to a
heartbeat, after which
// failure detection is started. This is specified
in milliseconds.
// If we don't hear from the partner in 60 seconds,
it's time to
// start worrying.
"max-response-delay": 60000,
// The following parameters control how the server
detects the
// partner's failure. The ACK delay sets the
threshold for the
// 'secs' field of the received discovers. This is
specified in
// milliseconds.
"max-ack-delay": 5000,
// This specifies the number of clients which send
messages to
// the partner but appear to not receive any response.
"max-unacked-clients": 5,
// This specifies the maximum timeout (in
milliseconds) for the server
// to complete sync. If you have a large deployment
(high tens or
// hundreds of thousands of clients), you may need
to increase it
// further. The default value is 60000ms (60 seconds).
"sync-timeout": 60000,
"peers": [
// This is the configuration of this server
instance.
{
"name": "adc2",
// This specifies the URL of our server
instance. The
// Control Agent must run along with our
DHCPv4 server
// instance and the "http-host" and
"http-port" must be
// set to the corresponding values.
// "url": "http://adc2.arbeitsgruppe.ikw-amstetten.at:8005/",
"url": "http://10.0.0.230:8005/",
"basic-auth-user": "admin",
"basic-auth-password": "X-dEldmfRz",
// This server is primary. The other one
must be
// secondary.
"role": "primary"
},
// This is the configuration of our HA peer.
{
"name": "adc1",
// Specifies the URL on which the partner's
control
// channel can be reached. The Control
Agent is required
// to run on the partner's machine with
"http-host" and
// "http-port" values set to the
corresponding values.
"url": "http://10.0.0.231:8005/",
"basic-auth-user": "admin",
"basic-auth-password": "X-dEldmfRz",
// The partner is a secondary. Our is primary.
"role": "standby"
}
]
} ]
}
}
],
# cat kea-dhcp4.conf
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eno1" ],
"dhcp-socket-type": "raw",
"service-sockets-require-all": false,
"service-sockets-max-retries": 1000,
"service-sockets-retry-wait-time": 10000
},
"control-sockets": [
{
"socket-type": "https",
"socket-address": "10.0.0.231",
"socket-port": 8000,
"trust-anchor": "/etc/kea/ca.crt",
"cert-file": "/etc/kea/server_adc1.crt",
"key-file": "/etc/kea/server_adc1.key",
"cert-required": false
}
],
"sanity-checks": {
"lease-checks": "fix-del"
},
[..]
// HA requires two hooks libraries to be loaded:
libdhcp_lease_cmds.so and
// libdhcp_ha.so. The former handles incoming lease updates from
the HA peers.
// The latter implements high availability feature for Kea. Note
the library name
// should be the same, but the path is OS specific.
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so"
},
// The lease_cmds library must be loaded because HA makes use of it to
// deliver lease updates to the server as well as synchronize the
// lease database after failure.
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
},
{
// The HA hooks library should be loaded.
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
// Each server should have the same HA configuration,
except for the
// "this-server-name" parameter.
"high-availability": [ {
// This parameter points to this server instance.
The respective
// HA peers must have this parameter set to their
own names.
"this-server-name": "adc1",
// "trust-anchor": "/etc/kea/ca.crt",
// "cert-file": "/etc/kea/server_adc1.crt",
// "key-file": "/etc/kea/server_adc1.key",
// The HA mode is set to hot-standby. In this mode,
the active server handles
// all the traffic. The standby takes over if the
primary becomes unavailable.
"mode": "hot-standby",
// Heartbeat is to be sent every 10 seconds if no
other control
// commands are transmitted.
"heartbeat-delay": 10000,
// Maximum time for partner's response to a
heartbeat, after which
// failure detection is started. This is specified
in milliseconds.
// If we don't hear from the partner in 60 seconds,
it's time to
// start worrying.
"max-response-delay": 60000,
// The following parameters control how the server
detects the
// partner's failure. The ACK delay sets the
threshold for the
// 'secs' field of the received discovers. This is
specified in
// milliseconds.
"max-ack-delay": 5000,
// This specifies the number of clients which send
messages to
// the partner but appear to not receive any response.
"max-unacked-clients": 5,
// This specifies the maximum timeout (in
milliseconds) for the server
// to complete sync. If you have a large deployment
(high tens or
// hundreds of thousands of clients), you may need
to increase it
// further. The default value is 60000ms (60 seconds).
"sync-timeout": 60000,
"peers": [
// This is the configuration of this server
instance.
{
"name": "adc2",
// This specifies the URL of our server
instance. The
// Control Agent must run along with our
DHCPv4 server
// instance and the "http-host" and
"http-port" must be
// set to the corresponding values.
// "url": "http://adc2.arbeitsgruppe.ikw-amstetten.at:8005/",
"url": "http://10.0.0.230:8005/",
"basic-auth-user": "admin",
"basic-auth-password": "X-dEldmfRz",
// This server is primary. The other one
must be
// secondary.
"role": "primary"
},
// This is the configuration of our HA peer.
{
"name": "adc1",
// Specifies the URL on which the partner's
control
// channel can be reached. The Control
Agent is required
// to run on the partner's machine with
"http-host" and
// "http-port" values set to the
corresponding values.
"url": "http://10.0.0.231:8005/",
"basic-auth-user": "admin",
"basic-auth-password": "X-dEldmfRz",
// The partner is a secondary. Our is primary.
"role": "standby"
}
]
} ]
}
}
],
More information about the Kea-users
mailing list