[Kea-users] Kea DHCP4 not working on newly configured bridged network
Stuart MacGregor
sleepygriogar at gmail.com
Sat Feb 21 11:43:19 UTC 2026
There is an instance of dnsmasq running on virbr0, which is the default
"nat" interface for kvm vms not using bridged networking. The virbr0
network is supposed to be isolated from the rest of the network, but it
is possible; According to the output of netstat -lntup"
tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN
2707/kea-ctrl-agent
tcp 0 0 192.168.1.104:5357 0.0.0.0:* LISTEN
2732/python3
tcp 0 0 0.0.0.0:37099 0.0.0.0:* LISTEN
2718/rpc.mountd
tcp 0 0 192.168.100.1:53 0.0.0.0:* LISTEN
3028/dnsmasq
...
udp 0 0 192.168.100.1:53 0.0.0.0:*
3028/dnsmasq
udp 0 0 127.0.0.54:53 0.0.0.0:*
1548/systemd-resolv
udp 0 0 127.0.0.53:53 0.0.0.0:*
1548/systemd-resolv
udp 0 0 0.0.0.0:67 0.0.0.0:*
3028/dnsmasq
That last line is a bit of a worry, I think kea DHCP4 would be running
on 0.0.0.0:67 if it were running. I'll just check....
tcp 0 0 192.168.1.104:8003 0.0.0.0:* LISTEN
845230/kea-dhcp4
When I started dhcp4 the only record netstat-lntop had of it was tcp
rather than udp, but i thought that kea ran on udp by default unless
specified. I actually think the 8003 port is where the stork server
communicates, so perhaps the dnsmasq is blocking kea from udp.
When I disconnect virbr0 and start kea-dhcp4-server I still get dnsmasq
on 0.0.0.0:67 udp, even though dnsmasq is not installed on my computer
and only runs as part of qemu-kvm. I will look into this further in the
morning.
Regards
Stuart MacGregor
On 21/2/26 21:17, Razvan Becheriu wrote:
> netstat -lntup
> is dnsmasq running/binding to same iface/addr/port?
>
> ------------------------------------------------------------------------
> *From: *Stuart <sleepygriogar at gmail.com>
> *To: *Razvan <razvan at isc.org>
> *Cc: *Kea <kea-users at lists.isc.org>
> *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 <sleepygriogar at gmail.com>
> <mailto:sleepygriogar at gmail.com>
> *To: *Kea <kea-users at lists.isc.org>
> <mailto:kea-users at lists.isc.org>; Razvan <razvan at isc.org>
> <mailto: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/c29a674a/attachment-0001.htm>
More information about the Kea-users
mailing list