Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-26T21:44:52Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3314RBAC: Omitting configuration option results in logged error2024-03-26T21:44:52ZDarren AnkneyRBAC: Omitting configuration option results in logged errorThe configuration directive `"response-filters"` seems to be de facto required whereas the ARM seems to imply that this parameter should be optional as it shows examples where the parameter is not present (see the extensive example). It...The configuration directive `"response-filters"` seems to be de facto required whereas the ARM seems to imply that this parameter should be optional as it shows examples where the parameter is not present (see the extensive example). It doesn't actually say whether the parameter is required or optional, however.
Omitting the directive causes this error:
```
[kea-ctrl-agent.callouts/401411.129873316435840] HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook response registered by library with index 1 (callout address 0x761e7c475880): unable to find callout context associated with the current library index (1) (callout duration: 0.047 ms)
```
The error does not seem to cause any harm as the operations still seem to be performed. This can fill up the logs though if there is a lot of API access (such as in the case of Stork).
Adding the directive to the roles configuration(s) removes the error.
[SF1816](https://isc.lightning.force.com/lightning/r/Case/500S6000007Ho67IAC/view)Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3289DHCPv4: bad option 81 data (invalid FQDN) causes halt in further processing o...2024-03-14T15:00:06ZDarren AnkneyDHCPv4: bad option 81 data (invalid FQDN) causes halt in further processing of packetA packet with option 81 attached with an empty label causes further processing of the client's DHCPv4 packet to cease and the packet to be dropped.
This is very simple to reproduce with the following
<details><summary>Simple configurat...A packet with option 81 attached with an empty label causes further processing of the client's DHCPv4 packet to cease and the packet to be dropped.
This is very simple to reproduce with the following
<details><summary>Simple configuration</summary>
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"calculate-tee-times": true,
"option-data": [
{
"name": "domain-name-servers",
"data": "10.0.0.1"
}
],
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100-10.1.2.200"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "DEBUG",
"debuglevel": 99,
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
and sending packets with malformed FQDN using `perfdhcp`:
```
perfdhcp -4 -r 1 -p 10 -l ens256 -R 1 -o 81,0100002E656D7074792E6C6162656C2E6578616D706C652E636F6D
```
<details><summary>Messages like this are logged</summary>
```
2024-03-13 11:21:28.124 DEBUG [kea-dhcp4.packets/52340.281473684041744] DHCP4_BUFFER_RECEIVED received buffer from 10.1.2.6:67 to 255.255.255.255:67 over interface ens256
2024-03-13 11:21:28.124 DEBUG [kea-dhcp4.options/52340.281473642041216] DHCP4_BUFFER_UNPACK parsing buffer received from 10.1.2.6 to 255.255.255.255 over interface ens256
2024-03-13 11:21:28.124 DEBUG [kea-dhcp4.bad-packets/52340.281473642041216] DHCP4_PACKET_DROP_0001 failed to parse packet from 10.1.2.6 to 255.255.255.255, received over interface ens256, reason: failed to parse the domain-name in DHCPv4 Client FQDN Option: non terminating empty label in .empty.label.example.com, hwaddr=00:0c:01:02:03:04
```
</details>
Clients with such incorrect FQDNs in option 81 are not able to get an IP address. Option 81 content from such clients is probably not useable and should perhaps be ignored but the client should still get an IP address possibly? This type of error in option 81 was allowed in ISC DHCP and so this is a problem for those migrating to Kea from ISC DHCP.
Attached a pcap of the DHCP packets generated by `perfdhcp`: [fqdn-test.pcap](/uploads/810d5aa88d78f58f1c4b39d6b1eec3d1/fqdn-test.pcap)
[SF1790](https://isc.lightning.force.com/lightning/r/Case/500S6000006lxqtIAA/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3283CableLabs option (RFC3495): Inconsistent "option_def" usage in client class d...2024-03-27T20:44:57ZPeter DaviesCableLabs option (RFC3495): Inconsistent "option_def" usage in client class definitionsInconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"opt...Inconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" }
],
...
```
However, if this "option-def" is defined within a client class as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
The following message is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '122' in space 'dhcp4'
```
If the "Option_122" "option-def" is changed to private option "224" as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 224, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
Then the following error is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '1' in space 'Option_122_Space'
```
[SF00001775](https://isc.lightning.force.com/lightning/r/Case/500S6000006TLtj/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3282Support option-data based on client class AND subnet2024-03-14T14:49:00ZDarren AnkneySupport option-data based on client class AND subnetScenario: A class of clients (ACME Phones) need to receive option 225 "foo" with string content. This string needs to vary depending on the subnet selected. The option-data must not be offered to clients that are NOT ACME Phones.
<det...Scenario: A class of clients (ACME Phones) need to receive option 225 "foo" with string content. This string needs to vary depending on the subnet selected. The option-data must not be offered to clients that are NOT ACME Phones.
<details><summary>Current solution:</summary>
```
{
"Dhcp4": {
"option-def": [
{
"name": "foo",
"code": 225,
"type": "string",
}
],
"client-classes": [
{
"name": "ACMEphone",
"test": "option[60].hex == 'ACME IP Phone'",
"option-data": [
{
"name": "foo",
"data": "'some string 1'"
}
],
"only-if-required": true
},
{
"name": "ACMEphone2",
"test": "option[60].hex == 'ACME IP Phone'",
"option-data": [
{
"name": "foo",
"data": "'some string 2'"
}
],
"only-if-required": true
}
],
"subnet4": [
{
"id": 1,
"subnet": "192.0.2.0/24",
"require-client-classes": [
"ACMEphone"
],
"pools": [
{
"pool": "192.0.2.2 - 192.0.2.254"
}
]
},
{
"id": 2,
"subnet": "192.0.3.0/24",
"require-client-classes": [
"ACMEphone2"
],
"pools": [
{
"pool": "192.0.3.2 - 192.0.3.254"
}
]
}
]
}
}
```
</details>
This solution works but requires adding one client-class per subnet that will need to provide differing parameters to the class of clients in question on a per subnet basis.
This scenario is quite common and was handled previously in ISC DHCP with "if" statements where an "if" statement would be dropped into a subnet as necessary for the clients that might appear there that needed some option content provided with values specific to the subnet selected.
[SF1773](https://isc.lightning.force.com/lightning/r/Case/500S6000006NkOVIA0/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3257ddns-update-on-renew and cache-threshold still produce ddns updates2024-03-27T12:52:01ZDarren Ankneyddns-update-on-renew and cache-threshold still produce ddns updatesIf a Kea server (2.4.1) has these settings:
```
...
"cache-threshold": 0.25,
"ddns-update-on-renew": true,
...
```
and a client renews their lease at under 25% of the lease length, ddns updates are still sent.
```
$ sudo tail -f /var/lo...If a Kea server (2.4.1) has these settings:
```
...
"cache-threshold": 0.25,
"ddns-update-on-renew": true,
...
```
and a client renews their lease at under 25% of the lease length, ddns updates are still sent.
```
$ sudo tail -f /var/log/kea/kea-dhcp4.log | egrep 'DHCP4_LEASE_REUSE|DHCPSRV_DHCP_DDNS_NCR_SENT'
2024-02-15 16:46:35.032 INFO [kea-dhcp4.leases/1192.140241126283008] DHCP4_LEASE_REUSE [hwtype=1 c8:7f:54:9e:cf:c8], cid=[01:c8:7f:54:9e:cf:c8], tid=0x17c6ef6f: lease 192.168.20.20 has been reused for 24845 seconds
2024-02-15 16:46:35.033 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 1 (CHG_REMOVE)
2024-02-15 16:46:35.033 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 0 (CHG_ADD)
2024-02-15 16:46:40.807 INFO [kea-dhcp4.leases/1192.140241159853824] DHCP4_LEASE_REUSE [hwtype=1 c8:7f:54:9e:cf:c8], cid=[01:c8:7f:54:9e:cf:c8], tid=0xfbfead04: lease 192.168.20.20 has been reused for 24840 seconds
2024-02-15 16:46:40.807 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 1 (CHG_REMOVE)
2024-02-15 16:46:40.808 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 0 (CHG_ADD)
```
The customer who brought this to our attention notes:
> While looking at some customer logs I noticed that we were both reusing a lease and doing DDNS update for that reused lease. It seems like if a lease is being reused and therefore it doesn't have any changes to the client DNS name that Kea shouldn't redo the DDNS even if the configuration has update on renew enabled. As soon as the device renews outside of the threshold window I would expect it to do a DDNS update based on the update on renew option.
I've looked at the code and the design. It appears that in dhcp4_srv.cc:assignLease() the call to createNameChangeRequests() is called without checking the threshold and the threshold isn't checked within that function.
The design doesn't explicitly say anything but seems to suggest that the DDNS update shouldn't be done if a lease is reused.
I am unsure if this is a feature request or a bug report as I am not sure of the intended behavior here. It seems like it would be preferable to reduce load by not sending ddns updates on a reused lease.
[SF1707](https://isc.lightning.force.com/lightning/r/Case/500S6000005OUblIAG/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3255CA reconfig doesn't pick up on new certificates2024-02-22T15:00:09ZPeter DaviesCA reconfig doesn't pick up on new certificatesCA reconfig doesn't pick up on new certificates:
After changing the certificates directory in the kea-ctrl-agent configuration
file and sending a SIGHUP signal, kea-ctrl-agent reports
DCTL_CONFIG_COMPLETE server has completed...CA reconfig doesn't pick up on new certificates:
After changing the certificates directory in the kea-ctrl-agent configuration
file and sending a SIGHUP signal, kea-ctrl-agent reports
DCTL_CONFIG_COMPLETE server has completed configuration:
However, the agent still uses the old certificates:
Users that employ the systemd restart command may expect a different behaviour
A workaround would be to kill the process and restart a new one.
[000016830](https://isc.lightning.force.com/lightning/r/Case/500S60000055eAC/view)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3250Unattended terminated state and a reboot2024-03-27T21:53:51ZMarcin SiodelskiUnattended terminated state and a rebootConsider the following case. The clocks on two HA-enabled servers diverge and the clock skew eventually exceeds 60 seconds. As a result, both servers transition to the terminated state. In this state, the servers continue serving DHCP cl...Consider the following case. The clocks on two HA-enabled servers diverge and the clock skew eventually exceeds 60 seconds. As a result, both servers transition to the terminated state. In this state, the servers continue serving DHCP clients but do not exchange the lease updates nor heartbeats. An administrator neglects to correct the clocks and one of the servers reboots. The server enters the `waiting` state and remains in this state hoping that the other server is restarted so they can continue the lease database synchronization and start normal operation. However, the server is unaware that its reboot was not triggered in the course of fixing the clocks, so it will wait for the partner endlessly (or until the administrator comes to work in the morning). The waiting server is not responding to the DHCP traffic until then.
This situation should not occur in a setup where NTP has been enabled. It also should not occur if there is a proper monitoring to detect that the clocks diverge early enough. However, there are chances this situation may happen when all of this is neglected.
The proposed solution is to apply a timeout (could even be several to 10 minutes long) for a server in the waiting state. If the transition of its partner does not occur until this timeout elapses, the server in the waiting state transitions back to the terminated state and continues serving the clients. The waiting server MUST NOT transition to the waiting state immediately after it detects that its partner is in the terminated state to allow enough time to the administrator to reboot the server sequentially after correcting the clocks.
[SF1598](https://isc.lightning.force.com/lightning/r/Case/500S6000003jBs3IAE/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3247changes in hammer for rocky linux2024-03-28T08:11:54ZMarcin Godzinachanges in hammer for rocky linuxWe need to extend Hammer to build on Rocky Linux 9. We have a business need for this.We need to extend Hammer to build on Rocky Linux 9. We have a business need for this.kea2.5.8Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/3246DHCPRELEASE and lease expiration in active-standby HA setup2024-03-27T12:53:48ZPeter DaviesDHCPRELEASE and lease expiration in active-standby HA setupDHCPvRELEASE lease expiration in active-standby HA setup
Kea 2.5.5
When a client sends a DHCPRELEASE message to a Kea primary HA server, the expired
lease processing settings are honoured.
However, the primary updates the...DHCPvRELEASE lease expiration in active-standby HA setup
Kea 2.5.5
When a client sends a DHCPRELEASE message to a Kea primary HA server, the expired
lease processing settings are honoured.
However, the primary updates the failover server with instructions to delete the
lease.
This leads to a divergence of lease data between the two servers.
[SF00001636](https://isc.lightning.force.com/lightning/r/Case/500S6000004XPRy/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3244Allow redefine of standard DHCP options2024-03-07T12:07:26ZDarren AnkneyAllow redefine of standard DHCP optionsCurrently, it isn't possible to redefine any standard DHCP option that is defined in Kea. This is a good practice because it prevents administrators from shooting themselves in the foot. However, DHCPv4 is quite old and there have been...Currently, it isn't possible to redefine any standard DHCP option that is defined in Kea. This is a good practice because it prevents administrators from shooting themselves in the foot. However, DHCPv4 is quite old and there have been some newer RFCs that define options that vendors previously could freely use.
An example of this is an older vendor of IP phones who used option 156 with some of their equipment. Option 156 is part of Bulk Lease Query now ([RFC 6926](https://datatracker.ietf.org/doc/html/rfc6926)) since about 2013. This IP phone manufacturer existed from 1998, however. This option was not defined in ISC DHCP, and so could be used there. The option is defined in Kea, though not presently used. Option 156, in the RFC, is defined as containing an integer as a flag of sorts. The old IP phone vendor needs option 156 to contain a string of some kind. This is only an example. This is probably not a one-off situation.
It is unreasonable to require administrators to purchase new equipment as part of the move to Kea, and therefore, it would be better to, in some way, allow the redefine of standard options. This should probably be a deliberate act somehow, perhaps requiring a keyword of some sort, so that the administrator is aware of what they are doing.
[SF1626](https://isc.lightning.force.com/lightning/r/Case/500S6000004IKcWIAW/view)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3239New Global Counter assigned-addresses2024-03-27T12:53:11ZPeter DaviesNew Global Counter assigned-addressesFeature Request: New Global Counter assigned-addresses
Statistics return per subnet counters "assigned-addresses" and "cumulative-assigned-addresses".
However, globally, only the cumulative-assigned-addresses counter is retu...Feature Request: New Global Counter assigned-addresses
Statistics return per subnet counters "assigned-addresses" and "cumulative-assigned-addresses".
However, globally, only the cumulative-assigned-addresses counter is returned.
It may interest administrators to know the total number of assigned addresses per
server.
[SF00001629](https://isc.lightning.force.com/lightning/r/Case/500S6000004QXmC/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3213Feature request: statistics-get-all-global command to get all of the global s...2024-03-27T12:51:29ZCathy AlmondFeature request: statistics-get-all-global command to get all of the global stats without any of the subnet stats---
name: statistics-get-all-global command
about: `statistics-get-all-global` command (or similar) to get all of the global statistics without any of the subnet statistics
---
It would also be useful to have something like "statistics...---
name: statistics-get-all-global command
about: `statistics-get-all-global` command (or similar) to get all of the global statistics without any of the subnet statistics
---
It would also be useful to have something like "statistics-get-all-global" command to get all of the global stats but not all of the subnet (or pool if they get added) stats. We have scenarios with multiple 100s of subnets and for those "get-all" can get unwieldy.
See [SF1429](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyA1sQAF/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3140Feature request: Add Statistics Counters for dropped packets (for various dif...2024-03-27T12:51:09ZCathy AlmondFeature request: Add Statistics Counters for dropped packets (for various different reasons)---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
...---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
This is loosely related to issue #3125 for counting some dropped packets due to HA (#3125 is more about not logging them unnecessarily though, or being able to disable the per-event logging).
This is a request to add a specific packet counts for both HA and for other dropped packets such as ones dropped due to kea being disabled.
Customer requesting this feature currently has an issue where they can't tell if an operator has misconfigured their network such that Kea wasn't receiving any traffic or if it was in a disabled state due to Kea HA sync.
Version 2.2
See [SF1429](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyA1sQAF/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3125HA ignored packets cause DROP statistics counter increment2024-03-27T12:58:00ZDarren AnkneyHA ignored packets cause DROP statistics counter incrementHA_BUFFER6_RECEIVE_NOT_FOR_US increments drop counters.
- This happens at least with a load balancing configuration.
- I think maybe not with hot-standby since I don't think the service logs anything or cares about incoming client pack...HA_BUFFER6_RECEIVE_NOT_FOR_US increments drop counters.
- This happens at least with a load balancing configuration.
- I think maybe not with hot-standby since I don't think the service logs anything or cares about incoming client packets unless it loses contact with the HA peer?
- I cite BUFFER6 above but I'm sure the same is true for DHCPv4.
Possible solutions:
- introduce a new drop status that could be discounted later or part of a different drop statistic?
- Could introduce new status that it is ignored or filtered instead of dropped?
[SF1374](https://isc.lightning.force.com/lightning/r/Case/5007V00002YkO0oQAF/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3098Effect of behavioural parameters when ddns is disabled:2024-03-27T12:58:34ZPeter DaviesEffect of behavioural parameters when ddns is disabled:
Effect of behavioural parameters when ddns is disabled:
There are a number of behavioural parameters which control what gets sent to d2.
Some settings also control what is returned to the client and saved as the host-
name in th...
Effect of behavioural parameters when ddns is disabled:
There are a number of behavioural parameters which control what gets sent to d2.
Some settings also control what is returned to the client and saved as the host-
name in the lease information.
Setting "dhcp-ddns.enable-updates": false turns off ddns, but some of these settings
remain active.
For example, the "ddns-qualifying-suffix" setting may affect hostnames even if
ddns are disabled. It has been brought to our attention that this is not clearly
documented in the ARM.
RT [#22818](https://support.isc.org/Ticket/Display.html?id=22818)
SF [#00001287](https://isc.lightning.force.com/lightning/r/Case/5007V00002XcaY4QAJ/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3082kea-ctrl-agent and dual stack listening2024-03-21T11:45:53ZDarren Ankneykea-ctrl-agent and dual stack listeningThe `kea-ctrl-agent` can presently only listen on one address, be that an IPv4 or IPv6 address. If you have a dual stack on the equipment where you want to listen, then you have to choose either the IPv4 or the IPv6 address to configure...The `kea-ctrl-agent` can presently only listen on one address, be that an IPv4 or IPv6 address. If you have a dual stack on the equipment where you want to listen, then you have to choose either the IPv4 or the IPv6 address to configure in the `kea-ctrl-agent.json`.
I propose to add a new parameter to the kea-ctrl-agent configuration "http-hosts" as shown:
```
{
"Control-agent": {
"http-hosts": [
"2001:db8::2",
"10.1.2.2"
],
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
This would allow listening on multiple IP addresses especially in a dual stack environment. Also, the new parameter would preserve backward compatibility.
FYI: I did solve this problem by running two copies of the `kea-ctrl-agent`. However, I'm not convinced that is a good solution. Configurations and other details included below for illustration.
<details><summary>kea-dhcp4.json</summary>
```
{
"Dhcp4": {
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
},
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100 - 10.1.2.254"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "INFO",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>kea-ctrl-agent-v4.json</summary>
```
{
"Control-agent": {
"http-host": "10.1.2.2",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
</details>
<details><summary>kea-ctrl-agent-v6.json</summary>
```
{
"Control-agent": {
"http-host": "2001:db8::2",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
</details>
<details><summary>Configuration of ens256</summary>
```
3: ens256: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:c0:5f:47 brd ff:ff:ff:ff:ff:ff
altname enp26s0
inet 10.1.2.2/24 brd 10.1.2.255 scope global ens256
valid_lft forever preferred_lft forever
inet6 2001:db8::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fec0:5f47/64 scope link
valid_lft forever preferred_lft forever
```
</details>
<details><summary>Daemon command lines</summary>
```
kea-dhcp4 -c kea-dhcp4.json
```
```
kea-ctrl-agent -c kea-ctrl-agent-v4.json
```
```
kea-ctrl-agent -c kea-ctrl-agent-v6.json
```
</details>
<details><summary>Send config-get with curl to both</summary>
```
curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://10.1.2.2:8000/ | jq
```
```
curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://[2001:db8::2]:8000/
```
</details>
Both returned a result successfully.
[SF1260](https://isc.lightning.force.com/lightning/r/Case/5007V00002X2x4cQAB/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3047Detection of packet processing slowdown2024-03-22T13:16:46ZDarren AnkneyDetection of packet processing slowdownSometimes Kea will find itself unable to keep up with incoming packet load for various reasons (overwhelming amounts of packets in an avalanche scenario, slowdown in SQL queries in the case of database usage, and etc). Kea currently has...Sometimes Kea will find itself unable to keep up with incoming packet load for various reasons (overwhelming amounts of packets in an avalanche scenario, slowdown in SQL queries in the case of database usage, and etc). Kea currently has no way to detect or warn about this situation. Detailed analysis of the logs is necessary to understand what is happening. This issue is meant to provide some ideas for future development in this area where Kea could possibly detect this situation and provide warning log messages about it.
Possible ideas:
1. Add timestamps to received packets (possible? [perhaps](https://www.kernel.org/doc/Documentation/networking/timestamping.txt)) as they are put into the buffer. Check these timestamps against the current time as they are pulled out of the buffer. If there is some discrepancy that is larger than some threshold, emit some kind of log message about this.
2. In `netstat -l` output, there is a representation of the current buffer size for a process. Example:
```
$ netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
...
udp 0 0 10.1.2.2:bootps 0.0.0.0:*
```
Administrators sometimes use this to find out if some process has a slowdown in processing packets. If the number is larger than normal, then there might be. Kea may not necessarily know what is normal, but there must be some maximum size of the Recv-Q. If so, perhaps this maximum size is being reached when these backups occur. If that could be detected, perhaps a warning message could be logged.
[RT22378](https://support.isc.org/Ticket/Display.html?id=22378)kea2.5.8Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2979RAI based flex-id reservations2024-03-27T12:56:42ZPeter DaviesRAI based flex-id reservationsRAI based flex-id reservations:
When providing dhcp services for customer equipment, maintaining a consistent IP
address is often desired even when customers replace their equipment.
Host reservations may be defined using a ...RAI based flex-id reservations:
When providing dhcp services for customer equipment, maintaining a consistent IP
address is often desired even when customers replace their equipment.
Host reservations may be defined using a flex-id host identifier based on some
RAI options; however, the lease data will typically contain the hw-address as
the identifier.
This works well until the customer replaces his equipment and there is an active
lease on the reserved address with the old client's hw-address. In this case,
Kea will regard this as an address conflict.
Enabling the "replace-client-id" flex-id flag can mitigate this; however, changing
the value of this flag on a running Kea server will cause address conflicts.
Is there a way to address this problem?
[RT #20140](https://support.isc.org/Ticket/Display.html?id=20140)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2976Implement the ISC DHCP stash-agent-options in Kea2024-03-27T12:56:52ZFrancis DupontImplement the ISC DHCP stash-agent-options in KeaSee #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the R...See #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the RAI from its user context. Requires some design but on the paper this should do the job...
Note this is for v4 only because v6 requires a specific setup on both the client and the server for direct unicast queries so the problem never occurs in the real world.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2863require-client-classes does not prioritize classes options2024-03-21T12:42:39ZMarcin Godzinarequire-client-classes does not prioritize classes optionsUsing `require-client-classes` does not prioritize options defined in classes.
I tried classifying clients by empty host reservations and by class test.
**Recreation:**
`00:03:00:01:f6:f5:f4:f3:f2:11` is sending Solicit and option 23 ...Using `require-client-classes` does not prioritize options defined in classes.
I tried classifying clients by empty host reservations and by class test.
**Recreation:**
`00:03:00:01:f6:f5:f4:f3:f2:11` is sending Solicit and option 23 requirements.
Kea responds with Advertise, including option 23.
I expect "2001:db8::2" in option 23, which is defined in the class, but receive "2001:db8::1" from the subnet.
Tested configs:
<details><summary>1 - using empty reservation (both with and without "only-if-required": true) </summary>
```
{
"Dhcp6": {
"subnet6": [
{
"subnet": "2001:db8:1::/64",
"pools": [
{
"pool": "2001:db8:1::1-2001:db8:1::1"
}
],
"interface": "enp0s9",
"option-data": [
{
"code": 23,
"csv-format": true,
"data": "2001:db8::1",
"name": "dns-servers",
"space": "dhcp6"
}
],
"require-client-classes": [
"blocked"
]
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"client-classes": [
{
"name": "blocked",
"option-data": [
{
"name": "dns-servers",
"data": "2001:db8::2"
}
]
}
],
"reservations": [
{
"duid": "00:03:00:01:f6:f5:f4:f3:f2:11",
"client-classes": [
"blocked"
]
}
],
"reservation-mode": "global",
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"lease-database": {
"type": "memfile"
}
}
}
```
</details>
<details><summary>2 - using class test (both with and without "only-if-required": true)</summary>
```
{
"Dhcp6": {
"subnet6": [
{
"subnet": "2001:db8:1::/64",
"pools": [
{
"pool": "2001:db8:1::1-2001:db8:1::1"
}
],
"interface": "enp0s9",
"option-data": [
{
"code": 23,
"csv-format": true,
"data": "2001:db8::1",
"name": "dns-servers",
"space": "dhcp6"
}
],
"require-client-classes": [
"blocked"
]
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"client-classes": [
{
"name": "blocked",
"test": "option[1].hex == 0x00030001f6f5f4f3f211",
"only-if-required": true,
"option-data": [
{
"name": "dns-servers",
"data": "2001:db8::2"
}
]
}
],
"reservations": [
{
"duid": "00:03:00:01:f6:f5:f4:f3:f2:11"
}
],
"reservation-mode": "global",
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"lease-database": {
"type": "memfile"
}
}
}
```
</details>next-stable-3.0