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
