Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-07-17T13:58:22Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2631Modification of handling of global reservations with IP addresses set2023-07-17T13:58:22ZAlan CleggModification of handling of global reservations with IP addresses setCustomer request, ref: https://support.isc.org/Ticket/Display.html?id=21365
NOTE: Support ticket has patches that have been reviewed by Thomas and Francis and are not seen as appropriate. It would appear that the customers need is rea...Customer request, ref: https://support.isc.org/Ticket/Display.html?id=21365
NOTE: Support ticket has patches that have been reviewed by Thomas and Francis and are not seen as appropriate. It would appear that the customers need is real and that we should determine a good course forward.
-----------------------------
Ticket narrative provided below:
I would like to put in a feature request to modify the handling of global reservations with IP addresses set.
## Background ##
I'd like to detail some of our use case and the behaviors we have had to work around in our Kea implementation. We have created a self-service portal for users to register their devices to access the network. In the general case, this consists of a user giving us a MAC address and an FQDN for us to create a host reservation with, but we do allow IT administrators to reserve IP addresses as well. Even when a user requests a certain IP address, we do not necessarily restrict them from only using that network; i.e. they should be able to get a valid IP address in any network (with DDNS determined by the subnet they land in).
A few behaviors we've ran into using global host reservations:
1) Global reservations with IP addresses do no bounds checking on if the IP address is correct for a subnet.
a) If a device requests an address from a shared-network that does not contain its IP address, it will receive an address which cannot be used
b) If a device requests an address from a shared-network that does contain its IP address, but it's IP address is not a part of the subnet with the lowest ID, it will receive the correct address but incorrect options (e.g. routers).
2) Updated reservation MAC addresses may create conflicts when a lease with the old MAC address still exists (we use `match-client-id: false`)
3) I suspect that updated reservation FQDNs do not reflect when a client lease is updated, but have not verified
We have worked around issues 1b, 2, and 3 by modifying leases through the API via the self-service portal. On every create of update of a device with an IP reservation in our self-service portal, we ensure that the hostname, MAC address, and subnet-id on the lease(s) match what we expect. (1a) is still an issue for us and requires manual intervention to either move the device into the shared-network where it should exist, or change the host reservation to be in the shared-network where the device currently resides.
I understand there is a workaround: create two reservations (one global without an IP address and one inside the subnet with an IP address). This increases our complexity by adding another data store to keep in sync, and I believe could end up reducing performance due to more host lookups. It's my opinion that the current global reservation behavior is a footgun which can be easily avoided, and the requested behavior is more in line with what users of ISC DHCPd would expect.
## Feature Request ##
Kea should only hand out feasible addresses to clients and correctly match leases to subnets for global reservations with IP addresses.
Current behavior:
- if a host reservation does not have an IP address:
- defer to normal dynamic lease creation
- if a host reservation has an IP address, and the IP address overlaps with any subnet within a shared network:
- create/reuse a lease tied to the first subnet that the client class allows
- if a host reservation has an IP address, and the IP address does not overlap with any subnet in a shared network
- create/reuse a lease tied to a subnet unfit for the IP address
Requested behavior:
- if a host reservation does not have an IP address:
- defer to normal dynamic lease creation
- if a host reservation has an IP address, and the IP address overlaps with any subnet within a shared network:
- create/reuse a lease tied to the matching subnet
- if a host reservation has an IP address, and the IP address does not overlap with any subnet in a shared network
- defer to normal dynamic lease creation
I have attached a patch series to implement this behavior for both DHCPv4 and DHCPv6 IA_NA reservations. Descriptions of the patches are below:
- alloc_engine4.patch: implements requested behavior for DHCPv4 reservations
- alloc_engine_tests4.patch: implements tests for requested behavior in DHCPv4
- alloc_engine6.patch: implements requested behavior for DHCPv6 IA_NA reservations
- alloc_engine_tests6.patch: implements tests for requested behavior in DHCPv6kea2.3.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2566reservation-get-page command result for RADIUS backend2023-07-17T13:58:24ZSlawek Figielreservation-get-page command result for RADIUS backend**Describe the bug**
The user configured Kea to use RADIUS as the host backend.
The `reservation-get-page` command (and similar) returns a general error. For example:
```shell
$ kea-shell --host 127.0.0.1 --port 8000 --service dhcp4 re...**Describe the bug**
The user configured Kea to use RADIUS as the host backend.
The `reservation-get-page` command (and similar) returns a general error. For example:
```shell
$ kea-shell --host 127.0.0.1 --port 8000 --service dhcp4 reservation-get-page
"subnet-id": 1, "limit": 10
^D
[ { "result": 1, "text": "not supported by the RADIUS backend" } ]
```
I think that the result should be different.
The first proposal is to return status 2 (unsupported). It will be consistent with the error description.
The second prosal is to skip the RADIUS backend for this command. Currently, if the user has other host databases configured simultaneously, it is impossible to query them using host commands.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea DHCP daemon (I tested it only on the DHCPv4 daemon and Kea 1.8, 2.0, and 2.2) with `hosts_cmds`, `host_cache`, and `radius` hooks.
2. Generate some network traffic. It is necessary to activate the RADIUS host backend.
3. Send the `reservations-get-page` or `reservations-get-all` command
4. Observe an error with the `result` property equal to 1.
**Expected behavior**
Skip querying the unsupported host backend for the above commands (recommended) or return an unsupported status (`result` property equal to 2).
**Environment:**
- Kea version: Kea 1.8, 2.0, and 2.2 installed from the premium CloudSmith packages. (The user reports that he used the standard ones).
- Kea hooks: hosts_cmds, host_cache, and radius
- OS: Debian 10, 11, and RHEL 8.5
- Which features were compiled in (in particular which backends): I used the official CloudSmith packages.
**Additional Information**
The problem was originally described in [stork#792](https://gitlab.isc.org/isc-projects/stork/-/issues/792).
The reporter attached the configuration file, short parts of logs, and other details.
We will handle this problem on the Stork side because it affects already released Kea versions. But it'll be nice to change it in Kea for consistency.
**Contacting you**
I'm where I'm always. An original reporter is @vps-eric.kea2.3.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2452Postgres - New key for hosts table2022-07-22T14:35:23ZPeter DaviesPostgres - New key for hosts tablewe did some performance testing in our dhcp setup and discovered, that the session setup rate is very bad (~ 20/sec.).
We use postgresql as host reservation backend and noticed, that it utilizes nearly 100% of the CPU during the test.
...we did some performance testing in our dhcp setup and discovered, that the session setup rate is very bad (~ 20/sec.).
We use postgresql as host reservation backend and noticed, that it utilizes nearly 100% of the CPU during the test.
We discovered that the cause for that are pgsql queries inside the hosts database, which take about 7ms for each host.
There exist indexes for the "hosts" table, but none matches for the query that Kea uses in our case. So we added that index and the queries were about 400 times faster (session setup rate also over 200/sec., seems to be limited only by our dhcp relay, because the CPU utilization of the server stays below 50% now).
We did not test IPv6, but the problem could exist there as well.
In the case of IPv4, the following modifications of the pgsql database solved our problem:
1. added the following index:
CREATE UNIQUE INDEX key_dhcp4_identifier on hosts (dhcp_identifier, dhcp_identifier_type);
--> there is already an index, but it contains the dhcp4_subnet_id, which Kea didn't use in the host lookup query.
2. modified the following existing index:
"key_dhcp4_identifier_subnet_id" UNIQUE, btree (dhcp_identifier, dhcp_identifier_type, dhcp4_subnet_id) WHERE dhcp4_subnet_id IS NO
T NULL AND dhcp4_subnet_id <> 0
to
"key_dhcp4_identifier_subnet_id" UNIQUE, btree (dhcp_identifier, dhcp_identifier_type, dhcp4_subnet_id) WHERE dhcp4_subnet_id IS NO
T NULL
--> we use global reservations, where dhcp4_subnet_id = 0 is set in the hosts database, so the index was not used because of "dhcp4_subnet_id <> 0"
Some background information:
We use Kea to dynamically assign addresses out of pools inside a shared subnet, but only if the host has an entry in the "hosts" table. So the host entry does not have an IP address defined.
Please feel free to ask if you have further questions of if we can test/debug anything.
see also:
https://gitlab.isc.org/isc-projects/kea/-/issues/2037
https://gitlab.isc.org/isc-projects/kea/-/issues/1458
[RT #20893](https://support.isc.org/Ticket/Display.html?id=20893 )kea2.2.0 - a new stable branchThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2409Shared network with different subnets for HR and pool - a client matching a H...2022-10-25T13:27:12ZCathy AlmondShared network with different subnets for HR and pool - a client matching a HR is issued lease from pool but with wrong subnet IDFrom [Support ticket #20651](https://support.isc.org/Ticket/Display.html?id=20651) and associated with issue #2408.
The scenario is a shared network that contains two subnets.
One subnet has no pool addresses, but has a number of host ...From [Support ticket #20651](https://support.isc.org/Ticket/Display.html?id=20651) and associated with issue #2408.
The scenario is a shared network that contains two subnets.
One subnet has no pool addresses, but has a number of host reservations for clients. These clients are matched on the basis of information added by their relay.
The other subnet has the pool addresses for unreserved clients.
Something goes wrong with the mechanism for identifying clients, so the same relay-info is being associated with more than one client. This means that sometimes when a client needs a lease, it is matched to the host reservation per the information added by the relay, but it can't be allocated the address in its host reservation because that address is already in-use.
The Kea server OFFERs instead a pool address from the other subnet in the shared network. This is then written to the leases database, but with the subnet of the host reservations, not the subnet of the unreserved pool. The client operates normally and the Kea server appears not to take issue with this itself (although I anticipate that there might be a problem restarting and loading these subnet/address mis-matched leases). But in an HA environment, the lease update is rejected by the other servers because of the subnet id being incorrect for the address of the lease.
(Note that the above is a production environment issue, but that other circumstances could lead to an address associated with a HR that matches a 'new' client, not actually being available to be granted, so I think we should look at this more widely than just this scenario as presented above. There is also the additional scenario (which I think would take a different code path) where a client is offered the HR address, but then sends back DHCPDECLINE because it detects itself that it is in use locally, even if the Kea server did not issue the lease. Please consider this scenario too when looking at reasons why an address associated with a HR cannot be OFFERed).
Here's the logging by HA when the lease update is rejected
```
2022-04-28 22:42:39.410 ERROR [kea-dhcp4.callouts/9787.140701841197248] HOOKS_CALLOUT_ERROR error returned by callout on hook $lease4_update registered by library with index 1 (callout address 0x7ff7aa57bf30) (callout duration 0.074 ms)
2022-04-28 22:42:41.546 ERROR [kea-dhcp4.callouts/9787.140701841197248] HOOKS_CALLOUT_ERROR error returned by callout on hook $lease4_update registered by library with index 1 (callout address 0x7ff7aa57bf30) (callout duration 0.066 ms)
```
Also this:
```
2022-04-28 22:30:07.013 WARN [kea-dhcp4.ha-hooks/26493.139690055428288] HA_LEASE_UPDATE_FAILED [hwtype=1 ce:47:47:XX:XX:XX], cid=[01:ce:47:47:XX:XX:XX], tid=0x5fc5fba0: lease update to SERVER-NAME-REDACTED (http://XXX.XXX.XX.XX:8080) failed: The
address 10.1.XX.XX does not belong to subnet 192.2.XX.XX/24, subnet-id=6, error code 1
```
And here's the logging on the active server when it hits the issue with host reservation because another client has already been issued with the address associated with the matching HR:
```
2022-04-28 22:36:41.489 WARN [kea-dhcp4.alloc-engine/26493.139690055428288] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 08:9b:b9:XX:XX:XX], cid=[01:08:9b:b9:XX:XX:XX], tid=0xdcec1449: conflicting reservation for address 10.1.XX.XX with existing lease Address: 10.1.XX.XX
```
Version 2.0.0 (package)kea2.1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2304radius and early global HR lookup2022-03-15T18:02:19ZFrancis Dupontradius and early global HR lookupPremium only issue for RADIUS hook and early global reservations lookup incompability.Premium only issue for RADIUS hook and early global reservations lookup incompability.kea2.1.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1463Performance improvement: lookup leases by address first when address is avail...2023-07-31T13:14:28ZAndrei Pavelandrei@isc.orgPerformance improvement: lookup leases by address first when address is availableEdit: TLDR: This issue is about looking up leases by address hint in renews and v6 requests. Currently, they are first searched by DUID/client ID. Because these are not primary keys, but indexes, this lookup is slower. Searching by addre...Edit: TLDR: This issue is about looking up leases by address hint in renews and v6 requests. Currently, they are first searched by DUID/client ID. Because these are not primary keys, but indexes, this lookup is slower. Searching by address which is a primary key should be significantly faster. I imagine this as a few lines of code changed, although it is affecting the allocation engine. There are concerns that this might affect host reservations, RADIUS or other aspects. I expect that to come up in tests.
---
When designing database scehmas, it is desirable to look at access patterns in order to define keys or indexes or maybe entire table definitions. When looking at the DHCP protocol, we can easily figure out that the key that we most want to use in a lookup is the client's identifier which is usually the DUID or client ID. This is not the case for current Kea since address is clearly chosen as sole primary key across all backends for the lease databases. This is probably because it is chosen based on it's unique properties. A v6 client can have multiple addresses per DUID and maybe it's the same for v4 in same strange use cases. This could have been solved by storing addresses as a list in DUID/clientID-keyed tables at the cost of complexity. But that is not my proposal.
We can leverage the current table structure by looking up by address when possible. This is effectively the case when an address hint is provided. A well known case when this happens is during the renew process, but I think I remember reading from a RFC that it can be provided in other DHCP messages as well. But a well-behaved client should (RFC SHOULD?) always send the address in their RENEW (I think it's still called REQUEST for DHCPv4?) and RENEWs are 99% of the DHCP messages sent in networks with high uptime. So it is an optimization for RENEW.
Concerns:
* Security? Honoring DHCP clients requesting address directly might lead to address starvation?
* No, after lookup by address finds nothing, the usual DISCOVER & SOLICIT messages go through with looking up by DUID/clientID. And then it will find the lease that belonged to the malicious client. Even if it did, add that to the list of security issues. Clients spoofing their DUID/clientID doesn't do the same?
* Are we sure we aren't providing the address to the wrong client?
* Yes. We can check in-memory/in-server if the DUIDs/clientIDs match. Even though what harm can the right lease given to the wrong client do?
* Does this affect the ability to reserve addresses/prefixes, RADIUS, hooks or other use-cases?
* To be investigated. I don't know. Because firstly I don't understand why host reservations are looked up before leases. This optimization is less impactful if we still search by DUID/clientID in hosts first. I would move the address lookup in the lease database at the beginning of the packet processing. But then why not move the DUID/clientID lookup at the beginning as well? If the client has an active lease, doesn't it stop there?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1458suboptimal retrieval of host reservation in the case of db backends2022-06-24T09:41:05ZRazvan Becheriusuboptimal retrieval of host reservation in the case of db backendsin void AllocEngine::findReservation(ClientContext[4|6]& ctx)
```
void
AllocEngine::findReservation(ClientContext[4|6]& ctx) {
ctx.hosts_.clear();
// If there is no subnet, there is nothing to do.
if (!ctx.subnet_) {
...in void AllocEngine::findReservation(ClientContext[4|6]& ctx)
```
void
AllocEngine::findReservation(ClientContext[4|6]& ctx) {
ctx.hosts_.clear();
// If there is no subnet, there is nothing to do.
if (!ctx.subnet_) {
return;
}
auto subnet = ctx.subnet_;
std::map<SubnetID, ConstHostPtr> host_map;
SharedNetwork[4|6]Ptr network;
subnet->getSharedNetwork(network);
if (subnet->getHostReservationMode() == Network::HR_GLOBAL) {
ConstHostPtr ghost = findGlobalReservation(ctx);
if (ghost) {
ctx.hosts_[SUBNET_ID_GLOBAL] = ghost;
// @todo In theory, to support global as part of HR_ALL,
// we would just keep going, instead of returning.
return;
}
}
// If the subnet belongs to a shared network it is usually going to be
// more efficient to make a query for all reservations for a particular
// client rather than a query for each subnet within this shared network.
// The only case when it is going to be less efficient is when there are
// more host identifier types in use than subnets within a shared network.
// As it breaks RADIUS use of host caching this can be disabled by the
// host manager.
const bool use_single_query = network &&
!HostMgr::instance().getDisableSingleQuery() &&
(network->getAllSubnets()->size() > ctx.host_identifiers_.size());
if (use_single_query) {
for (auto id_pair : ctx.host_identifiers_) {
ConstHostCollection hosts = HostMgr::instance().getAll(id_pair.first,
&id_pair.second[0],
id_pair.second.size());
// Store the hosts in the temporary map, because some hosts may
// belong to subnets outside of the shared network. We'll need
// to eliminate them.
for (auto host = hosts.begin(); host != hosts.end(); ++host) {
if ((*host)->getIPv[4|6]SubnetID()) {
host_map[(*host)->getIPv[4|6]SubnetID()] = *host;
}
}
}
}
// We can only search for the reservation if a subnet has been selected.
while (subnet) {
// Only makes sense to get reservations if the client has access
// to the class and host reservations are enabled.
if (subnet->clientSupported(ctx.query_->getClasses()) &&
(subnet->getHostReservationMode() != Network::HR_DISABLED)) {
// Iterate over configured identifiers in the order of preference
// and try to use each of them to search for the reservations.
for (auto id_pair : ctx.host_identifiers_) {
if (use_single_query) {
if (host_map.count(subnet->getID()) > 0) {
ctx.hosts_[subnet->getID()] = host_map[subnet->getID()];
break;
}
} else {
// Attempt to find a host using a specified identifier.
ConstHostPtr host = HostMgr::instance().get[4|6](subnet->getID(),
id_pair.first,
&id_pair.second[0],
id_pair.second.size());
// If we found matching host for this subnet.
if (host) {
ctx.hosts_[subnet->getID()] = host;
break;
}
}
}
}
// We need to get to the next subnet if this is a shared network. If it
// is not (a plain subnet), getNextSubnet will return NULL and we're
// done here.
subnet = subnet->getNextSubnet(ctx.subnet_, ctx.query_->getClasses());
}
}
```
vs
```
void
AllocEngine::findReservation(ClientContext[4|6]& ctx) {
ctx.hosts_.clear();
// If there is no subnet, there is nothing to do.
if (!ctx.subnet_) {
return;
}
auto subnet = ctx.subnet_;
std::map<SubnetID, ConstHostPtr> host_map;
SharedNetwork[4|6]Ptr network;
subnet->getSharedNetwork(network);
if (subnet->getHostReservationMode() == Network::HR_GLOBAL) {
ConstHostPtr ghost = findGlobalReservation(ctx);
if (ghost) {
ctx.hosts_[SUBNET_ID_GLOBAL] = ghost;
// @todo In theory, to support global as part of HR_ALL,
// we would just keep going, instead of returning.
return;
}
}
// If the subnet belongs to a shared network it is usually going to be
// more efficient to make a query for all reservations for a particular
// client rather than a query for each subnet within this shared network.
// The only case when it is going to be less efficient is when there are
// more host identifier types in use than subnets within a shared network.
// As it breaks RADIUS use of host caching this can be disabled by the
// host manager.
***
// Can not call getAll[4|6] because RADIUS does not support it.
// While the performance is acceptable for RADIUS and CfgHosts, doing
// network->getAllSubnets()->size() * ctx.host_identifiers_.size() for
// db backends is suboptimal, as getAll[4|6] is supported.
// This results in
// network->getAllSubnets()->size() * ctx.host_identifiers_.size()
// roundtrips vs network->getAllSubnets()->size() number of roundtrips
// Should this function be implemented as a Host virtual function?
***
const bool use_single_query = network &&
!HostMgr::instance().getDisableSingleQuery() &&
(network->getAllSubnets()->size() > ctx.host_identifiers_.size());
if (use_single_query) {
for (auto id_pair : ctx.host_identifiers_) {
ConstHostCollection hosts = HostMgr::instance().getAll(id_pair.first,
&id_pair.second[0],
id_pair.second.size());
// Store the hosts in the temporary map, because some hosts may
// belong to subnets outside of the shared network. We'll need
// to eliminate them.
for (auto host = hosts.begin(); host != hosts.end(); ++host) {
if ((*host)->getIPv[4|6]SubnetID()) {
host_map[(*host)->getIPv[4|6]SubnetID()] = *host;
}
}
}
}
// We can only search for the reservation if a subnet has been selected.
while (subnet) {
// Only makes sense to get reservations if the client has access
// to the class and host reservations are enabled.
if (subnet->clientSupported(ctx.query_->getClasses()) &&
(subnet->getHostReservationMode() != Network::HR_DISABLED)) {
// Iterate over configured identifiers in the order of preference
// and try to use each of them to search for the reservations.
ConstHostCollection subnet_hosts;
if (!use_single_query) {
subnet_hosts = HostMgr::instance().getAll[4|6](subnet->getID());
}
for (auto id_pair : ctx.host_identifiers_) {
if (use_single_query) {
if (host_map.count(subnet->getID()) > 0) {
ctx.hosts_[subnet->getID()] = host_map[subnet->getID()];
}
} else {
ConstHostPtr host;
for (auto current : subnet_hosts) {
if (current->getIdentifierType() != id_pair.first) {
continue;
}
if (current->getIdentifier() != id_pair.second) {
continue;
}
host = current;
break;
}
// If we found matching host for this subnet.
if (host) {
ctx.hosts_[subnet->getID()] = host;
break;
}
}
}
}
// We need to get to the next subnet if this is a shared network. If it
// is not (a plain subnet), getNextSubnet will return NULL and we're
// done here.
subnet = subnet->getNextSubnet(ctx.subnet_, ctx.query_->getClasses());
}
}
```
Things to note:
1. the following comment is misleading:
```
// If the subnet belongs to a shared network it is usually going to be
// more efficient to make a query for all reservations for a particular
// client rather than a query for each subnet within this shared network.
// The only case when it is going to be less efficient is when there are
// more host identifier types in use than subnets within a shared network.
// As it breaks RADIUS use of host caching this can be disabled by the
// host manager.
```
2. the following check is wrong, because it uses the slow path for db backends when using global subnets:
```
const bool use_single_query = network &&
!HostMgr::instance().getDisableSingleQuery() &&
(network->getAllSubnets()->size() > ctx.host_identifiers_.size());
```
because of the RADIUS limitation, there are still network->getAllSubnets()->size() * ctx.host_identifiers_.size() calls.
This is optimal for CfgHosts and it is a limitation for RADIUS, but it is very bad on db backends as it does a lot of roundtrips (slower than actual in RAM filtering by calling getAll[4|6] and keeping hosts with matching identifiers).
Because there is no easy way to optimize this, maybe this function can be implemented as a virtual function in each backend:
CfgHosts and Radius can use current implementation by calling get[4|6] for each subnet and for each identifier type, and mysql, postgresql and cassandra can call getAll[4|6] for each subnet and filter the identifiers in ram (effectively lowering the number of roundtrips).
It can also be implemented by adding a flag just like in case of RADIUS, 'getDisableSingleQuery', like 'getAllQueryEnabled', but , by using this approach, there is no way RADIUS can function with a db backend in an optimal way.kea1.9.4Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1428Multiple reservations for the same IP2022-10-25T13:30:06ZTomek MrugalskiMultiple reservations for the same IPA new use case has been brought to our attention. A new device with two NICs is being powered. Each NIC has its own MAC address. However, at any given time only one of those NICs is connected and powered up. Sadly, it's not possible to d...A new use case has been brought to our attention. A new device with two NICs is being powered. Each NIC has its own MAC address. However, at any given time only one of those NICs is connected and powered up. Sadly, it's not possible to determine this a'priori which interface will be connected. The intention here to have the same IP address assigned, regardless which NIC will be used.
Under normal circumstances, it is a configuration error to have more than one reservation for the same IP. However, the use case above provides an external constraint that ensures this conflict will never be observed, as there is always only one of the two reservations that will be in use.
The goal of this ticket is to make such operation possible.
While we will start this work in %"kea1.9.0", given the imminent code freeze this Friday, the solution will likely be available in %"kea1.9.1"
[Support ticket #17096](https://support.isc.org/Ticket/Display.html?id=17096)kea1.9.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/558some host retrieval operations can not be executed in read only database2019-04-16T07:09:19ZRazvan Becheriusome host retrieval operations can not be executed in read only databasequeries like:
GET_HOST_SUBID4, // Gets hosts by IPv4 SubnetID
GET_HOST_SUBID6, // Gets hosts by IPv6 SubnetID
GET_HOST_SUBID4_PAGE, // Gets hosts by IPv4 SubnetID beginning by HID
GET_HOST_...queries like:
GET_HOST_SUBID4, // Gets hosts by IPv4 SubnetID
GET_HOST_SUBID6, // Gets hosts by IPv6 SubnetID
GET_HOST_SUBID4_PAGE, // Gets hosts by IPv4 SubnetID beginning by HID
GET_HOST_SUBID6_PAGE, // Gets hosts by IPv6 SubnetID beginning by HID
have index in enum 'StatementIndex' after
INSERT_HOST
This will cause on both mysql and postgresql to not enable these queries in read only database:
easy code lookup: search for:
WRITE_STMTS_BEGINKea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/550authentication key to text method miss-spelled2019-07-22T10:48:26ZFrancis Dupontauthentication key to text method miss-spelledIt is `AuthKey::ToText()` when it should be `Authkey::toText()`.
BTW it is the occasion to fix a second issue about this method: display the key in hexadecimal (it could make harder to input it but the syntax for DHCPv6 host reservation...It is `AuthKey::ToText()` when it should be `Authkey::toText()`.
BTW it is the occasion to fix a second issue about this method: display the key in hexadecimal (it could make harder to input it but the syntax for DHCPv6 host reservations nor in the host commands hook (can be the subject of another issue but currently authentication keys are stored only in databases, not config files).Kea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/549Implement reservation-update command2023-07-17T13:58:21ZTomek MrugalskiImplement reservation-update commandWe currently have commands that add, retrieve and delete host reservations. We're missing a command to update existing reservations.We currently have commands that add, retrieve and delete host reservations. We're missing a command to update existing reservations.kea2.3.7Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/511Return a list of all reservations by subnet ID - #313 for Cassandra back-end ...2019-05-22T16:59:20ZCathy AlmondReturn a list of all reservations by subnet ID - #313 for Cassandra back-end (if possible)This is a follow-on request from GL #313 - which was not implemented for Cassandra database back-end due to the technical challenges, described as:
In #313, the idea about paging is to reduce the communication:
- with SQL database you ...This is a follow-on request from GL #313 - which was not implemented for Cassandra database back-end due to the technical challenges, described as:
In #313, the idea about paging is to reduce the communication:
- with SQL database you can ask a page of the whole result from the DB: the kea-server will translate this page to JSON and sends to the requestor.
- with Cassandra you do not have this so you can get the whole result and page it in the kea-sever, etc.
To summarise, what matters is where the paging is done. In #313 we decided to do it only in the DB (so only for SQL DBs).
This ticket is to explore what we could to meet the use-case need (similarly or differently) with the Cassandra back-endKea1.6Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/478Improve error message: "Database access parameter 'type' does not specify a s...2019-03-06T20:25:35ZCathy AlmondImprove error message: "Database access parameter 'type' does not specify a supported database backend:mysql"---
name: Improve error message: "Database access parameter 'type' does not specify a supported database backend:mysql"
about: Please make it clearer why this error is being emitted. The 'type' is a valid configuration option. The prob...---
name: Improve error message: "Database access parameter 'type' does not specify a supported database backend:mysql"
about: Please make it clearer why this error is being emitted. The 'type' is a valid configuration option. The problem is that the build does not include support for mysql back-end.
---
These error messages don't explain well what the problem is and where to look to fix it:
> root@debian:/opt/kea-1.5.0# 2019-02-18 17:26:12.746 ERROR [kea-dhcp4.dhcp4/51240] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /usr/local/etc/kea/kea-dhcp4.conf, reason: Unable to open database: Database access parameter 'type' does not specify a supported database backend:mysql
> 2019-02-18 17:26:12.746 ERROR [kea-dhcp4.dhcp4/51240] DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/usr/local/etc/kea/kea-dhcp4.conf': Unable to open database: Database access parameter 'type' does not specify a supported database backend:mysql
A better message would be something like:
"Unable to open database: The Kea server has not been built with support for database type: mysql"
See [#14213](https://support.isc.org/Ticket/Display.html?id=14213)Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/474RADIUS with shared networks2019-05-15T12:50:03ZTomek MrugalskiRADIUS with shared networksWhen RADIUS was implemented, we didn't have shared networks support. As a result, there was a mechanism designed (subnet-reselect) to do something a bit similar to shared networks.
We need to look at the code and see:
- what is needed t...When RADIUS was implemented, we didn't have shared networks support. As a result, there was a mechanism designed (subnet-reselect) to do something a bit similar to shared networks.
We need to look at the code and see:
- what is needed to make RADIUS work with shared network
- what the limitations would be
RADIUS has some substantial limitations as a database-like system, but the basic assumption that it can return attributes that are mapped to client classes should be viable.
#403 has a discussion about current (1.5) code and its limitations.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/181reallocate IPv6-Addr with one Host and different DUIDs not working2023-09-19T15:24:09ZGeorg W.reallocate IPv6-Addr with one Host and different DUIDs not working---
name: Bug report
about: Reallocate IPv6-Address not working properly with PXE (or multiple OS)
---
I've tried to get some help using the kea-users mailing list months ago but I didn't get a solution to this problem. For now, I comp...---
name: Bug report
about: Reallocate IPv6-Address not working properly with PXE (or multiple OS)
---
I've tried to get some help using the kea-users mailing list months ago but I didn't get a solution to this problem. For now, I compiled myself a workaround into the code to get the IPv6 leases by hw-addr and not by duid. Details following:
***Description***
The Kea dhcp6 daemon doesn't reallocate (active) IPv6-leases for an OS after a successful PXE IPv6 address allocation.
***Configuration***
(configuration file is attached)
- lease-database: postgresql
- hosts-database: postgresql
- mac-sources: client-link-addr-option only
- host-reservation-identifiers: hw-address only
***To Reproduce***
Steps to reproduce the behavior:
1. Run Kea dhcpv6-daemon with: ```"mac-sources": ["client-link-addr-option"]``` and ```"host-reservation-identifiers": ["hw-address"]``` and an IPv6 host reservation with hw-address as the specific reservation-id-type
2. boot the PXE-System (or the first OS) first, everything works fine
3. boot another OS (e.g. Debian) with this host, daemon answers with "Sorry, no address could be allocated."
***Expected behavior***
In the configuration file exists a parameter called "host-reservation-identifiers". Kea uses only these specific identifier types to get host reservations from the host database. To get all active Leases of a hostsystem, Kea should use the same Method like in the reservation procedure.
If the host boots up the first time with PXE, kea gets a request, gets the host-reservation and allocate this IPv6 with its hw-address. Now the host boots up with its real OS (e.g. Debian) and kea should search for a lease like it was searching for a host-reservation.
In our case:
Kea gets the mac-address from the clients client-link-addr-option and so Kea should search for active leases by the mac-address, because of the host-reservation-identifiers option.
***Environment***
- Kea version: 1.4.0 (from gitlab)
- OS: debian stretch
- used database back-end: postgresql
- no hooks were used
Atachements
***kea-dhcp6.conf***
```
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "eth0/2001:db8::8d:37:c0:f6" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea-dhcp6-ctrl.sock"
},
"lease-database": {
"type": "postgresql",
"name": "kea",
"user": "keauser",
"password": "xxxxxx",
"host": "localhost",
"port": 5432
},
"hosts-database": {
"readonly": true,
"type": "postgresql",
"name": "kea",
"user": "keauser",
"password": "xxxxxx",
"host": "localhost",
"port": 5432
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 1800,
"rebind-timer": 2880,
"valid-lifetime": 3600,
"mac-sources": ["client-link-addr-option"],
"host-reservation-identifiers": [ "hw-address" ],
"subnet6": [
{
"subnet": "2001:db8:0:24::/64",
"id": 24,
"reservations": [
]
}
]
},
// Logging configuration starts here. Kea uses different loggers to log various
// activities. For details (e.g. names of loggers), see Chapter 18.
"Logging":
{
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea/kea-dhcp6.log",
"maxsize": 26214400,
"maxver": 8
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
```
***hosts-table***
| host_id | dhcp_identifier | dhcp_identifier_type | ... |
| -------- | -------- | -------- | -------- |
| 01 | 0x00163e01c01f | 0 | ... |
| 02 | 0x... | ... | ... |
***ipv6_reservations***
| reservation_id | address | prefix_len | type | dhcp_iaid | host_id |
| -------- | -------- | -------- | -------- | -------- | -------- |
| 01 | 2001:db8:0:24::ff | 128 | 0 | (null) | 01 |
| 02 | ... | ... | ... | ... | ... |
***Remarks***
I can push my short workaround, if you want o have a look at.kea2.5.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/173Kea guide documentation correction needed2018-12-10T16:08:52ZGhost UserKea guide documentation correction neededHere is my setup for DB in **kea-dhcp4.conf **
Case : I have kea server running with below DB config but when my DB crashes[Manually i stopped db for test]. Kea log shows DB connection error and it started retrying for 50 tries as i co...Here is my setup for DB in **kea-dhcp4.conf **
Case : I have kea server running with below DB config but when my DB crashes[Manually i stopped db for test]. Kea log shows DB connection error and it started retrying for 50 tries as i configured but when i DB crash recover [Manually i started db]. kea unable to connect with DB still showing below mentioned error messages and not assigning lease to client !
```
}]
}],
"lease-database": {
"type": "mysql",
"name": "kea",
"user": "root",
"password": "",
"host": "10.25.133.13",
"port": 3306,
"max-reconnect-tries" : 50,
"reconnect-wait-time": 2000,
"connect-timeout": 5000,
"request-timeout": 12000,
"tcp-keepalive": 1,
"tcp-nodelay": true
},
"hosts-database": {
"type": "mysql",
"name": "kea",
"user": "root",
"password": "",
"host": "10.25.133.13",
"port": 3306,
"max-reconnect-tries" : 50,
"reconnect-wait-time": 2000,
"connect-timeout": 5000,
"request-timeout": 12000,
"tcp-keepalive": 1,
"tcp-nodelay": true
},
```
**Once kea started with DB Log output : [1st start ]**
```
DHCPSRV_MYSQL_DB opening MySQL lease database: connect-timeout=5000 host=10.25.133.13 **max-reconnect-tries=50 name=kea port=3306 reconnect-wait-time=2000 request-timeout=12000 tcp-keepalive=1 tcp-nodelay=true type=mysql universe=4 user=root**
2018-10-16 23:26:47.385 INFO [kea-dhcp4.hosts/12919] DHCPSRV_MYSQL_HOST_DB opening MySQL hosts database: connect-timeout=5000 host=10.25.133.13 max-reconnect-tries=50 name=kea port=3306 reconnect-wait-time=2000 request-timeout=12000 tcp-keepalive=1 tcp-nodelay=true type=mysql universe=4 user=root
2018-10-16 23:26:47.398 INFO [kea-dhcp4.ha-hooks/12919] HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the is in the WAITING state
2018-10-16 23:26:47.398 INFO [kea-dhcp4.ha-hooks/12919] HA_SERVICE_STARTED started high availability service in load-balancing mode as primary server
2018-10-16 23:26:47.399 INFO [kea-dhcp4.dhcp4/12919] DHCP4_STARTED Kea DHCPv4 server version 1.4.0 started
```
**Once DB crashed log output : [DB stopped ] **
```
ERROR [kea-dhcp4.dhcpsrv/12919] DHCPSRV_MYSQL_FATAL_ERROR Unrecoverable MySQL error occurred: unable to execute for <SELECT address, hwaddr, client_id, valid_lifetime, expire, subnet_id, fqdn_fwd, fqdn_rev, hostname, state FROM lease4 WHERE state != ? AND expire < ? ORDER BY expire ASC LIMIT ?>, reason: MySQL server has gone away (error code: 2006).
2018-10-16 23:33:49.235 INFO [kea-dhcp4.dhcpsrv/12919] DHCPSRV_MYSQL_DB opening MySQL lease database: connect-timeout=5000 host=10.25.133.13** max-reconnect-tries=50 name=kea port=3306 reconnect-wait-time=2000 request-timeout=12000 tcp-keepalive=1 tcp-nodelay=true type=mysql universe=4 user=root**
2018-10-16 23:33:49.236 ERROR [kea-dhcp4.dhcp4/12919] DHCP4_DB_RECONNECT_ATTEMPT_FAILED database reconnect failed: Can't connect to MySQL server on '10.25.133.13' (111)
2018-10-16 23:33:49.236 INFO [kea-dhcp4.dhcp4/12919] DHCP4_DB_RECONNECT_ATTEMPT_SCHEDULE** scheduling attempt 2 of 50 in 2000 seconds**
2018-10-16 23:33:49.236 ERROR [kea-dhcp4.dhcpsrv/12919] DHCPSRV_TIMERMGR_CALLBACK_FAILED running handler for timer reclaim-expired-leases caused exception: fatal database errror or connectivity lost
2018-10-16 23:33:53.240 ERROR [kea-dhcp4.alloc-engine/12919] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: no current lease manager is available
```
**Once DB recovered log output : [DB up and running ]
Still kea not connecting with db **
```
2018-10-16 23:35:33.359 ERROR [kea-dhcp4.alloc-engine/12919] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: no current lease manager is available
2018-10-16 23:35:58.390 ERROR [kea-dhcp4.alloc-engine/12919] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: no current lease manager is available
2018-10-16 23:36:23.419 ERROR [kea-dhcp4.alloc-engine/12919] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: no current lease manager is available
2018-10-16 23:36:48.449 ERROR [kea-dhcp4.alloc-engine/12919] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: no current lease manager is available
2018-10-16 23:37:13.479 ERROR [kea-dhcp4.alloc-engine/12919] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: no current lease manager is available
2018-10-16 23:37:38.499 ERROR [kea-dhcp4.alloc-engine/12919] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: no current lease manager is available
2018-10-16 23:38:03.528 ERROR [kea-dhcp4.alloc-engine/12919] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: no current lease manager is available
2018-10-16 23:38:28.557 ERROR [kea-dhcp4.alloc-engine/12919] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: no current lease manager is available
```
I believe Kea should automatically connect with lease DB once DB came UP/running !
**Is something am missing on conf or bug ?**Kea1.5-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/27CqlHostDataSource::del4 () and del6() fail when given a non-existent host res...2018-11-28T09:21:55ZThomas MarkwalderCqlHostDataSource::del4 () and del6() fail when given a non-existent host reservationNeither function checks for the case of host not found, and causes the server to SIGABRT. They should both be modified to simply return true if the host does not exist. This is in keeping with our philosophy that attempting to delete an...Neither function checks for the case of host not found, and causes the server to SIGABRT. They should both be modified to simply return true if the host does not exist. This is in keeping with our philosophy that attempting to delete an object that does not exist equates to a successful delete.
There are apparently no unit tests for this scenario and there most certainly should be. We need to verify that MySQL and PostgreSQL behave properly and have unit tests for this.Kea1.5-beta2Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/15Global Host Reservations Task 5: data migration scripts to convert existing s...2021-11-11T12:02:57ZThomas MarkwalderGlobal Host Reservations Task 5: data migration scripts to convert existing subnet-id values of 0The changes made in 5704 to support global HRs necessitate migrating existing data. Specifically for MySQL and PostgreSQL, any columns with values of 0 for subnet IDs in hosts and options tables, need to replace with NULL, and for Cassan...The changes made in 5704 to support global HRs necessitate migrating existing data. Specifically for MySQL and PostgreSQL, any columns with values of 0 for subnet IDs in hosts and options tables, need to replace with NULL, and for Cassandra, they should be replaced with GLOBAL_ID_UNUSED.
Data migration steps need to be added to the schema upgrade scripts for 1.5.0 to accommodate this.
Replaces http://kea.isc.org/ticket/5708Kea1.5-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/70Global Host Reservations Task 5: data migration scripts to convert existing s...2018-11-07T11:38:39ZGhost UserGlobal Host Reservations Task 5: data migration scripts to convert existing subnet-id values of 0The changes made in 5704 to support global HRs necessitate migrating existing data. Specifically for MySQL and PostgreSQL, any columns with values of 0 for subnet IDs in hosts and options tables, need to replace with NULL, and for Cassa...The changes made in 5704 to support global HRs necessitate migrating existing data. Specifically for MySQL and PostgreSQL, any columns with values of 0 for subnet IDs in hosts and options tables, need to replace with NULL, and for Cassandra, they should be replaced with GLOBAL_ID_UNUSED.
Data migration steps need to be added to the schema upgrade scripts for 1.5.0 to accommodate this.Kea1.5-beta1https://gitlab.isc.org/isc-projects/kea/-/issues/681Synchronize reservations between HA partners2022-11-02T16:23:36ZGhost UserSynchronize reservations between HA partnersI have bought Kea Premium hook package and I am using it for IP reservation but I have a problem not sure if that's how should be or not.
I am running kea DHCP in HA(Active/HotStandBY)- When I add a reservation on Active node it doesn't...I have bought Kea Premium hook package and I am using it for IP reservation but I have a problem not sure if that's how should be or not.
I am running kea DHCP in HA(Active/HotStandBY)- When I add a reservation on Active node it doesn't get replicated to HotStandBy node. Due to this, I am unable to use my hot standby node. Can you please have a look asap.
And what will happen if I add some reservation while other node is down - will they get replication when the node comes back online?
Kea DHCP 1.5outstanding