[Kea-users] Issue created on GitLab (Was: Re: DHCPv4 server only serves clients connected to first interface in some cases)

[Chuck Zmudzinski]

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
>