netstat -lntup
is dnsmasq running/binding to same iface/addr/port?
------------------------------------------------------------------------
*From: *Stuart <[email protected]>
*To: *Razvan <[email protected]>
*Cc: *Kea <[email protected]>
*Date: *Saturday, 21 February 2026 12:57 PM EET
*Subject: *Re: [Kea-users] Kea DHCP4 not working on newly
configured bridged network
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 <[email protected]>
<mailto:[email protected]>
*To: *Kea <[email protected]>
<mailto:[email protected]>; Razvan <[email protected]>
<mailto:[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
