[Kea-users] Kea DHCP4 not working on newly configured bridged network
Stuart MacGregor
sleepygriogar at gmail.com
Sat Feb 21 01:30:56 UTC 2026
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 at 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/",
"role": "primary"
},
{
"name": "oldhp",
"url": "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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20260221/4dfa7319/attachment-0001.htm>
More information about the Kea-users
mailing list