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@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
