[Kea-users] Kea DHCP4 not working on newly configured bridged network
Stuart MacGregor
sleepygriogar at gmail.com
Sat Feb 21 10:55:28 UTC 2026
Darren,
Kea was installed from packages on the standard Ubuntu repo, thus it is
the lowly version 2.4.1. I have been considering changing to the isc
repos but it is a bit of a hassle and if my teenage kids are
disconnected from the internet for too long there will be a mutiny. I
was under the impression that Ubuntu will change to Kea 3 when 26.04
comes out, so I haven't been bothered.
I do start and stop using systemd, I have typed "sudo systemctl restart
kea-dhcp4-server" a great many times in the last week. I can change the
log config. I will do that tomorrow, it's nearly 9pm here in Brisbane
and I've had a few glasses of wine. My already insignificant tech skills
are further compromised at the moment.
Regards
Stuart MacGregor
On 21/2/26 20:43, Darren Ankney wrote:
> Hi Stuart,
>
> If there is no file: /var/log/kea-dhcp4.log then I would say that Kea
> cannot write to this file (or, more probably, the directory
> /var/log/). What was the source of the Kea software (compile from
> source? packages? If packages, how did you add the repo (or is it
> ubuntu package)?) What exact command do you use to start and stop
> Kea?
>
> If you are starting Kea with systemd, I would actually recommend
> changing your logger section to this:
>
> "loggers": [
> {
> "name": "kea-dhcp4",
> "output_options": [
> {
> "output": "stdout"
> }
> ],
> "severity": "INFO",
> "debuglevel": 0
> }
> ]
>
> And then you can tail logs like this: `sudo journalctl -u <service
> file name> -f` while you start kea and send traffic to it.
>
> Thank you,
> Darren Ankney
>
> On Sat, Feb 21, 2026 at 5:35 AM Stuart MacGregor
> <sleepygriogar at gmail.com> wrote:
>> 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<sleepygriogar at gmail.com>
>> To: kea-users<kea-users at lists.isc.org>
>> 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 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 brdff: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 brdff: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
>> inet6fe80::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 brdff: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/etherfe:00:27:dc:06:7e brdff:ff:ff:ff:ff:ff
>> inet6fe80::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/etherfe:54:00:80:eb:73 brdff:ff:ff:ff:ff:ff
>> inet6fe80::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
>>
>>
>>
>>
>>
>>
>> --
>> ISC funds the development of this software with paid support subscriptions. Contact us athttps://www.isc.org/contact/ for more information.
>>
>> To unsubscribe visithttps://lists.isc.org/mailman/listinfo/kea-users.
>> Kea-users at lists.isc.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20260221/934a2d3c/attachment-0001.htm>
More information about the Kea-users
mailing list