Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-01-19T14:45:45Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2686Minor: MultiThreadingMgr::[gs]etMode are not MT safe.2023-01-19T14:45:45ZFrancis DupontMinor: MultiThreadingMgr::[gs]etMode are not MT safe.TSAN reports a race on enabled_ in MultiThreadingMgr::getMode and MultiThreadingMgr::setMode. It is only an issue if we want the code to be race free i.e. TSAN no longer reporting any race.TSAN reports a race on enabled_ in MultiThreadingMgr::getMode and MultiThreadingMgr::setMode. It is only an issue if we want the code to be race free i.e. TSAN no longer reporting any race.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/72Radius option definitions2023-06-19T11:01:38ZGhost UserRadius option definitionsThe RadiusDesign calls for an optional mechanism that will query the Radius server about specific client. Typically this functionality has been done by a relay, which then inserted Radius options into DHCP message before forwarding it to...The RadiusDesign calls for an optional mechanism that will query the Radius server about specific client. Typically this functionality has been done by a relay, which then inserted Radius options into DHCP message before forwarding it to the server.
Kea should be able to understand such options. See RFC4014 (v4) and RFC7037 (v6) for details. Kea should be able to represent radius attributes as sub-options, so general mechanisms, like client classification could be used.
This ticket calls for option definitions only. No special handling logic should be implemented.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3315hooks should use their own IOService instance and register it with the main I...2024-03-29T08:37:22ZRazvan Becheriuhooks should use their own IOService instance and register it with the main IOServicerelated to https://gitlab.isc.org/isc-projects/kea/-/issues/3308
to properly load and run IOService poll so that configuration errors are detected before configuration is applied and to unload hooks and safely call all close callbacks, ...related to https://gitlab.isc.org/isc-projects/kea/-/issues/3308
to properly load and run IOService poll so that configuration errors are detected before configuration is applied and to unload hooks and safely call all close callbacks, a "local" IOService instance should be used by each hook. this guarantees that there can be no handlers referencing objects created in the hook that are called after hook unload.
hooks that use main io service:
premium:
* gss_tsig
* forensic_log
* lease_query
* ping_check
* radius
core:
* high_availability
* mysql_cb
* pbsql_cb
* run_script
all hooks requiring IOService should do the following:
```plaintext
int unload() {
if (getMainIOService()) {
getMainIOService()->unregisterExternalIOService(getIOService());
}
getIOService()->stop();
getIOService()->restart();
try {
getIOService()->poll();
} catch (...) {
}
...
}
int dhcp4_srv_configured(CalloutHandle& handle) {
handle.getArgument("io_context", getMainIOService());
if (!getMainIOService()) {
// Should not happen!
handle.setStatus(isc::hooks::CalloutHandle::NEXT_STEP_DROP);
const string error("Error: io_context is null");
handle.setArgument("error", error);
return (1);
}
...
getMainIOService()->registerExternalIOService(getIOService());
...
}
int dhcp6_srv_configured(CalloutHandle& handle) {
handle.getArgument("io_context", getMainIOService());
if (!getMainIOService()) {
// Should not happen!
handle.setStatus(isc::hooks::CalloutHandle::NEXT_STEP_DROP);
const string error("Error: io_context is null");
handle.setArgument("error", error);
return (1);
}
...
getMainIOService()->registerExternalIOService(getIOService());
...
}
void
IOService::registerExternalIOService(IOServicePtr io_service) {
external_io_services_.push_back(io_service);
}
void
IOService::unregisterExternalIOService(IOServicePtr io_service) {
auto it = std::find(external_io_services_.begin(), external_io_services_.end(), io_service);
if (it != external_io_services_.end()) {
external_io_services_.erase(it);
}
}
void
IOService::pollExternalIO() {
for (auto& io_service : external_io_services_) {
io_service->poll();
}
}
```
built on top of #3281
I confirm it fixes the crash in https://gitlab.isc.org/isc-projects/kea/-/issues/3308https://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/3295DDNS: addresses assigned from an arpa domain that is not configured can halt ...2024-03-28T16:58:13ZDarren AnkneyDDNS: addresses assigned from an arpa domain that is not configured can halt ddns processingKea Version tested: 2.4.0 with DHCPv4. Assumedly this same problem would exist in DHCPv6 but I didn't try that. The BIND version used in the test was 9.18.24, but I don't think it probably matters what version or brand of DNS server is...Kea Version tested: 2.4.0 with DHCPv4. Assumedly this same problem would exist in DHCPv6 but I didn't try that. The BIND version used in the test was 9.18.24, but I don't think it probably matters what version or brand of DNS server is used.
It has been discovered that it is possible that `kea-dhcp-ddns` can enter a state where no ddns updates are issued under certain circumstances. The circumstances required are only an intermittently unavailable DNS server, an address range in Kea that is not in the "reverse-ddns" portion of the DDNS configuration, a high rate of DHCP queries (I tested with 200 per second), and `"ddns-update-on-renew": true` in the `kea-dhcp4` configuration. Below is the test scenario (first with a working version of the ddns configuration):
<details><summary>Kea configuration and command line</summary>
Command: `kea-dhcp4 -c kea-dhcp4-test-ddns.json`
kea-dhcp4-test-ddns.json
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"calculate-tee-times": true,
"valid-lifetime": 7200,
"ddns-generated-prefix": "myhost",
"ddns-qualifying-suffix": "example.org",
"ddns-replace-client-name": "always",
"ddns-send-updates": true,
"ddns-override-client-update": true,
"ddns-override-no-update": true,
"ddns-update-on-renew": true,
"dhcp-ddns": {
"enable-updates": true,
"max-queue-size": 1024,
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"sender-ip": "0.0.0.0",
"sender-port": 0,
"server-ip": "127.0.0.1",
"server-port": 53001
},
"shared-networks": [
{
"name": "my-secret-lair-level-1",
"interface": "ens256",
"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"
}
]
},
{
"subnet": "172.16.0.0/24",
"id": 2,
"option-data": [
{
"name": "routers",
"data": "172.16.0.1"
}
],
"pools": [
{
"pool": "172.16.0.100-172.16.0.200"
}
]
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "DEBUG",
"debuglevel": 99,
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>BIND configuration and command line</summary>
Command: `named -4 -g -c /tmp/named.conf`
named.conf
```
options {
directory "/tmp";
recursion no;
allow-update { any;};
dnssec-validation no;
};
zone "2.1.10.in-addr.arpa" {
type primary;
file "/tmp/2.1.10.in-addr.arpa";
};
zone "0.16.172.in-addr.arpa" {
type primary;
file "/tmp/0.16.172.in-addr.arpa";
};
zone "example.org" {
type primary;
file "/tmp/example.org";
};
```
example.org
```
$ORIGIN .
$TTL 86399 ; 23 hours 59 minutes 59 seconds
example.org IN SOA ns1.example.org. hostmaster.example.org. (
1 ; serial
43200 ; refresh (12 hours)
900 ; retry (15 minutes)
1814400 ; expire (3 weeks)
7200 ; minimum (2 hours)
)
NS ns1.example.org.
ns1.example.org A 192.168.20.114
```
2.1.10.in-addr.arpa
```
$ORIGIN .
$TTL 86400 ; 1 day
2.1.10.in-addr.arpa IN SOA 2.1.10.IN-ADDR.ARPA. . (
1 ; serial
30800 ; refresh (8 hours 33 minutes 20 seconds)
7200 ; retry (2 hours)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS ns1.example.org.
```
0.16.172.in-addr.arpa
```
$ORIGIN .
$TTL 86400 ; 1 day
0.16.172.in-addr.arpa IN SOA 0.16.172.in-addr.arpa. . (
1 ; serial
30800 ; refresh (8 hours 33 minutes 20 seconds)
7200 ; retry (2 hours)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS ns1.example.org.
```
</details>
<details><summary>Working DDNS configuration and command line</summary>
Command: `kea-dhcp-ddns -c kea-dhcp-ddns-test-ddns.json`
kea-dhcp-ddns-test-ddns.json
```
{
"DhcpDdns": {
"dns-server-timeout": 40000,
"forward-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "example.org."
}
]
},
"reverse-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "2.1.10.in-addr.arpa."
},
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "0.16.172.in-addr.arpa."
}
]
},
"ip-address": "127.0.0.1",
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"port": 53001,
"loggers": [
{
"severity": "DEBUG",
"debuglevel": 99,
"name": "kea-dhcp-ddns",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>non-Working DDNS configuration and command line</summary>
Command: `kea-dhcp-ddns -c kea-dhcp-ddns-test-ddns.json`
kea-dhcp-ddns-test-ddns.json
```
{
"DhcpDdns": {
"dns-server-timeout": 40000,
"forward-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "example.org."
}
]
},
"reverse-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "2.1.10.in-addr.arpa."
}
//,
// {
// "dns-servers": [
// {
// "ip-address": "192.168.20.114",
// "port": 53
// }
// ],
// "name": "0.16.172.in-addr.arpa."
// }
]
},
"ip-address": "127.0.0.1",
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"port": 53001,
"loggers": [
{
"severity": "DEBUG",
"debuglevel": 99,
"name": "kea-dhcp-ddns",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
Perfdhcp was used to create the traffic for this test: `sudo perfdhcp -4 -r 200 -p 1800 -l ens256 -R 200`
BIND will, for some reason, stop responding intermittently during the test. The reason for that is not important for this issue. This was originally reported by a customer using some kind of off premise DNS servers that would intermittently be unavailable due to network issues. If all subnets are configured in the DDNS configuration, then DDNS will not become unresponsive when BIND becomes unresponsive.
This message might appear while BIND is unresponsive:
```DHCP_DDNS_AT_MAX_TRANSACTIONS application has 1024 queued requests but has reached maximum number of 32 concurrent transactions```
but DDNS will recover once BIND recovers.
Using the "non-Working DDNS configuration and command line", the DDNS server cannot recover and is unavailable for the remainder of the test.
The `kea-dhcp-ddns` service must be restarted before it will respond again.
I also tested this with `example.org` removed from the ddns configuration. `kea-dhcp-ddns` did not suffer a stop in processing with that zone removed. It appears to only be in the case of a missing `.arpa` zone.
<details><summary>When the `kea-dhcp-ddns` stops responding, it is during one of these failures to match reverse DNS zone</summary>
```
2024-03-19 16:56:18.347 WARN [kea-dhcp-ddns.dhcp-to-d2/1479.281473066429376] DHCP_DDNS_NO_MATCH No DNS servers match FQDN 149.0.16.172.in-addr.arpa.
2024-03-19 16:56:18.347 ERROR [kea-dhcp-ddns.dhcp-to-d2/1479.281473066429376] DHCP_DDNS_NO_REV_MATCH_ERROR Request ID 000101285974D2A2411A8BCED2CF77E9E97AD8582814F422CD88FD27E2B37B26969C5F: the configured list of reverse DDNS domains does not contain a match for: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-172-16-0-149.example.org.]
IP Address: [172.16.0.149]
DHCID: [000101285974D2A2411A8BCED2CF77E9E97AD8582814F422CD88FD27E2B37B26969C5F]
Lease Expires On: 20240319173614
Lease Length: 2400
Conflict Resolution: yes
The request has been discarded.
```
No further logs are emitted by `kea-dhcp-ddns` until the process is restarted.
</details>
<details><summary>`kea-dhcp4` does not appear to realize anything is amiss</summary>
```
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473627656064] DHCPSRV_QUEUE_NCR [hwtype=1 00:0c:01:02:03:23], cid=[01:00:0c:01:02:03:23]: Name change request to remove DNS entry queued: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173840
Lease Length: 2400
Conflict Resolution: yes
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473669656592] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173840
Lease Length: 2400
Conflict Resolution: yes
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473627656064] DHCPSRV_QUEUE_NCR [hwtype=1 00:0c:01:02:03:23], cid=[01:00:0c:01:02:03:23]: Name change request to add DNS entry queued: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173841
Lease Length: 2400
Conflict Resolution: yes
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473669656592] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173841
Lease Length: 2400
Conflict Resolution: yes
```
as the log messages appear the same whether `kea-dhcp-ddns` is doing anything or not.
</details>
[SF1804](https://isc.lightning.force.com/lightning/r/Case/500S60000074PjmIAE/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3281Follow-up from "Draft: Resolve "heap-use-after-free and invalid vptr on PingC...2024-03-29T08:36:56ZRazvan BecheriuFollow-up from "Draft: Resolve "heap-use-after-free and invalid vptr on PingCheckMgr destruction""The following discussion from !2197 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2197#note_438320 'Draft: Resolve "heap-use-after-free and invalid vptr on PingCheckMg...The following discussion from !2197 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2197#note_438320 'Draft: Resolve "heap-use-after-free and invalid vptr on PingCheckMgr destruction"'): (+3 comments)
> > To keep the members alive, they can be added to a lambda function which uses a smart pointer to capture the object, but does not use it. It then must be added to the IOService queue using the post function.
>
> I would take the `shared_from_this` alternative anytime if it gets rid of the posts.
>
> If you think that it is too much work for now although it shouldn't be, we can create a ticket, but can you at least add comments to say that they are posted only for extending lifetime?
>
> Core:
>
> ```plaintext
> + getIOService()->post(std::bind(f, queue_mgr_));
> + io_service_->post(std::bind(f, timer_));
> + io_service_->post(std::bind(f, timer_));
> + io_service_->post(std::bind(f, timer_));
> + io_service_->post(std::bind(f, timer_, tcp_socket_, tls_socket_));
> ```
>
> Premium:
>
> ```plaintext
> + main_io_service_->post(std::bind(f, expiration_timer_, channel_));
> ```kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3254Include git commit hash for premium in the config report2024-03-22T16:21:17ZAndrei Pavelandrei@isc.orgInclude git commit hash for premium in the config reportThe report includes the git commit hash for core in the config report that can be accessed with the `-W` parameter when Kea was built from sources. It would be nice to have the git commit hash for premium as well, if Kea was built with p...The report includes the git commit hash for core in the config report that can be accessed with the `-W` parameter when Kea was built from sources. It would be nice to have the git commit hash for premium as well, if Kea was built with premium. It could be mentioned under `Extended version:` or under `Premium hooks: yes`.kea2.5.8https://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/3133Read TSIG secret from file2024-03-27T22:49:58ZIulian MegheaRead TSIG secret from file---
name: Feature request
about: Suggest an idea for this project
---
Allow reading tsig-keys (at least the secret) from an external file. This way it can integrate better with secret management tools.
For example the configuration cou...---
name: Feature request
about: Suggest an idea for this project
---
Allow reading tsig-keys (at least the secret) from an external file. This way it can integrate better with secret management tools.
For example the configuration could use more relaxed permissions but the file containing the tsig secret can use very restrictive permissions.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2359Flex option hook should support unspecified number of encapsulation levels (j...2023-07-31T13:32:51ZRazvan BecheriuFlex option hook should support unspecified number of encapsulation levels (just like the core code does). - Follow-up from "Draft: Resolve "[ISC-support #20152] Support for custom spaces in flex_option hook""Flex option hook should support unspecified number of encapsulation levels (just like the core code does).
Core supported spaces and options:
```
#define ISC_V6_OPTION_SPACE "4o6"
#define MAPE_V6_OPTION_SPACE "s...Flex option hook should support unspecified number of encapsulation levels (just like the core code does).
Core supported spaces and options:
```
#define ISC_V6_OPTION_SPACE "4o6"
#define MAPE_V6_OPTION_SPACE "s46-cont-mape-options"
#define MAPT_V6_OPTION_SPACE "s46-cont-mapt-options"
#define LW_V6_OPTION_SPACE "s46-cont-lw-options"
#define V4V6_RULE_OPTION_SPACE "s46-rule-options"
#define V4V6_BIND_OPTION_SPACE "s46-v4v6bind-options"
D6O_DHCPV4_MSG = 87, /* RFC7341 */
D6O_DHCPV4_O_DHCPV6_SERVER = 88, /* RFC7341 */
D6O_S46_RULE = 89, /* RFC7598 */
D6O_S46_BR = 90, /* RFC7598 */
D6O_S46_DMR = 91, /* RFC7598 */
D6O_S46_V4V6BIND = 92, /* RFC7598 */
D6O_S46_PORTPARAMS = 93, /* RFC7598 */
D6O_S46_CONT_MAPE = 94, /* RFC7598 */
D6O_S46_CONT_MAPT = 95, /* RFC7598 */
D6O_S46_CONT_LW = 96, /* RFC7598 */
```
The following discussion from !1600 should be addressed:
- [X] @razvan started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1600#note_274971): (+2 comments)
> we can have "sub-options" here also and we will effectively have unlimited encapsulation levels (of course limited by user definitions and configuration text), and we can call parseSubOptions in parseSubOptions recursively.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2256Prepare subnet selection speedup: patrica trees2023-06-19T12:08:06ZFrancis DupontPrepare subnet selection speedup: patrica treesPatricia trees are the optimal general data structure for IP prefix lookup: the number of comparisons is bounded by the number of bits so 32 or 128 for IP, the real number depends on the number of nodes where children differs and in the ...Patricia trees are the optimal general data structure for IP prefix lookup: the number of comparisons is bounded by the number of bits so 32 or 128 for IP, the real number depends on the number of nodes where children differs and in the real world is far lower.
BTW the current code just iterates on all subnetworks so is linear in the number of subnets (average case N/2, N for the worst case which includes the not found case). The patricia tree gives also overlaps (equality or inclusion).backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2255Prepare subnet selection speedup: auxiliary tables2023-07-31T13:32:51ZFrancis DupontPrepare subnet selection speedup: auxiliary tablesThere are at least two cases where an index can or should not be used/added to a multi index:
- when the corresponding data structure is not supported, e.g. patricia tree for IP prefixes
- when the default is very common: the multi ind...There are at least two cases where an index can or should not be used/added to a multi index:
- when the corresponding data structure is not supported, e.g. patricia tree for IP prefixes
- when the default is very common: the multi index works but gives a lot of values for this default value so it doubles the insert/delete operation time
- when a direct index value change is convenient: this breaks the multi index so must not be done (instead the multi index must be updated which is a complex (to code) and slow (to execute) operation)
The solution is to add in parallel of a multi index soem auxiliary tables which provide a specific lookup. The auxiliary table is a base type with add, delete and change (which is in general delete followed by add).backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2200Format GSS-TSIG code2022-10-06T10:58:58ZAndrei Pavelandrei@isc.orgFormat GSS-TSIG codeNow that GSS-TSIG development has reached maturity, this is a good opportunity to:
* [x] apply code formatting to its code
* [ ] improve .clang-formatNow that GSS-TSIG development has reached maturity, this is a good opportunity to:
* [x] apply code formatting to its code
* [ ] improve .clang-formatoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2140Can't use kea-dhcp6 as Prefix Delegation backend (like previously dibbler)2023-07-31T13:38:18ZLajos KatonaCan't use kea-dhcp6 as Prefix Delegation backend (like previously dibbler)Hi
I would like to use Kea for Openstack Neutron's pd "backend" (https://opendev.org/openstack/neutron ).
Currently we have a driver in Neutron for Dibbler which we use the following way (user workflow: https://docs.openstack.org/neutro...Hi
I would like to use Kea for Openstack Neutron's pd "backend" (https://opendev.org/openstack/neutron ).
Currently we have a driver in Neutron for Dibbler which we use the following way (user workflow: https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#prefix-delegation ):
Neutron l3-agent creates IP namespaces for the routers, and dibbler is started within the ip namespace with a config like this:
_duid-type duid-en 8888 0x0f73d556b8364067bc6b3c2e61367d67
downlink-prefix-ifaces "none"
script
"/opt/stack/data/neutron/pd/877976ab-71c1-4c3f-ab76-281c5f2a61fa:0f73d556-b836-4067-bc6b-3c2e61367d67:qr-58b7a155-28/notify.sh"
iface "qg-f63df9d7-a7" {
bind-to-address fe80::f816:3eff:fe3a:f745
pd 1
}_
sudo ip netns exec qrouter-7dc7553b-b3aa-4782-b534-e4fc61f8b54f dibbler-client start -w /opt/stack/data/neutron/pd/877976ab-71c1-4c3f-ab76-281c5f2a61fa:0f73d556-b836-4067-bc6b-3c2e61367d67:qr-58b7a155-28/client.conf
notify.sh is a hook script to make possible that the prefix is finally stored in db and user can fetch it via REST API.
I tried to use Kea isntead to reach something similar result:
```
_$ cat kea_test.conf
{
# DHCPv6 configuration starts on the next line
"Dhcp6": {
# Next we set up the interfaces to be used by the server.
"interfaces-config": {
"interfaces": [ "qg-f63df9d7-a7" ]
},
# Finally, we list the subnets from which we will be leasing addresses.
"subnet6": [
{
"subnet": "2001:db8:2222::/48",
"pools": [
{"pool": "2001:db8:2222::/64"}
],
"pd-pools": [
{
"prefix": "3000:1::",
"prefix-len": 64,
"delegated-len": 96
}
]
}
]
# DHCPv6 configuration ends with the next line
}}
sudo kea-dhcp6 -c kea_test.conf_
```
but without success.
I saw that Kea has support for hooks (not sure I can use them as those are not in current distros), not sure if I can have similar hook like we have with dibbler.
environment:
Ubuntu 20.04.3 LTS
Linux mykeaenv 5.4.0-88-generic #99-Ubuntu SMP Thu Sep 23 17:29:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ kea-dhcp6 -v
2.0.0outstandingTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1562command_processed hook not tested or documented in CA2022-08-01T13:27:57ZTomek Mrugalskicommand_processed hook not tested or documented in CAThis was discovered in #1421 that the `command_processed` hook point is not documented and not tested.
With the upcoming RBAC, we need to improve the testing situation.This was discovered in #1421 that the `command_processed` hook point is not documented and not tested.
With the upcoming RBAC, we need to improve the testing situation.outstandinghttps://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/1447use thread_local to optimize access to thread context2021-10-20T11:53:14ZRazvan Becheriuuse thread_local to optimize access to thread contextmoved from
#1333 https://gitlab.isc.org/isc-projects/kea/-/merge_requests/917
and
#1333 https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/130moved from
#1333 https://gitlab.isc.org/isc-projects/kea/-/merge_requests/917
and
#1333 https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/130outstandingWlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1420Speedup subnet selection: less indexes2023-07-31T12:45:46ZFrancis DupontSpeedup subnet selection: less indexesChild of #554
Subnet and shared network collections have subnet4 4, subnet6 3, shared network4 5 and shared network6 4 indexes. Some are clearly useless and can be removed, including the one making a difference between v4 and v6.Child of #554
Subnet and shared network collections have subnet4 4, subnet6 3, shared network4 5 and shared network6 4 indexes. Some are clearly useless and can be removed, including the one making a difference between v4 and v6.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1339calling expired can cause races2023-07-31T13:13:53ZRazvan Becheriucalling expired can cause racesas @fdupont mentioned, calling expire can cause races within the kea code:
```
lease->expired() // false here
...
// some time passes
lease->expired() // true here
```as @fdupont mentioned, calling expire can cause races within the kea code:
```
lease->expired() // false here
...
// some time passes
lease->expired() // true here
```next-stable-2.6Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1328Kea and link time optimization2023-09-28T08:09:49ZFrancis DupontKea and link time optimizationThis ticket addressed two different goals:
- first to investigate if/how Kea can be build using -flto
- second fix bugs revealed by the -flto optionsThis ticket addressed two different goals:
- first to investigate if/how Kea can be build using -flto
- second fix bugs revealed by the -flto optionsoutstanding