[Kea-users] dhcp4 server listening on more than one interface does not work
Chuck Zmudzinski
brchuckz at aol.com
Sat Apr 19 21:46:12 UTC 2025
On 4/19/2025 5:39 PM, Chuck Zmudzinski via Kea-users wrote:
> Hi Darren,
>
> I found the reason for the problem, but still have a question. Your
> advice to look at the logs identified the problem.
>
> According to the logs, the problem is that the Xen system is
> configuring each vifn.0 interface on which kea-dhcp4 is listening
> to have the same IPv4 address, and this is something that kea rejects.
>
> Here is the warning I get from the logger:
>
> Apr 19 16:25:05 almalinux kea-dhcp4[5650]: WARN [kea-dhcp4.dhcpsrv.139918558259328] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface vif6.0, reason: failed to bind fallback socket to address 192.168.1.105, port 67, reason: Address already in use - is another DHCP server running?
>
> That address, 192.168.1.105, is the address of the external interface
> which obtains its IPv4 address from a SOHO router, and by default in
> the Xen networking configuration is also the IPv4 address of the other
> vifn.0 interfaces that the kea-dhcp4 server needs to listen on. So
> apparently kea refuses to listen on more than one interface with the
> same IPv4 address, but the old ISC dhcp4 client was OK with that
> configuration.
>
> The good news:
>
> Unlike the hardware address of the vifn.0 interface which I could not
> figure out how to change, the Xen networking scripts do allow a
> change in the IPv4 address of the vifn.0 interface, and when I changed
> it to a different address on the same subnet, kea works as expected
> and can configure IPv4 for multiple guests on my Xen virtualization
> server.
>
> So now I can work around this limitation of kea relative to the old
> client.
>
> The not-so-good news:
>
> This behavior of kea means that multiple IPv4 addresses must now be
> wasted on the same node, which is not ideal. With the old ISC client,
Oops - I meant to say, With the old ISC *server* here. Sorry.
> the Xen server needs only 1 IPv4 address on the subnet that can be
> shared among all the vifn.0 interfaces to configure IPv4 for N guests.
>
> But with kea, the Xen server must use, or waste, N-1 additional IPv4
> addresses on the subnet for kea to be able to configure IPv4 for
> N guests.
>
> Do you think it is possible for a future version of kea to restore
> the behavior of the old ISC client that allowed the dhcp4 server to
> listen on multiple interfaces with the same IPv4 address, perhaps by
> adding a configuration option that causes kea to work the same way the
> old ISC dhcp4 server did in this particular configuration?
>
> I am currently running version 2.6.1 of kea.
>
> Thanks,
>
> Chuck
>
> On 4/19/2025 5:38 AM, Darren Ankney wrote:
>> Hi,
>>
>> What is most likely happening here is that Kea is having trouble
>> selecting the subnet in the case of the multiple interfaces. Suggest
>> you set "severity": "DEBUG", "debuglevel": 99 in your loggers for
>> kea-dhcp4 You will likely have to add an "interface": to the subnet as
>> a hint for selecting the subnet as explained here:
>> https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#local-and-relayed-traffic-in-shared-networks
>> It could be something else, but with the information available here,
>> that is my guess.
>>
>> Thank you,
>> Darren Ankney
>>
>> On Sun, Apr 13, 2025 at 9:29 PM Chuck Zmudzinski via Kea-users
>> <kea-users at lists.isc.org> wrote:
>>>
>>> Hi,
>>>
>>> I am trying to migrate my dhcp4 setup from the old ISC dhcp server to kea. I am
>>> running the dhcp4 server on a Xen virtual machine host to configure the network
>>> interfaces on guest virtual machines.
>>>
>>> Typically, each guest has a virtual ethernet interface on the virtual machine
>>> host connected to the network interface of the guest, and these interfaces are
>>> named vifn.0, where n is an integer equal to the virtual machine ID of the
>>> guest.
>>>
>>> So, if one guest is running whose ID is 1, the interface connected to the guest
>>> is vif1.0 and if two guests are running with ID of 1 and 2, then the interface
>>> connected to guest 1 is vif1.0 and the interface connected to guest 2 is vif2.0.
>>>
>>> Using the old ISC dhcp server, the list of vifn.0 interfaces is passed as an
>>> argument to the command line, for example 'vif1.0' or 'vif1.0 vif2.0'. This
>>> worked nicely, and all the guests were configured for IPv4 by the old ISC dhcp
>>> server.
>>>
>>> Using kea's dhcp4 server, I was hoping to reproduce the behavior of the old ISC
>>> dhcp4 server by having
>>>
>>> "interfaces-config": { "interfaces": [ "vif1.0", "vif2.0" ] },
>>>
>>> for the case with two guests and two interfaces to listen on, such as vif1.0 and
>>> vif2.0, and by having
>>>
>>> "interfaces-config": { "interfaces": [ "vif1.0" ] },
>>>
>>> for the case when there is only one guest and only one interface to listen on,
>>> such as vif1.0.
>>>
>>> The expected behavior is that each guest that is connected to an interface on
>>> which the kea-dhcp4 server is listening will receive an IPv4 address and other
>>> IPv4 configurations in accordance with the rest of the configuration file.
>>>
>>> The actual behavior is that the only case when any guest receives an IPv4
>>> configuration is when there is only one interface listed in the
>>> interfaces-config specification.
>>>
>>> IOW, this works as expected: "interfaces-config": { "interfaces": [ "vif1.0" ] },
>>>
>>> That is, the guest connected to vif1.0 receives an IPv4 configuration.
>>>
>>> This does not work for either guest:
>>> "interfaces-config": { "interfaces": [ "vif1.0", "vif2.0" ] },
>>>
>>> That is, neither the guest connected to vif1.0 nor the guest connected to vif2.0
>>> receives an IPv4 configuration.
>>>
>>> So, is this a bug? What am I missing here for the case when the server is
>>> supposedly configured to listen on more that one interface?
>>>
>>> Other useful information that might be relevant to this problem:
>>>
>>> 1. One odd thing Xen's toolstack does when configuring the vifn.0 interfaces is
>>> that it configures them all with the same hw mac address of fe:ff:ff:ff:ff:ff
>>> and it also by default configures the IPv4 address of each vifn.0 interface with
>>> a static address equal to the host's primary IPv4 address. The old ISC dhcp4
>>> server handled this situation without problems. Is it possible the kea dhcp4
>>> server cannot deal with multiple interfaces with the same mac address?
>>> Unfortunately, I have not been able to figure out how to change the mac address
>>> of the vifn.0 interfaces created by Xen so they are unique in the system;
>>> it is always fe:ff:ff:ff:ff:ff for every interface. There is a comment in the
>>> Xen repo that explains why they use this mac address:
>>>
>>> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/hotplug/Linux/xen-network-common.sh;h=42fa704e8d40f683ed3a7d3562b7c9685b7f804c;hb=3ad5d648cda5add395f49fc3704b2552aae734f7#l90
>>>
>>> The comment says:
>>>
>>> > # Initialise a dummy MAC address. We choose the numerically
>>> > # largest non-broadcast address to prevent the address getting
>>> > # stolen by an Ethernet bridge for STP purposes.
>>> > # (FE:FF:FF:FF:FF:FF)
>>> > ip link set dev ${dev} address fe:ff:ff:ff:ff:ff || true
>>>
>>> I tried to edit this to change the mac address in this script for one of the
>>> interfaces when I had two guests running but it did not work, probably because
>>> this script is not setting the mac address in my case. I could not find what
>>> is setting that mac address in my setup so I don't know how to change it.
>>>
>>> 2. For reference, following is a redacted version of the kea-dhcp4.conf file I
>>> am using when I want it to listen on vif1.0 and vif2.0. The reservations, dns,
>>> and router parts are working fine, the problem is the server does not configure
>>> any guests unless the server is configured to listen on only one interface, and
>>> in that case, it only configures the guest that is connected to the single
>>> interface the server isconfigured to listen on. The old dhcp server could listen
>>> on multiple vifn.0 interfaces and configure multiple guests with IPv4
>>> configurations, but kea's dhcp4 server seems to only work with one interface in
>>> my setup.
>>>
>>> Configuration file kea-dhcp4.conf:
>>>
>>> // This is an example configuration file for the DHCPv4 server in Kea.
>>> // It contains one subnet in which there are five static address reservations
>>> // for the clients identified by the MAC addresses.
>>> { "Dhcp4":
>>>
>>> {
>>> // Kea is told to listen only on these interfaces.
>>> "interfaces-config": {
>>> "interfaces": [ "vif1.0", "vif2.0" ]
>>> },
>>>
>>> // Kea supports control channel, which is a way to receive management
>>> // commands while the server is running. This is a Unix domain socket that
>>> // receives commands formatted in JSON, e.g. config-set (which sets new
>>> // configuration), config-reload (which tells Kea to reload its
>>> // configuration from file), statistic-get (to retrieve statistics) and many
>>> // more. For detailed description, see Sections 8.8, 16 and 15.
>>> "control-socket": {
>>> "socket-type": "unix",
>>> "socket-name": "/tmp/kea4-ctrl-socket"
>>> },
>>>
>>> // We need to specify the database used to store leases. As of April
>>> // 2022, three database backends are supported: MySQL, PostgreSQL, and the
>>> // in-memory database, Memfile. We'll use memfile because it doesn't
>>> // require any prior set up.
>>> "lease-database": {
>>> "type": "memfile",
>>> "lfc-interval": 3600
>>> },
>>>
>>> // Addresses will be assigned with a lifetime of 43200 seconds.
>>> "valid-lifetime": 43200,
>>>
>>> // This is for dns configuration
>>> "option-data": [
>>> {
>>> "name": "domain-name-servers",
>>> "data": "192.168.1.254"
>>> },
>>> // Typically people prefer to refer to options by their names, so they
>>> // don't need to remember the code names. However, some people like
>>> // to use numerical values. For example, option "domain-name" uses
>>> // option code 15, so you can reference to it either by
>>> // "name": "domain-name" or "code": 15.
>>> {
>>> "code": 15,
>>> "data": "example.org"
>>> },
>>>
>>> // Domain search is also a popular option. It tells the client to
>>> // attempt to resolve names within those specified domains. For
>>> // example, name "foo" would be attempted to be resolved as
>>> // foo.mydomain.example.com and if it fails, then as foo.example.com
>>> {
>>> "name": "domain-search",
>>> "data": "example.org"
>>> }
>>> ],
>>>
>>> // Reserve addresses by mac address
>>> "host-reservation-identifiers": [ "hw-address" ],
>>>
>>> // Define a subnet with five reservations.
>>> "subnet4": [
>>> {
>>> "pools": [ { "pool": "192.168.1.17 - 192.168.1.31" } ],
>>> "id": 1,
>>> "subnet": "192.168.1.0/24",
>>>
>>> // Router
>>> "option-data": [
>>> {
>>> "name": "routers",
>>> "data": "192.168.1.1"
>>> }
>>> ],
>>>
>>> // Specify whether the server should look up global reservations.
>>> // Defaults to false.
>>> "reservations-global": false,
>>>
>>> // Specify whether the server should look up in-subnet reservations.
>>> // Defaults to true.
>>> "reservations-in-subnet": true,
>>>
>>> // Specify whether the server can assume that all reserved addresses
>>> // are out-of-pool. Defaults to false.
>>> // Ignored when reservations-in-subnet is false.
>>> // If specified, it is inherited by "shared-networks" and
>>> // "subnet4" levels.
>>> "reservations-out-of-pool": true,
>>>
>>> "reservations": [
>>>
>>> // This are reservationis for a specific hardware/MAC address. It's a very
>>> // simple reservation: just an address and nothing else.
>>> {
>>> "hw-address": "<redacted>",
>>> "ip-address": "192.168.1.2"
>>> },
>>> {
>>> "hw-address": "<redacted>",
>>> "ip-address": "192.168.1.8"
>>> },
>>> {
>>> "hw-address": "<redacted>",
>>> "ip-address": "192.168.1.10"
>>> },
>>> {
>>> "hw-address": "<redacted>",
>>> "ip-address": "192.168.1.7"
>>> },
>>> {
>>> "hw-address": "<redacted>",
>>> "ip-address": "192.168.1.4"
>>> }
>>> ]
>>> }
>>> ],
>>>
>>> // The following configures logging. It assumes that messages with at
>>> // least informational level (info, warn, error and fatal) should be
>>> // logged to stdout.
>>> "loggers": [
>>> {
>>> "name": "kea-dhcp4",
>>> "output-options": [
>>> {
>>> "output": "stdout"
>>> }
>>> ],
>>> "severity": "INFO"
>>> }
>>> ]
>>> }
>>>
>>> }
>>>
>>> --
>>> 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 at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/kea-users
>
More information about the Kea-users
mailing list