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
