[Kea-users] Kea DHCP4 not working on newly configured bridged network
Stuart MacGregor
sleepygriogar at gmail.com
Sat Feb 21 10:57:44 UTC 2026
Razvan,
I tried adding interface "br0" to both my subnets a few days ago, there
was no measurable change so I removed the lines again.
On 21/2/26 20:48, Razvan Becheriu wrote:
> 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 <sleepygriogar at gmail.com>
> *To: *Kea <kea-users at lists.isc.org>; Razvan <razvan at isc.org>
> *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 <sleepygriogar at gmail.com>
> <mailto:sleepygriogar at gmail.com>
> *To: *kea-users <kea-users at lists.isc.org>
> <mailto: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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20260221/4ca56421/attachment-0001.htm>
More information about the Kea-users
mailing list