can you add “interface”: “br0” to each of your subnets?
set logging to DEBUG and level 99
you can overwrite logging temporarily by passing
KEA_LOGGER_SEVERITY="DEBUG" KEA_LOGGER_DBGLEVEL=99
KEA_LOGGER_DESTINATION="stdout"
before ./kea-dhcp4 -c …
------------------------------------------------------------------------
*From: *Stuart <[email protected]>
*To: *Kea <[email protected]>; Razvan <[email protected]>
*Date: *Saturday, 21 February 2026 12:35 PM EET
*Subject: *Re: [Kea-users] Kea DHCP4 not working on newly
configured bridged network
Razvan,
The secondary kea server is on a completely seperate computer. My
home network infrastructure consists of on decent (ish) server and
several, old, second hand computers I bought cheap. One of these
runs the secondary server. It binds to the standard ethernet port
of that machine and then services the network via the router. As I
said the main server is connected to the router through br0. It
connects to the internet and to other computers on the network
(e.g. it shares files via samba). It even contacts the secondary
dhcp server to ask it to turn off when I restart kea-dhcp4-server.
It then just doesn't offer leases. The VMs connect to the router
via the Bridged Network and then receive dhcp DORA from the
secondary server via the router, so long as the main server is off
and failover is complete.
There are no files at all in /var/log/kea. There is also no fles
called kea-dhcp4.log in /var/log, where the config file indicates
it should be. I think my logging parameters are screwed up,
perhaps I need to change the debug level or severity, perhaps
there is a stupid typo.
Regards
Stuart MacGregor
On 21/2/26 20:10, Razvan Becheriu wrote:
Hi,
How is it that the vms acquire ip using secondary server? does
the secondary bind on the same interface at the same time?
Logs should be under /kea/install/path/var/log/kea
I think that only one of your servers successfully binds to
the interface and because the server uses reuse port/address
the secondary if starts second will receive traffic.
------------------------------------------------------------------------
*From: *Stuart <[email protected]>
<mailto:[email protected]>
*To: *kea-users <[email protected]>
<mailto:[email protected]>
*Date: *Saturday, 21 February 2026 3:31 AM EET
*Subject: *[Kea-users] Kea DHCP4 not working on newly
configured bridged network
Good Morning,
I am running Ubuntu 24.04, Kea 2.4.1. I have been using
Kea without major issues for a year or two, isc-dhcp for a
couple of years prior. During recent kernel updates I
decided I was sick of Virtualbox compatibility issues, so
I created a bridged network so that I could move my vms
(Nextcloud, Stork) to KVM. I am somewhat incompetent, but
after about 100 attempts I have managed to setup a bridged
network that connects my server to the rest of the network
and to the internet. My new KVM VMs are joining the
network as if they were real devices. My problem is my kea
DHCP4 server. I guess have done something stupid, either
with selecting the interface in kea-dhcp4.conf or with
configuring my bridged network (br0). At this stage, when
I start kea-dhcp4-server, it communicates to my HA standby
to to take control of DHCP but then completely fails to
provide ip addresses itself. So, the network currently
looks like this:
/dad@macserver:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp34s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc fq_codel master br0 state UP group default qlen 1000
link/ether 2c:f0:5d:2d:88:35 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether 42:4c:23:6c:4d:7f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.104/23 brd 192.168.1.255 scope global
noprefixroute br0
valid_lft forever preferred_lft forever
inet6 fe80::e54c:73f4:f662:95fb/64 scope link
noprefixroute
valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:5b:e6:4e brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd 192.168.100.255 scope global
virbr0
valid_lft forever preferred_lft forever
5: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue master br0 state UNKNOWN group default qlen 1000
link/ether fe:00:27:dc:06:7e brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:27ff:fedc:67e/64 scope link
valid_lft forever preferred_lft forever
6: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue master br0 state UNKNOWN group default qlen 1000
link/ether fe:54:00:80:eb:73 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe80:eb73/64 scope link
valid_lft forever preferred_lft forever/
The key sections (eliminating all my lease reservations
and such) of my dhcp4.conf look like this:
/{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "br0" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/run/kea/kea4-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"multi-threading": {
"enable-multi-threading": true,
"thread-pool-size": 2,
"packet-queue-size": 14
},
"client-classes": [
{
"name": "homeauto"
},
{
"name": "normal",
"test": "not member('homeauto')"
}
],
"option-data": [
{
"space": "dhcp4",
"name": "domain-name",
"code": 15,
"data": "skfaf.servesarcasm.com"
},
{
"space": "dhcp4",
"name": "domain-name-servers",
"code": 6,
"data": "192.168.1.1"
},
{
"space": "dhcp4",
"name": "broadcast-address",
"code": 28,
"data": "192.168.1.255"
},
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "192.168.1.1"
},
{
"space": "dhcp4",
"name": "subnet-mask",
"code": 1,
"data": "255.255.254.0"
}
],
"valid-lifetime": 43200,
"renew-timer": 21600,
"rebind-timer": 32400,
"expired-leases-processing": {
"reclaim-timer-wait-time": 3600,
"hold-reclaimed-time": 172800,
"max-reclaim-leases": 0,
"max-reclaim-time": 0
},
"dhcp-ddns": {
"enable-updates": false
},
"authoritative": true,
"hooks-libraries": [
{
"library":
"/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
},
{
"library":
"/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so"
},
{
"library":
"/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [ {
"this-server-name": "macserver",
"mode": "hot-standby",
"heatbeat-delay": 10000,
"max-response-delay": 60000,
"max-ack-delay": 5000,
"max-unacked-clients": 5,
"sync-timeout": 60000,
"multi-threading": {
"enable-multi-threading": true,
"http-dedicated-listener": true,
"http-listener-threads": 0,
"http-client-threads": 0
},
"peers": [
{
"name": "macserver",
"url": "http://192.168.1.104:8003/";
<http://192.168.1.104:8003/>,
"role": "primary"
},
{
"name": "oldhp",
"url": "http://192.168.1.110:8003/";
<http://192.168.1.110:8003/>,
"role": "standby"
}
]
} ]
}
}/
//
/],
"shared-networks": [
{
"name": "macnet",
"subnet4": [
{
"id": 1,
"subnet": "192.168.1.0/24",
"pools": [
{
"pool": "192.168.1.124 - 192.168.1.198",
"client-class": "normal"
}
],
"option-data": [
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "192.168.1.1"
}
]
},
{
"id": 2,
"subnet": "192.168.0.0/23",
"pools": [
{
"pool": "192.168.0.150 - 192.168.0.175",
"client-class": "homeauto"
}
],
"option-data": [
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "192.168.1.1"
},
{
"space": "dhcp4",
"name": "domain-name-servers",
"code": 6,
"data": "192.168.1.1"
}
]
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea-dhcp4.log",
"maxsize": 2048000,
"maxver": 4
}
],
"severity": "INFO",
"debuglevel": 0
}
]
}
}/
I changed my "interface" to "br0" because my previous
setup (exerp below) stopped working when I started the br0
network.
/{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "enp34s0" ]/
Changing the interface to "br0" has had exactly no effect.
I realise that I have missed something fundamental and I
am wasting your valuable time. However I have been trying
to sort this out for days (in whatever spare time is
available) and I have acheived nothing. Each time I start
kea-dhcp-server on my main server it appears in Stork with
no errors, systemd says its running fine and my HA standby
stops providing dhcp. Unfortunately if I then turn on a
device it simply does not receive an ip lease. If I turn
off DHCP on the main server then eventually the standby
starts takes over dhcp again and network functions return
to normal (though this takes a very long time & sometimes
requires a restart of kea-dhcp4-server on the stanby
server, perhaps another error to fix later). Even my new
VMs receive ips seamlessly from the standby server.
If you need to see some logs, please tell me where I can
retreive them because I haven't been able to work that out
either (I think I need to change my logging parameters in
kea-dhcp4.conf). I used Wireshark to capture network coms
before and after turning on the main dhcp server but I
then realised that I was too stupid/ignorant to work out
what was going on from the output. I can provided the
Wireshark output, but it is a large file (ran it for too
long and filtered it poorly, I think) that I won't inflict
on you unless you wish it.
Please give me some ideas of what I have to do to
troubleshoot/fix this.
Regards
Stuart MacGregor
