Hi Darren, I created an issue on the ISC GitLab Instance for this problem:
https://gitlab.isc.org/isc-projects/kea/-/issues/3873 We had a brief discussion about this issue about 1-2 weeks ago. Kind regards, Chuck Zmudzinski On 4/23/2025 2:46 PM, Chuck Zmudzinski wrote: > 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
