Hi Chuck, I have read through your several messages. I am not quite understanding, however. Are you saying that you have two interfaces with the same IP address or that you have two interfaces and only one of them has an IP address normally?
Also, if Kea cannot open a raw socket connection, then it can only serve relayed traffic. It cannot serve local traffic. If all of your traffic is local, and Kea is indeed serving this traffic, then it must be opening raw sockets. You can specify an IP address on any interface like this: "eth0/192.0.2.1" so if you do have different IP addresses on each interface (perhaps not even in the same subnet) these can be specified in the configuration as shown. As far as why Kea behaves differently than ISC DHCP. ISC DHCP had its own networking engine written by ISC in the distant past. Kea uses current common networking libraries. I do not know if achieving the same behavior is possible. Thank you, Darren Ankney On Sat, Apr 19, 2025 at 5:39 PM Chuck Zmudzinski via Kea-users <kea-users@lists.isc.org> 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, > 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@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@lists.isc.org > >> https://lists.isc.org/mailman/listinfo/kea-users > > -- > 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 -- 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
