Hello,
I discovered this issue while preparing to migrate my virtual machine
and virtual network configuration from the old ISC server to KEA. This
problem is absent in the old ISC DHCPv4 server.
A minimal network topology to illustrate the problem. Note the absence
of any switches, virtual bridges, etc. Just a very simple topology with
two Ethernet cables connecting three hosts:
+--------------------------+
| |
192.168.1.1/32 | Host A |192.168.1.1/32
___vif1.0_| KEA DHCP server for |_vif2.0___
| | subnet 192.168.1.0/24 | |
| +--------------------------+ |
| |
| |
eth0 eth0
+-------------------------- +--------------------------+
| | | |
| Host B | | Host C |
| DHCP client 1 | | DHCP client 2 |
| | | |
+-------------------------+ +--------------------------+
The expected behavior is that if we configure KEA to listen
on both vif1.0 and vif2.0 with a section in the kea-dhcp4.conf
file like this, both clients will be served with an IPv4
configuration:
"interfaces-config": {
"interfaces": [ "vif1.0", "vif2.0" ],
"dhcp-socket-type": "raw"
},
The actual behavior is that only Host B, client 1, which
is connected to the first interface listed in the "interfaces"
specification of the config file, receives an IPv4 configuration.
If we reverse the order of the interfaces like this:
"interfaces": [ "vif2.0", "vif1.0" ],
then only Host C, client 2, which is now the client connected to
the first interface listed, vif2.0, gets an IPv4 configuration.
The ISC DHCP client handles this configuration perfectly and
serves both clients without any problem.
The workaround to cause the KEA server to also be able to serve
both clients is simply to assign vif2.0 a different address,
such as 192.168.1.2. After doing that and reloading the configuration,
Host C, client 2 finally also receives its configuration.
IMHO, this is not an acceptable workaround. I also discovered that
for each additional interface I added to serve another directly
connected client, it was necessary to use another address, such
as 192.168.1.3, for that next interface on the server, which in
this case would be vif3.0. With the old ISC client, I could assign
the same address to all three interfaces, which in this example is
192.168.1.1. So with the old ISC server, I only need to use N + 1
addresses to serve N clients, but with KEA, I need to use 2*N addresses.
This substantially reduces the pool of addresses from 192.168.1.0/24
that would be available for clients from 253 down to 126. The other
126 would need to be wasted on Host A, the KEA DHCP server.
More details and a likely cause of this issue in this previous
message:
https://lists.isc.org/pipermail/kea-users/2025-April/005506.html
Kind regards,
Chuck Zmudzinski
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
