[Kea-users] Kea DHCP4 not working on newly configured bridged network
Stuart MacGregor
sleepygriogar at gmail.com
Sat Feb 21 12:21:33 UTC 2026
Razvan & Darren,
Thank you for your help on what must be a Saturday morning for you.
After the information you sent me I used:
sudo virsh net-destroy default
That "destroyed" the KVM "default" virtual network, the one used for
"nat" networking that uses dnsmasq for DHCP (supposedly only on its
isolated network of vms, but obviously not so isolated). As soon as I
did this kea-dhcp4-server started responding to to DHCP requests. What's
more, my "bridged" vms are still connected. I was never going to use nat
connected vms, anyway, so everything works for me now. I will still
changing my logging config and will also check if my changes survive a
restart, but thank you for your help.
If another hopeless fool like me asks these questions again, I hope my
experience helps them.
Regards
Stuart MacGregor
On 21/2/26 21:56, Razvan Becheriu wrote:
> you can work around this by using linux namespaces and/or virtual
> interfaces (and keep dnsmasq still running).
> there is already a ticket about this:
> https://gitlab.isc.org/isc-projects/kea/-/issues/3006
> for a workaround see comment
> https://gitlab.isc.org/isc-projects/kea/-/issues/3037#note_600694
> hope this helps.
> Razvan
>
> ------------------------------------------------------------------------
> *From: *Razvan <razvan at isc.org>
> *To: *Stuart <sleepygriogar at gmail.com>
> *Cc: *Kea <kea-users at lists.isc.org>
> *Date: *Saturday, 21 February 2026 1:52 PM EET
> *Subject: *Re: [Kea-users] Kea DHCP4 not working on newly
> configured bridged network
>
> you can simply try 'killall dnsmasq' and see if you get traffic.
> regards,
> Razvan
>
> ------------------------------------------------------------------------
> *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 1:43 PM EET
> *Subject: *Re: [Kea-users] Kea DHCP4 not working on newly
> configured bridged network
>
> 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>
> <mailto:sleepygriogar at gmail.com>
> *To: *Razvan <razvan at isc.org> <mailto:razvan at isc.org>
> *Cc: *Kea <kea-users at lists.isc.org>
> <mailto: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/6978f8ce/attachment-0001.htm>
More information about the Kea-users
mailing list