Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-21T11:52:04Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3262add RADIUS thread pool and make the RADIUS library MT-compatible2024-03-21T11:52:04ZAndrei Pavelandrei@isc.orgadd RADIUS thread pool and make the RADIUS library MT-compatibleRADIUS access is now asynchronous, but it is still single-threaded. To truly benefit from multi-threading, it needs its own thread pool.
There might also be some MT-specific races and bugs that need to be fixed. TBDRADIUS access is now asynchronous, but it is still single-threaded. To truly benefit from multi-threading, it needs its own thread pool.
There might also be some MT-specific races and bugs that need to be fixed. TBDkea2.5.7Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3227config-set accepts incorrect "prefix-len" value2024-01-19T08:22:53ZPeter Daviesconfig-set accepts incorrect "prefix-len" value
---
name: config-set accepts incorrect "prefix-len" value
about: On kea-dhcp6 version 2.2.1 config-set accepts incorrect "prefix-len"
value and future config-get and config-write calls fail.
---
**Describe the bug**
Given the follo...
---
name: config-set accepts incorrect "prefix-len" value
about: On kea-dhcp6 version 2.2.1 config-set accepts incorrect "prefix-len"
value and future config-get and config-write calls fail.
---
**Describe the bug**
Given the following subnet definition ( within a shared-network)
```
"subnet": "2a02:6b67:fc00:31::/64",
"id": 2,
"pd-pools": [{
"prefix": "2a02:6b67:ed70::",
"prefix-len": 44,
"delegated-len": 56}],
```
Kea starts correctly and config-* commands function as expected.
Change "prefix-len": 44, to "prefix-len": 38, and run "config-test" with this
invalid configuration. The command returns "result": 0,
```
[root@blaenau agent]# ./config-test6
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5776 100 147 100 5629 143 5507 0:00:01 0:00:01 --:--:-- 5662
[
{
"result": 0,
"text": "Configuration seems sane. Control-socket, hook-libraries, and D2 configuration were sanity checked, but not applied."
}
]
```
Run config-set with this invalid configuration and it also returns 0
```
[root@blaenau agent]# ./config-set6
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5684 100 56 100 5628 53 5411 0:00:01 0:00:01 --:--:-- 5475
[
{
"result": 0,
"text": "Configuration successful."
}
]
````
Now try and retrieve the running configuration with config-get or config-write.
```
[root@blaenau agent]# ./config-get6
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 191 100 141 100 50 10071 3571 --:--:-- --:--:-- --:--:-- 15916
[
{
"result": 1,
"text": "Error during command processing: invalid prefix range 2a02:6b67:ed70::-2a02:6b67:efff:ffff:ffff:ffff:ffff:ffff"
}
]
```
```
[root@blaenau agent]# ./config-write6
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 269 100 134 100 135 13400 13500 --:--:-- --:--:-- --:--:-- 38428
[
{
"result": 1,
"text": "Error during write-config:invalid prefix range 2a02:6b67:ed70::-2a02:6b67:efff:ffff:ffff:ffff:ffff:ffff"
}
]
````
Strangely after accepting the invalid configuration Kea appears to start sending
logging to stdout. the last message in the Kea log file is:
```
2024-01-19 01:52:35.014 INFO [kea-dhcp6.commands/97719.140321550017664] COMMAND_RECEIVED Received command 'config-set'
```
Correcting "prefix-len" and re-runing config-set re-enables the retrieval of the
running config but not the logging issue.
I haven't test if lease processing is affected by this.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv6 with the attached configuration file [
2. change the prefix-len to some invalid value via config-set
3. The server then appears to accept the configuration but efforts to retrieve
the runing configuration fail
4. See above
**Expected behavior**.
When running config-test Kea ought to have discovered the configuration error
and reported it.
When running config-set Kea ought to have discovered the configuration error
and reported it.
**Environment:**
- Kea version: 2.2.1
tarball
linked with:
log4cplus 1.2.0
OpenSSL 1.1.1k FIPS 25 Mar 2021
database:
Memfile backend 4.0
- OS: Oracle Linux 8"
- none
- none
**Additional Information**
This does not affect 2.5.4 which generates the following error:
```
2024-01-18 14:53:13.667 ERROR [kea-dhcp6.dhcp6/431892.140413956814720] DHCP6_PARSER_FAIL failed to create or run parser for configuration element shared-networks: Invalid Pool6 address boundaries: 2a02:6b67:ed70:: is not the first address in prefix: 2a02:6b67:ec00::/38 (<wire>:0:3314) (<wire>:0:2401)
```
**SalesForce**
[#00001600](https://isc.lightning.force.com/lightning/r/Case/500S6000003m9ybIAA/view)https://gitlab.isc.org/isc-projects/kea/-/issues/3198vivso-suboptions not properly supported in Netconf2024-01-26T10:58:09ZDarren Ankneyvivso-suboptions not properly supported in NetconfAn example of configuration of `vivso-suboptions` is shown in the ARM (simplified here):
```
"Dhcp4": {
"option-data": [
{
"name": "vivso-suboptions",
"space": "dhcp4",
"data": "2234"
...An example of configuration of `vivso-suboptions` is shown in the ARM (simplified here):
```
"Dhcp4": {
"option-data": [
{
"name": "vivso-suboptions",
"space": "dhcp4",
"data": "2234"
},
{
"name": "vivso-suboptions",
"space": "dhcp4",
"data": "3561"
},
...
]
}
```
In the Kea yang definition found in: src/share/yang/modules/kea-dhcp4-server@2023-06-28.yang the keys are "code space" as shown here:
```
grouping option-data-list {
description "Option data list grouping.";
list option-data {
key "code space";
description "Option data entry.";
leaf code {
type uint8;
mandatory true;
description "Option code.";
}
leaf space {
type string;
mandatory true;
description "Option space.";
}
uses dhcp:option-data-name;
uses dhcp:option-data-data;
uses dhcp:option-data-csv-format;
uses dhcp:option-data-always-send;
uses dhcp:option-data-never-send;
uses dhcp:option-data-user-context;
}
}
```
which makes it impossible to create two option-data entries with the same space (dhcp4) and code (125 for VIVSO). This is as stated in [RFC6020](https://datatracker.ietf.org/doc/html/rfc6020#section-7.8.2):
> The combined values of all the leafs specified in the key are used to uniquely identify a list entry. All key leafs MUST be given values when a list entry is created.
So this `sysrepocfg` xml works:
```
<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp4-server">
<subnet4>
<id>1</id>
<pool>
<start-address>192.168.20.100</start-address>
<end-address>192.168.20.200</end-address>
</pool>
<subnet>192.168.20.0/24</subnet>
</subnet4>
<option-data>
<code>125</code>
<space>dhcp4</space>
<data>2234</data>
</option-data>
<interfaces-config>
<interfaces>enp0s3</interfaces>
</interfaces-config>
<control-socket>
<socket-name>/tmp/kea-dhcp4-ctrl.sock</socket-name>
<socket-type>unix</socket-type>
</control-socket>
</config>
```
while this, with second entry for option 125, does not:
```
<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp4-server">
<subnet4>
<id>1</id>
<pool>
<start-address>192.168.20.100</start-address>
<end-address>192.168.20.200</end-address>
</pool>
<subnet>192.168.20.0/24</subnet>
</subnet4>
<option-data>
<code>125</code>
<space>dhcp4</space>
<data>2234</data>
<code>125</code>
<space>dhcp4</space>
<data>3561</data>
</option-data>
<interfaces-config>
<interfaces>enp0s3</interfaces>
</interfaces-config>
<control-socket>
<socket-name>/tmp/kea-dhcp4-ctrl.sock</socket-name>
<socket-type>unix</socket-type>
</control-socket>
</config>
```
When an attempt to apply the configuration is made, the output is as follows:
```
$ sudo sysrepocfg -v debug -d startup -f xml -m kea-dhcp4-server --edit=startup4.xml
[INF] Connection 52 created.
[INF] Session 20 (user "root", CID 52) created.
libyang error: Invalid position of the key "code" in a list. (Data location "/kea-dhcp4-server:config/option-data[code='125'][space='dhcp4']/code", line number 14.)
sysrepocfg error: Data parsing failed
[INF] No datastore changes to apply.
```
Please see [SF1556](https://isc.lightning.force.com/lightning/r/Case/500S6000002qbYdIAI/view) for further details including some proposed solutions.kea2.5.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3178Run multiple HA relationships in hub-and-spoke configuration2024-01-26T14:35:10ZMarcin SiodelskiRun multiple HA relationships in hub-and-spoke configurationThis is the actual implementation of the hub-and-spoke model described in the design ticket: https://gitlab.isc.org/isc-projects/kea/-/issues/1149
It should add the logic to run multiple `HAService` instances concurrently. The major iss...This is the actual implementation of the hub-and-spoke model described in the design ticket: https://gitlab.isc.org/isc-projects/kea/-/issues/1149
It should add the logic to run multiple `HAService` instances concurrently. The major issue is to implement the callouts for the `subnet4_select` and `subnet6_select` hook points that would be used in the hub-and-spoke configuration to select the relationship based on the selected subnet. We should also test that the `HAService` instances do not stomp on each other, that are thread safe etc. After this ticket, the hub-and-spoke configuration should be usable, at least in a basic form.
[support#22017](https://support.isc.org/Ticket/Display.html?id=22017).kea2.5.5Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3161lease4-get-all has incorrect count in the case of multiple subnets2023-12-06T18:16:33ZDarren Ankneylease4-get-all has incorrect count in the case of multiple subnetsIt seems that in the case of `lease4-get-all` output, when there are multiple subnets with used addresses, that the final count only includes the number of leases from that subnet. (Please note: This is as reported by output obtained fr...It seems that in the case of `lease4-get-all` output, when there are multiple subnets with used addresses, that the final count only includes the number of leases from that subnet. (Please note: This is as reported by output obtained from version 2.2.1 by someone else. I don't personally have a way to confirm this as I don't have a way, in my testbed, to setup multiple subnets and have addresses used in all of them.)
For example:
subnet 1 has 10 addresses in use.
subnet 2 has 20 and
subnet 3 has 5
When performing a `lease4-get-all` without a "subnets" argument, all leases from all three subnets will be included but the final text will say this:
```
'result': 0,
'text': '5 IPv4 lease(s) found.'}]
```
even though the actual number of leases returned, confirmed by inspecting the output, is 35. See [SF1234](https://isc.lightning.force.com/lightning/r/Case/5007V00002WzraeQAB/view?0.source=alohaHeader) for full details.kea2.5.5Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3149Bulk Leasequery (BLQ) needs to be able to match PDs associated with a link, e...2024-01-18T20:33:05ZCathy AlmondBulk Leasequery (BLQ) needs to be able to match PDs associated with a link, even if the subnet of the PD is outside of the subnet of the linkI'm reporting this a bug, since this is missing functionality, but functionality that is clearly important operationally, and without this (or a viable workaround) means the use of BLQ by a rebooting router is useless for finding and qui...I'm reporting this a bug, since this is missing functionality, but functionality that is clearly important operationally, and without this (or a viable workaround) means the use of BLQ by a rebooting router is useless for finding and quickly reprovisioning PDs as well as IAs.
**Describe the bug**
A router is using BLQ to learn of the existing leases associated with its link following a reboot. Particularly it's interested in the PDs since it's going to need to set up its routing appropriately to the client PDs.
BLQ using `query-by-link-address` is retrieving only the IAs associated with the link. This is sort of unsurprising since the PDs, although associated with the subnet that matches the link, aren't members of that subnet (this is also unsurprising).
However, in the leases memfile, both the IA and the PD have the same subnet id (the id of the subnet that matches to the link), and the IA, unsurprisingly is an address within that subnet.
- There is no PD pool associated with the subnet in the dhcp6 configuration
- All the PDs are assigned using HRs - but they *are* associated with the same subnet as the client IA
- I can see in the leases file, that the subnet ID is correct, if BLQ happened internally to be using subnet ID to 'find' leases associated with a link address.
I can't see any other way to get this information currently. The natural way to use BLQ here is to specify the link address (which also does match in the leases database, as well as the subnet ID associated with this link address's subnet). But the underlying lease search code doesn't seem to be using either of these.
How else is a router going to get the list of PDs it should be provisioning? Clearly after just rebooting, it's not going to **know** what ranges of prefixes have been delegated since PD subnets are independent of the subnet via which they're being delegated anyway.
See details in the customer case linked below.
I've also been discussing the semantics of the documentation and other information around BLQ with Kea Engineering, who have requested that I open this issue.
**Environment:**
- Kea version: 2.4.0
- OS: N/A
- Using memfile for leases, postgresql for HRs and mysql for config:
```
...
"Dhcp6": {
"allocator": "iterative",
"calculate-tee-times": true,
"config-control": {
"config-databases": [
{
"host": "127.0.0.1",
"max-reconnect-tries": 30,
"name": "kea",
"password": "<obscured>",
"port": 3306,
"reconnect-wait-time": 2000,
"type": "mysql",
"user": "kea"
}
],
"config-fetch-wait-time": 60
},
...
"lease-database": {
"lfc-interval": 3600,
"type": "memfile"
},
...
"reservations-global": false,
"reservations-in-subnet": true,
"reservations-lookup-first": false,
"reservations-out-of-pool": false,
...
"library": "\/usr\/lib\/x86_64-linux-gnu\/kea\/hooks\/libdhcp_lease_query.so",
"parameters": {
"advanced": {
"active-query-enabled": false,
"bulk-query-enabled": true,
"extended-info-tables-enabled": true,
"lease-query-ip": "<obscured>",
"lease-query-tcp-port": 547,
"max-bulk-query-threads": 0,
"max-concurrent-queries": 0,
"max-leases-per-fetch": 100,
"max-requester-connections": 10,
"max-requester-idle-time": 300
},
"requesters": [
"<obscured>"
]
}
}
],
"host-reservation-identifiers": [
"duid",
"flex-id"
],
"hostname-char-replacement": "",
"hostname-char-set": "[^A-Za-z0-9.-]",
"hosts-databases": [
{
"host": "127.0.0.1",
"max-reconnect-tries": 30,
"name": "kea",
"password": "<obscured>",
"port": 3306,
"reconnect-wait-time": 2000,
"type": "mysql",
"user": "kea"
}
],
```
- Using hooks:
> libdhcp_ha.so
> libdhcp_mysql_cb.so
> libdhcp_host_cmds.so
> libdhcp_lease_cmds.so
> libdhcp_subnet_cmds.so
> libdhcp_cb_cmds.so
> libdhcp_flex_id.so
> libdhcp_legal_log.so
> libdhcp_lease_query.so
**Additional Information**
Here's the operational use case supporting this:
> The DHCP BLQ needs to return the PDs including from any reservations. For our use case, PDs are the one thing we are actually looking to grab when using BLQ. Our routers will send a BLQ after they reload so that they can re-populate the PD routes and subscribers v6 networks can begin working again.
**Contacting you**
See [SF#1426](https://isc.lightning.force.com/lightning/r/5007V00002Zkn9vQAB/view?0.source=alohaHeader)kea2.5.5Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3141Update DNR docs to RFC 94632024-02-23T16:22:33ZPiotrek ZadrogaUpdate DNR docs to RFC 9463As of November 2023, draft-ietf-add-dnr/16 was published as RFC 9463.
There are some comments in code referring to draft, they could be updated with RFC no. for clarity.
Sadly, the on-wire format has changed between draft and RFC. Kea ...As of November 2023, draft-ietf-add-dnr/16 was published as RFC 9463.
There are some comments in code referring to draft, they could be updated with RFC no. for clarity.
Sadly, the on-wire format has changed between draft and RFC. Kea code needs to be updated.kea2.5.6Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3136Cloudsmith repository and local proxying2024-01-16T21:20:23ZDarren AnkneyCloudsmith repository and local proxyingPresently, the Cloudsmith Kea repository setup script does not request any parameters. Therefore, if the client machine needs to use a proxy to connect via http/https to the outside world, there is no possibility of doing this without m...Presently, the Cloudsmith Kea repository setup script does not request any parameters. Therefore, if the client machine needs to use a proxy to connect via http/https to the outside world, there is no possibility of doing this without making hand edits to the script or changing things that were setup after the fact.
There were two resolutions to this proposed:
- Would it be possible to map the sources of kea and the entire tools in a tool such as https://debgen.github.io/ or https://debgen.xyz/ for Premium packages?
- Or ask for a proxy during the script setup from Cloudsmith? This one would need to be requested of Cloudsmith as this script is not created by ISC.
- Perhaps a sources.list tool that allows automatically generating the required sources.list (incl. token) + the gpg key while using the proxy.
I'm not sure if any are viable solutions but perhaps something else could be done?
Further detail available here: [SF1425](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZkPPQQA3/view)kea2.5.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3123Synced leases with HA standby cause RADIUS accounting packets2024-01-26T15:38:09ZDarren AnkneySynced leases with HA standby cause RADIUS accounting packetsIf the Kea HA peers (`libdhcp_ha.so`) are configured to send RADIUS accounting packets using the `libdhcp_radius.so` hook, then the standby peer also sends accounting packets on lease sync. This can create a few problems such as:
- The ...If the Kea HA peers (`libdhcp_ha.so`) are configured to send RADIUS accounting packets using the `libdhcp_radius.so` hook, then the standby peer also sends accounting packets on lease sync. This can create a few problems such as:
- The "acct-session-id" will not match between the accounting packets sent from the primary and standby Kea peers.
- The timestamp of the event may not match between the packets sent from the primary and standby Kea peers.
- If there were attributes gathered via the RADIUS authentication process, this will not have occurred on the standy peer. Therefore, there may be missing data in the accounting packet.
Propose that some type of flag to disable sending these accounting updates from the standby server be added.
[SF1403](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZRLi2QAH/view)kea2.5.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3109Logging inconsistency between dhcp4.packets and dhcp6.packets2023-11-27T11:53:16ZDarren AnkneyLogging inconsistency between dhcp4.packets and dhcp6.packetsThis log for DHCPv4:
```
[kea-dhcp4.packets/2921701.140031672309504] DHCP4_QUERY_DATA [hwtype=1 00:00:00:ff:ff:ff], cid=[00:00:00:00:ff:ff:ff:ff:ff:ff:ff], tid=0x8eabb73f, packet details: local_address=1.2.3.4:67, remote_address=1.2.3.5:...This log for DHCPv4:
```
[kea-dhcp4.packets/2921701.140031672309504] DHCP4_QUERY_DATA [hwtype=1 00:00:00:ff:ff:ff], cid=[00:00:00:00:ff:ff:ff:ff:ff:ff:ff], tid=0x8eabb73f, packet details: local_address=1.2.3.4:67, remote_address=1.2.3.5:68, msg_type=DHCPREQUEST (3), transid=0x8eabb73f,
```
contains the msg_type while the DHCPv6 counterpart does not:
```
[kea-dhcp6.packets/3264085.139762203666176] DHCP6_QUERY_DATA duid=[00:00:00:00:ff:ff:ff:ff:ff:ff:ff], tid=0x5f541f, packet details: localAddr=[1:1:1:1::1]:0 remoteAddr=[2:2:2:2::2]:547
```
Similar inconsistency in these two log messages:
```
[kea-dhcp4.packets/2921701.140031535531776] DHCP4_RESPONSE_DATA [hwtype=1 00:00:00:ff:ff:ff], cid=[00:00:00:00:ff:ff:ff:ff:ff:ff:ff], tid=0xfe456e5f: responding with packet DHCPACK (type 5), packet details: local_address=1.2.3.4:67, remote_address=1.2.3.5:68, msg_type=DHCPACK (5), transid=0xfe456e5f,
```
and
```
[kea-dhcp6.packets/3264085.139762070353664] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[1:1:1:1::1]:547 remoteAddr=[2:2:2:2::2]:547
```
Perhaps this is this way for a reason? There are, of course, differences between DHCPv4 and DHCPv6.
[SF1375](https://isc.lightning.force.com/lightning/r/Case/5007V00002YkWE4QAN/view)kea2.5.4Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3068CA returns number overflow on ipv6 stats2023-10-12T08:04:56ZPeter DaviesCA returns number overflow on ipv6 statsSending a statistic-get command IPv6 statistics to the control-agent can cause a
number overflow error to be returned to the caller.
Sending the command directly to the Kea process's control socket does not generate
this error.
...Sending a statistic-get command IPv6 statistics to the control-agent can cause a
number overflow error to be returned to the caller.
Sending the command directly to the Kea process's control socket does not generate
this error.
[RT #22759]( https://support.isc.org/Ticket/Display.html?id=22759)kea2.5.3Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3048Matching of case for ASCII content2023-09-22T13:36:44ZDarren AnkneyMatching of case for ASCII contentSometimes administrators will want to match some arbitrary content for reservations or classes. For example, they may want to match on remote id. There may be some differences between equipment with how this content is added to remote ...Sometimes administrators will want to match some arbitrary content for reservations or classes. For example, they may want to match on remote id. There may be some differences between equipment with how this content is added to remote id.
- Device 1 remote ID content: `some ascii string` Hex: `736F6D6520617363696920737472696E67`
- Device 2 remote ID content: `SOME ASCII STRING` Hex: `534F4D4520415343494920535452494E47`
Currently, Kea is only able to match these based on the hexadecimal content of the remote ID field. At no time is Kea able to decode these as it has no way to know how it was encoded. Therefore the administrator cannot predict what the match will be in advance. In ISC DHCP, one might match like this: `ucase(binary-to-ascii(10,8,option agent.remote-id)) = "SOME ASCII STRING"` where the string would first be converted to ASCII and then converted to all uppercase letters so that strings would be, in a sense, case insensitive.
Suggest to add some equivalent of these functions to Kea so that matches could be done in a similar way.
Relevant ISC DHCP functions:
**binary-to-ascii (numeric-expr1, numeric-expr2, data-expr1, data-expr2)**
Converts the result of evaluating data-expr2 into a text string containing one number for each element of the result of evaluating data-expr2. Each number is separated from the other by the result of evaluating data-expr1. The result of evaluating numeric-expr1 specifies the base (2 through 16) into which the numbers should be converted. The result of evaluating numeric-expr2 specifies the width in bits of each number, which may be either 8, 16 or 32.
As an example of the preceding three types of expressions, to produce the name of a PTR record for the IP address being assigned to a client, one could write the following expression:
concat (binary-to-ascii (10, 8, ".",
reverse (1, leased-address)),
".in-addr.arpa.");
**lcase (data-expr)**
The lcase function returns the result of evaluating data-expr converted to lower case. If data-expr evaluates to null, then the result is also null.
**ucase (data-expr)**
The ucase function returns the result of evaluating data-expr converted to upper case. If data-expr evaluates to null, then the result is also null.
[SF1172](https://isc.lightning.force.com/lightning/r/Case/5007V00002VW9pgQAD/view)kea2.5.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2995[ISC-support #22440] ARM fix needed for perfdhcp's -D option2023-08-04T16:15:15ZEverett Fulton[ISC-support #22440] ARM fix needed for perfdhcp's -D optionA customer has noticed a discrepancy in the [ARM:](https://kea.readthedocs.io/en/kea-2.4.0/man/perfdhcp.8.html#options-controlling-a-test)
`Use -D 0 to abort if even a single request has been dropped. "max-drop" must be a positive intege...A customer has noticed a discrepancy in the [ARM:](https://kea.readthedocs.io/en/kea-2.4.0/man/perfdhcp.8.html#options-controlling-a-test)
`Use -D 0 to abort if even a single request has been dropped. "max-drop" must be a positive integer.`
An error is generated if `-D 0` is used. In chat with SWENG, it was stated that `-D 1` should be used instead.kea2.5.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2982Missing subnet4-update message2023-08-16T14:41:34ZPeter DaviesMissing subnet4-update messageMissing subnet4-update message:
In Kea 2.4.0:
The subnet commands hooks libraries generate a the following message on successfull
completion of a "subnet4-get" command:
```
SUBNET_CMDS_SUBNET_GET successfully retrieved sub...Missing subnet4-update message:
In Kea 2.4.0:
The subnet commands hooks libraries generate a the following message on successfull
completion of a "subnet4-get" command:
```
SUBNET_CMDS_SUBNET_GET successfully retrieved subnet ...
```
However no message is generated on completion of a "subnet4-update" command.
[RT #22374](https://support.isc.org/Ticket/Display.html?id=22374)kea2.5.1Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/2968missing documentation: subnet selection by interface.2023-08-21T16:14:55ZDarren Ankneymissing documentation: subnet selection by interface.In the ARM under [8.4. Shared Networks in DHCPv4](https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#shared-networks-in-dhcpv4), it is indirectly shown how interface may be specified at the subnet level as a hint during subnet se...In the ARM under [8.4. Shared Networks in DHCPv4](https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#shared-networks-in-dhcpv4), it is indirectly shown how interface may be specified at the subnet level as a hint during subnet selection while talking about what not to do. However, in the ARM under [8.6. How the DHCPv4 Server Selects a Subnet for the Client](https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#how-the-dhcpv4-server-selects-a-subnet-for-the-client), this is not mentioned.
It is mentioned in [DHCPv4 Subnet Selection](https://kea.readthedocs.io/en/kea-2.4.0/umls.html#dhcpv4-subnet-selection) diagram in the appendix. The corresponding DHCPv6 section on subnet selection ([9.2.18. IPv6 Subnet Selection](https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp6-srv.html#ipv6-subnet-selection)) shows the possibility.
I couldn't find documentation of interface being allowed in DHCPv4 subnet {} block as a hint for subnet selection anywhere else in the ARM.
[RT22363](https://support.isc.org/Ticket/Display.html?id=22363)kea2.5.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2918ISC DHCP log emulation2023-10-06T17:12:30ZPeter DaviesISC DHCP log emulation---
name: ISC DHCP log emulation
about: Kea to generate logging similar ISC DCHP.
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
Kea's forensic logging hooks library ...---
name: ISC DHCP log emulation
about: Kea to generate logging similar ISC DCHP.
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
Kea's forensic logging hooks library can be configured generate messages that look
like ISC DHCP logging but DHCPDISCOVER/DHCPOFFER and SOLICIT/ADVERTISE
packets are not logged.
**Is your feature request related to a problem? Please describe.**
As a help to folks who are planning to migrate from ISC DCHP to Kea it may be helpful if
Kea could be induced to produce logging that approximate those generated by ISC DCHP.
**Describe the solution you'd like**
There appear to be two ways forward:
1) Enhance Kea's forensic logging hooks library.
2) Generate new logging messages at severity INFO
**Additional context**
See [RT #22155](https://support.isc.org/Ticket/Display.html?id=22155)kea2.5.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2913Section 8.2.10 of the ARM contains a typo2023-07-17T13:58:20ZDarren AnkneySection 8.2.10 of the ARM contains a typoThis [table](https://kea.readthedocs.io/en/kea-2.3.8/arm/dhcp4-srv.html#id3) contains a typo for option 50. It says the type is `ipv6-address`. It should be `ipv4-address`.
[RT22158](https://support.isc.org/Ticket/Display.html?id=22158)This [table](https://kea.readthedocs.io/en/kea-2.3.8/arm/dhcp4-srv.html#id3) contains a typo for option 50. It says the type is `ipv6-address`. It should be `ipv4-address`.
[RT22158](https://support.isc.org/Ticket/Display.html?id=22158)kea2.4.0Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/kea/-/issues/2908DEBUG DHCP4_CLASS_ASSIGNED fails to log properly in kea-dhcp4.dhcp4 with shar...2023-08-03T14:35:27ZDarren AnkneyDEBUG DHCP4_CLASS_ASSIGNED fails to log properly in kea-dhcp4.dhcp4 with shared-networksIf a subnet is part of a shared-networks definition, then classes assigned by reservations are not logged in the DHCP4_CLASS_ASSIGNED messages. This simple configuration:
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces"...If a subnet is part of a shared-networks definition, then classes assigned by reservations are not logged in the DHCP4_CLASS_ASSIGNED messages. This simple configuration:
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "ens256" ]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/tmp/all-dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"client-classes": [
{
"name": "someclass",
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
]
}
],
"shared-networks": [
{
"name": "some-shared-network",
"subnet4": [
{
"subnet": "10.1.2.0/24",
"reservations": [
{
"client-classes": [
"someclass"
],
"hw-address": "00:0c:01:02:03:04",
"ip-address": "10.1.2.133",
}
]
}
]
}
]
}
}
```
results in logs like this:
```
2023-06-06 12:36:47.547 DEBUG [kea-dhcp4.dhcp4/4418.281472760196992] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x2b: client packet has been assigned to the following class(es): KNOWN
2023-06-06 12:36:47.547 DEBUG [kea-dhcp4.dhcp4/4418.281472760196992] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x2b: client packet has been assigned to the following class(es): ALL, KNOWN
```
even though the client is added to the class as evidenced by the presence of the 10.1.2.1 routers option in the packet:
```
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.dhcp4/4553.281472785596288] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x189: client packet has been assigned to the following class(es): KNOWN
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.dhcp4/4553.281472785596288] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x189: client packet has been assigned to the following class(es): ALL, KNOWN
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.ddns/4553.281472785596288] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x189: processing client's Hostname option
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.dhcpsrv/4553.281472785596288] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:00:0c:01:02:03:04
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.hosts/4553.281472785596288] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 10.1.2.133
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.hosts/4553.281472785596288] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.1.2.133
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.hosts/4553.281472785596288] HOSTS_CFG_GET_ALL_ADDRESS4_HOST using address 10.1.2.133 found host: hwaddr=000C01020304 ipv4_subnet_id=1 hostname=(empty) ipv4_reservation=10.1.2.133 siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none) dhcp4_class0=someclass
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.hosts/4553.281472785596288] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.1.2.133, found 1 host(s)
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.hosts/4553.281472785596288] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_HOST using subnet id 1 and address 10.1.2.133, found host: hwaddr=000C01020304 ipv4_subnet_id=1 hostname=(empty) ipv4_reservation=10.1.2.133 siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none) dhcp4_class0=someclass
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.dhcpsrv/4553.281472785596288] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.1.2.133
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.alloc-engine/4553.281472785596288] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x189: extending lifetime of the lease for address 10.1.2.133
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.dhcpsrv/4553.281472785596288] DHCPSRV_MEMFILE_UPDATE_ADDR4 updating IPv4 lease for address 10.1.2.133
2023-06-06 12:57:39.715 INFO [kea-dhcp4.leases/4553.281472785596288] DHCP4_LEASE_ALLOC [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x189: lease 10.1.2.133 has been allocated for 7200 seconds
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.options/4553.281472785596288] DHCP4_PACKET_PACK [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x189: preparing on-wire format of the packet to be sent
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.packets/4553.281472785596288] DHCP4_PACKET_SEND [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x189: trying to send packet DHCPACK (type 5) from 10.1.2.2:67 to 10.1.2.6:67 on interface ens256
2023-06-06 12:57:39.715 DEBUG [kea-dhcp4.packets/4553.281472785596288] DHCP4_RESPONSE_DATA [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x189: responding with packet DHCPACK (type 5), packet details: local_address=10.1.2.2:67, remote_address=10.1.2.6:67, msg_type=DHCPACK (5), transid=0x189,
options:
type=001, len=004: 4294967040 (uint32)
type=003, len=004: 10.1.2.1
type=051, len=004: 7200 (uint32)
type=053, len=001: 5 (uint8)
type=054, len=004: 10.1.2.2
type=061, len=007: 01:00:0c:01:02:03:04
```
being present in the DHCPACK
Remove the shared-networks as shown:
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "ens256" ]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/tmp/all-dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"client-classes": [
{
"name": "someclass",
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
]
}
],
"subnet4": [
{
"subnet": "10.1.2.0/24",
"reservations": [
{
"client-classes": [
"someclass"
],
"hw-address": "00:0c:01:02:03:04",
"ip-address": "10.1.2.133",
}
]
}
]
}
}
```
And the log notes that the client has been added to 'someclass':
```
2023-06-06 12:54:14.715 DEBUG [kea-dhcp4.dhcp4/4512.281473095200640] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0xbc: client packet has been assigned to the following class(es): KNOWN
2023-06-06 12:54:14.715 DEBUG [kea-dhcp4.dhcp4/4512.281473095200640] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0xbc: client packet has been assigned to the following class(es): ALL, someclass, KNOWN
```
[RT22139](https://support.isc.org/Ticket/Display.html?id=22139)kea2.5.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2904output_options document update2023-09-18T08:08:08ZPeter Daviesoutput_options document update
---
name: Bug report
about: output_options document update
---
**Describe the bug**
One of our astute users has pointed out that the "output_options" keyword contains
an underscore, whereas other configuration keywords use a hyp...
---
name: Bug report
about: output_options document update
---
**Describe the bug**
One of our astute users has pointed out that the "output_options" keyword contains
an underscore, whereas other configuration keywords use a hyphen. In the Kea ARM,
there are examples of usage of "output_options" and "output-options."
**To Reproduce**
Steps to reproduce the behaviour:
Start Kea with the following "loggers" definition
```
"loggers": [ {
"name": "kea-dhcp4",
"output-options": [ { "output": "./kea-dhcp4.log" } ],
"severity": "DEBUG", "debug level": 99 }]
```
Kea will exit with the following error message:
```
DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file 'kea-template.json': kea-template.json:60.17-32: got unexpected keyword "output-options" in loggers map.
```
[RT #22138](https://support.isc.org/Ticket/Display.html?id=22138)kea2.5.1https://gitlab.isc.org/isc-projects/kea/-/issues/2866Print warning if subnet IDs do not exist in one or more subnets2023-07-17T13:58:20ZDarren AnkneyPrint warning if subnet IDs do not exist in one or more subnets
- **name:** Warn about missing subnet IDs
- **about:** Print a warning at startup if subnet IDs are not configured with one or more subnets
If subnet IDs are not added to the configuration, then strange behaviors can happen when the su...
- **name:** Warn about missing subnet IDs
- **about:** Print a warning at startup if subnet IDs are not configured with one or more subnets
If subnet IDs are not added to the configuration, then strange behaviors can happen when the subnet order is changed or a new subnet is added.
Consider this partial configuration:
```
"subnet4": [
{
"subnet": "10.1.3.0/24",
"pools": [
{
"pool": "10.1.3.100 - 10.1.3.200"
}
]
},
{
"subnet": "10.1.2.0/24",
"pools": [
{
"pool": "10.1.2.100 - 10.1.2.200"
}
]
}
]
```
Client gets a lease as recorded in the leases file:
```
10.1.2.124,00:0c:29:9e:4f:41,,300,1684442616,2,0,0,perfdhcp1,0,
```
Note that the subnet id recorded was 2. Now re-order the subnets:
```
"subnet4": [
{
"subnet": "10.1.2.0/24",
"pools": [
{
"pool": "10.1.2.100 - 10.1.2.200"
}
]
},
{
"subnet": "10.1.3.0/24",
"pools": [
{
"pool": "10.1.3.100 - 10.1.3.200"
}
]
}
]
```
Now the client comes back and requests the previous address `10.1.2.124` and receives a NAK. Then a discover follows and a new address is allocated with the new subnet id of 1:
```
10.1.2.120,00:0c:29:9e:4f:41,,300,1684442746,1,0,0,perfdhcp1,0,
```
The above example was produced with Kea 2.3.7 using memfile lease-database. The problems get much worse if there are multiple Kea servers using a shared mysql or postgres lease-database.
A WARNING printed when the server starts and one or more subnets are missing a subnet ID in the style of the one printed for the development versions:
```
2023-05-18 20:52:41.379 WARN [kea-dhcp4.dhcp4/243124.281473000751120] DHCP4_DEVELOPMENT_VERSION This software is a development branch of Kea. It is not recommended for production use.
```
would help with this situation. Many administrators may not be aware of the problems this can cause.
[RT22065](https://support.isc.org/Ticket/Display.html?id=22065)kea2.4.0Marcin SiodelskiMarcin Siodelski