The Single Point of Failure Problem
Monday morning, 9:00 AM. Your helpdesk phone starts ringing off the hook because the Wi-Fi is “down.” After twenty minutes of frantic troubleshooting, you find the real culprit: the DHCP server service crashed. Without it, your network is just a collection of disconnected devices waiting for an IP address that never comes.
I have seen entire office buildings grind to a halt because of a single corrupted lease file. Relying on one DHCP server is a massive risk. To fix this, we use High Availability (HA). This guide walks through setting up Kea DHCP—the modern, modular successor to the legacy ISC DHCP—to ensure your network stays alive even if a server goes offline unexpectedly.
How Kea DHCP HA Actually Works
Unlike older systems that relied on complex heartbeat protocols, Kea uses a specialized hook library called libdhcp_ha.so. This allows different Kea instances to synchronize their lease databases in near real-time over a REST API.
You generally choose between two operational modes:
- Load Balancing: Both servers stay active. They split the client requests (e.g., Server A handles 50%, Server B handles 50%). If one fails, the survivor immediately absorbs 100% of the traffic.
- Hot Standby: A Primary server does all the heavy lifting while a Secondary server watches. The Secondary only takes over if the Primary stops responding.
We will implement Load Balancing in this tutorial. It is the most efficient way to ensure both servers are healthy and capable of handling your network’s peak demand.
The Role of the Control Agent
Kea instances don’t talk to each other directly through the DHCP service. Instead, they use the kea-ctrl-agent. This sidecar service listens for commands via HTTP. For HA to function, Server A must be able to reach Server B’s Control Agent on port 8000, and vice versa. If your firewall blocks this, your HA pair will never sync.
Prerequisites
You will need two Linux instances. Ubuntu 22.04 or Debian 12 are the most common choices for this setup. In our example, we use these IPs:
- Server 1 (Primary): 192.168.1.10
- Server 2 (Secondary): 192.168.1.11
Static IP addresses are mandatory. Ensure the servers can ping each other before proceeding.
Step 1: Install Kea DHCP
Install the DHCP server and the Control Agent on both machines. While many distros include Kea in their default repos, I recommend using the official ISC repositories for the latest security patches.
sudo apt update
sudo apt install kea-dhcp4-server kea-ctrl-agent -yImmediately stop the services. It is easier to configure them while they aren’t trying to manage active leases.
sudo systemctl stop kea-dhcp4-server kea-ctrl-agentStep 2: Configure the Control Agent
The Control Agent is the bridge between your two nodes. Edit /etc/kea/kea-ctrl-agent.conf on both servers. You must change the http-host from 127.0.0.1 to 0.0.0.0 so it can receive requests from its partner.
{
"Control-agent": {
"http-host": "0.0.0.0",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
}
},
"loggers": [
{
"name": "kea-ctrl-agent",
"output_options": [
{ "output": "/var/log/kea-ctrl-agent.log" }
],
"severity": "INFO"
}
]
}
}Restart the agent on both nodes to apply the changes:
sudo systemctl start kea-ctrl-agentStep 3: Setting up the HA Hook on Server 1
Open /etc/kea/kea-dhcp4.conf on the first server. We need to tell Kea to load the HA library and define who its partner is. In this example, we are managing a 192.168.1.0/24 subnet with a pool of 101 addresses.
{
"Dhcp4": {
"interfaces-config": { "interfaces": [ "eth0" ] },
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "server1",
"mode": "load-balancing",
"heartbeat-delay": 1000,
"max-response-delay": 2000,
"peers": [
{
"name": "server1",
"url": "http://192.168.1.10:8000/",
"role": "primary"
},
{
"name": "server2",
"url": "http://192.168.1.11:8000/",
"role": "secondary"
}
]
}]
}
}
],
"subnet4": [
{
"id": 1,
"subnet": "192.168.1.0/24",
"pools": [ { "pool": "192.168.1.100 - 192.168.1.200" } ],
"option-data": [
{ "name": "routers", "data": "192.168.1.1" },
{ "name": "domain-name-servers", "data": "8.8.8.8, 8.8.4.4" }
]
}
]
}
}Step 4: Syncing Server 2
Copy the configuration to Server 2, but pay close attention to the this-server-name field. This is the only line that must change. If you leave it as “server1” on the second machine, the HA sync will fail immediately.
On Server 2, update /etc/kea/kea-dhcp4.conf:
"high-availability": [{
"this-server-name": "server2",
"mode": "load-balancing",
...
}]Keep the peers list and subnet4 settings identical across both nodes. Kea uses these to verify that both servers are trying to manage the same network.
Step 5: Verification and Failover Testing
Fire up the DHCP service on both machines:
sudo systemctl start kea-dhcp4-serverMonitor the logs to confirm the handshake was successful. You are looking for a transition to the “load-balancing” state.
journalctl -u kea-dhcp4-server -fIf you see “communication-interrupted,” double-check that port 8000 is open in your firewall. You can test this quickly with curl http://192.168.1.10:8000.
The “Pull the Plug” Test
To verify the redundancy, stop the service on Server 1. Within two seconds (the max-response-delay we set), Server 2 will detect the silence. It will log a state change and begin responding to all DHCP Discover packets. Once you restart Server 1, the two nodes will perform a “bulk lease update” to sync any new IPs assigned during the downtime.
Final Thoughts
Configuring Kea DHCP HA is one of the most effective ways to harden your infrastructure. By moving away from a single-server setup, you eliminate a common bottleneck and a dangerous failure point. While we used a simple file-based database here, larger environments with thousands of clients should consider a shared MySQL or PostgreSQL backend for even better scalability.
