Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-07-05T10:39:18Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1588EVAL_RESULT displays boolean status as an integer2023-07-05T10:39:18ZFrancis DupontEVAL_RESULT displays boolean status as an integerFor instance ```EVAL_RESULT Expression 53148-RU evaluated to 1``` should be ```EVAL_RESULT Expression 53148-RU evaluated to true``` so all uses of EVAL_RESULT should set std::boolalpha or convert the boolean into false and true directly.For instance ```EVAL_RESULT Expression 53148-RU evaluated to 1``` should be ```EVAL_RESULT Expression 53148-RU evaluated to true``` so all uses of EVAL_RESULT should set std::boolalpha or convert the boolean into false and true directly.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1446Control the amount of certain attributes in RADIUS packets per RFCs 2865, 28662024-03-20T11:22:24ZAndrei Pavelandrei@isc.orgControl the amount of certain attributes in RADIUS packets per RFCs 2865, 2866Attributes that are marked with `0`, `0-1`, `1` in RFCs 2865, 2866 need to be verified when building a RADIUS packet. `0+` has no restrictions. More details in #1441.Attributes that are marked with `0`, `0-1`, `1` in RFCs 2865, 2866 need to be verified when building a RADIUS packet. `0+` has no restrictions. More details in #1441.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1387Support RFC6603 Prefix Exclude with host reservations not just pd-pools2023-07-05T10:39:18ZDax KelsonSupport RFC6603 Prefix Exclude with host reservations not just pd-poolsIn RFC7084 (Basic Requirements for IPv6 Customer Edge Routers) it says CPE SHOULD IMPLEMENT support for RFC6603.
In [RIPE-690](https://www.ripe.net/publications/docs/ripe-690) Best Current Operational Practice for Operators: IPv6 prefix...In RFC7084 (Basic Requirements for IPv6 Customer Edge Routers) it says CPE SHOULD IMPLEMENT support for RFC6603.
In [RIPE-690](https://www.ripe.net/publications/docs/ripe-690) Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users, it says
Not using a pd-pool, but with a host specific reservation I would like be able to set the RFC6603 prefix to exclude:
Perhaps something like this syntax?
```
"reservations": [
{
"hw-address": "00:01:02:03:04:05",
"ip-addresses": [ "2001:DB8::101" ],
"prefixes": [ "2001:DB8:10:200::/56" ],
"prefixes_excluded": [ "2001:DB8:10:200::/64" ]
}
]
```
Per RFC6603 exactly one prefix can be excluded from a delegated prefix. So a validity check should be done on the intersection between the prefixes and prefixes_excluded.
Further elaborating, note that prefixes is an array as multiple prefixes can be listed (although a single prefix is the most common). Thus prefixes_excluded must also be array so that you could technically specify an excluded prefix for each prefix.next-stable-2.6https://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/1281Explore methods of enhancing lease synchronization2024-01-09T21:14:42ZPeter DaviesExplore methods of enhancing lease synchronization**Explore methods of enhancing lease synchronization**
To minimise the time taken to synchronize lease data when a primary Kea server comes online after an outage. Thereby minimise the time in which dhcp traffic is not processed.
Is it...**Explore methods of enhancing lease synchronization**
To minimise the time taken to synchronize lease data when a primary Kea server comes online after an outage. Thereby minimise the time in which dhcp traffic is not processed.
Is it possible to speed up the convergence of lease data on a HA pair by giving a server knowledge of what leases its partner has?
Or a mechanism where Kea server could request only lease updates that were made while it was off line. Based either on time or maybe some serial nr? The case where one Kea server can be standby for more than one primary could make this difficult to implement.
Or some out-of-bounds method of copying the lease file contents?
RT [#16560](https://support.isc.org/Ticket/Display.html?id=16560)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1146Perform profiling for MT Kea2023-02-23T09:44:56ZTomek MrugalskiPerform profiling for MT Kea@fdupont proposed to do a profiling for multi-threaded Kea. This is a very good idea. The goal of this ticket is to run profiling and come up with a list of bottlenecks. No code changes needed at this time, just to highlight the problems...@fdupont proposed to do a profiling for multi-threaded Kea. This is a very good idea. The goal of this ticket is to run profiling and come up with a list of bottlenecks. No code changes needed at this time, just to highlight the problems.
I think the result of this work should be a list of code areas that's inefficient.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/878performance: implement backend statistics2023-07-31T13:02:12ZTomek Mrugalskiperformance: implement backend statisticsWe want to be able to measure the following:
* looking for reservations took X us,
* looking for leases took Y us.
* Z queries per packet were conducted.
* W total queries performed by backend, average response time was A.
* possibly st...We want to be able to measure the following:
* looking for reservations took X us,
* looking for leases took Y us.
* Z queries per packet were conducted.
* W total queries performed by backend, average response time was A.
* possibly stats by query type (getLease4byHWAddr, getLease4ByAddr, etc.)
* possibly query by SQL type (A number of SELECTs, B number of INSERTs, C number of DELETEs)
This, on its own, wouldn't improve any performance, but it will be an essential tool for assessing other performance improvement proposals.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/414Use new lease user contexts in RADIUS accounting2024-03-21T16:21:16ZFrancis DupontUse new lease user contexts in RADIUS accountingMigrated from https://oldkea.isc.org/ticket/5658
Current code has many potential problems and was scheduled to use use contexts from the beginning but it was postponed because user contexts in leases were implemented later:
- save/load...Migrated from https://oldkea.isc.org/ticket/5658
Current code has many potential problems and was scheduled to use use contexts from the beginning but it was postponed because user contexts in leases were implemented later:
- save/load to a CSV file is implemented but never tested.
- eraseCreateTimestamp() is called only when a STOP event is sent so the timestamp stays in memory without more control
+ obviously using an user-context is the right way: extent following the lease one, save in stable storage, etc.
If memory leak on RADIUS accounting experiments are not conclusive this should be tried.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/326Handle Reconfigure Accept Option #872023-05-30T11:04:20ZVicky Riskvicky@isc.orgHandle Reconfigure Accept Option #87Mayya Sunil opened on Github as issue #87 on June 1, 2018
Reconfigure Accept Option : Included in Server's Replies, Advertise message and client's Solicit, Request, Renew, Rebind, Information Request to announce support of Reconfigure f...Mayya Sunil opened on Github as issue #87 on June 1, 2018
Reconfigure Accept Option : Included in Server's Replies, Advertise message and client's Solicit, Request, Renew, Rebind, Information Request to announce support of Reconfigure feature.
This issue involves 2 tasks
Include the option in the server's outgoing message.
2)Parse the option in the client's message and generate and store the keys in the reservation if keys not available.
----------
MayyaSunil pushed a commit to MayyaSunil/kea that referenced this issue on Aug 14
[store_client_context] Stotes client info in user contexts …
a09944dnext-stable-2.62020-02-29https://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/3286Allow absolute values for DDNS RR TTLs (to correctly meet RFC 4702, Section 5)2024-03-21T14:54:27ZRobin EdserAllow absolute values for DDNS RR TTLs (to correctly meet RFC 4702, Section 5)We are currently preparing a migration from `dhcpd` to Kea and are struggling a bit with DNS TTLs for DDNS entries created with Kea. We have a requirement from the organisation to have our default lease time be `2 days` / `172800 seconds...We are currently preparing a migration from `dhcpd` to Kea and are struggling a bit with DNS TTLs for DDNS entries created with Kea. We have a requirement from the organisation to have our default lease time be `2 days` / `172800 seconds`, but in combination with a short TTL of `300 seconds` because our Juniper firewall rules are almost entirely name based.
Since Kea only calculates the TTL we are currently having to set `ddns-ttl-percent` to `.00174` to get a `301 second` TTL. However since we are setting this globally, the result is that any client classes where we explicitly want much shorter lease than the default to get a `1 second` TTL.
RFC 4702, Section 5 does also mention that TTLs should also be configurable as an absolute time interval:
> We recognize that individual administrators
will have varying requirements: DHCP servers and clients SHOULD allow
administrators to configure TTLs and upper and lower bounds on the
TTL values, either as an absolute time interval or as a percentage of
the lease time.
This is something that would be ideal for us and hopefully useful for others. I hope it can be considered.
Thank you to the Kea devs and ISC for all your hard work :heart:next-stable-3.0https://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/3277Result YXRRSET for in Dual Stack Environment2024-03-21T14:51:54ZDavid SchmidtResult YXRRSET for in Dual Stack EnvironmentI have a Dual Stack environment with kea-dhcp4-server, kea-dhcp6-server and kea-dhcp-ddns-server.
I am running kea 2.2 on devuan 12, my source code check showed it's an issue in version 2.5.7 still.
DDNS is enabled with conflict resolu...I have a Dual Stack environment with kea-dhcp4-server, kea-dhcp6-server and kea-dhcp-ddns-server.
I am running kea 2.2 on devuan 12, my source code check showed it's an issue in version 2.5.7 still.
DDNS is enabled with conflict resolution for both kea-dhcp servers.
When the DHCP lease is released, DDNS trys to cleanup the regarding A/AAAA RRs and both PTR RRs.
When the cleanup of FwdRRSet is executed in Dual Stack environment, the RRSET cleanup of A resp. AAAA - whatever comes first - will fail with Rcode YXRRSET because the other Fwd RRSET is still there. In case of A removal, the AAAA will still be existing, in case of AAAA removal the A record will still exist. Therefore the prerequisit in buildRemoveFwdRRsRequest() neither A nor AAAA exists won't be fulfilled. This behaviour leads to corrupted PTR entries in DDNS.
To fix the issue I changed the function removingFwdRRsHandler() in src/bin/d2/nc_remove.cc to accept rcode == dns:Rcode::YXRRSET() in case of IO_COMPLETED_EVT also.
```
057 09:28:42.773 kea-dhcp-ddns.dhcp-to-d2 DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: received and queued a request.
057 09:28:42.773 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_STARTING_TRANSACTION Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5:
057 09:28:42.774 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward Add to server: 192.168.x.x port:53
057 09:28:42.787 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:42.787 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:42.787 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Reverse Replace to server: 192.168.x.x port:53
057 09:28:42.796 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:42.796 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:42.796 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [lan-client.xxx.de.]
IP Address: [192.168.x.x]
DHCID: [000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5]
Lease Expires On: 20240226094842
Lease Length: 1200
Conflict Resolution: yes
057 09:28:43.317 kea-dhcp-ddns.dhcp-to-d2 DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: received and queued a request.
057 09:28:43.317 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_STARTING_TRANSACTION Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5:
057 09:28:43.318 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward Add to server: 192.168.x.x port:53
057 09:28:43.319 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:43.320 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: YXDOMAIN
057 09:28:43.321 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward Replace to server: 192.168.x.x port:53
057 09:28:43.335 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:43.335 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:43.336 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Reverse Replace to server: 192.168.x.x port:53
057 09:28:43.344 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:43.344 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:43.344 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [lan-client.xxx.de.]
IP Address: [fdxx::282]
DHCID: [000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5]
Lease Expires On: 19700101000000
Lease Length: 2400
Conflict Resolution: yes
057 09:40:04.392 kea-dhcp-ddns.dhcp-to-d2 DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: received and queued a request.
057 09:40:04.393 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_STARTING_TRANSACTION Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5:
057 09:40:04.393 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward A/AAAA Remove to server: 192.168.x.x port:53
057 09:40:04.405 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward RR Remove to server: 192.168.x.x port:53
057 09:40:04.405 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: **YXRRSET**
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns **DHCP_DDNS_FORWARD_REMOVE_RRS_REJECTED** DNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Server, 192.168.x.x port:53, rejected a DNS update request to remove forward RR entries for FQDN, lan-client.xxx.de., with an RCODE: 7
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_REMOVE_FAILED DHCP_DDNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Transaction outcome: Status: Failed, Event: UPDATE_FAILED_EVT, Forward change: failed, Reverse change: failed, request: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [lan-client.xxx.de.]
IP Address: [fdxx::282]
DHCID: [000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5]
Lease Expires On: 20240226100843
Lease Length: 2400
Conflict Resolution: yes
```next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3274Synchronous run script2024-03-14T14:37:11ZAndrei Pavelandrei@isc.orgSynchronous run scriptAs ARM states
> Currently, enabling synchronous calls to external scripts is not supported.
Sync run script is not supported.
With the addition of sync process spawn functionality in issue 3025, this is now doable.As ARM states
> Currently, enabling synchronous calls to external scripts is not supported.
Sync run script is not supported.
With the addition of sync process spawn functionality in issue 3025, this is now doable.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3273Upgrade schema on startup2024-03-14T14:36:20ZAndrei Pavelandrei@isc.orgUpgrade schema on startupKea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.Kea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.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/3241Failed to start kea-dhcp if the interface defined in the interface-config lis...2024-03-07T14:54:35ZPranathi NandhigamFailed to start kea-dhcp if the interface defined in the interface-config list is unavailable even though some of the interfaces are upI have observed kea-dhcp failed to start when one of the interface defined in the "interface-config" list does not exist even though other defined interfaces are up and has usable IP address configured. May be dhcp server can be started ...I have observed kea-dhcp failed to start when one of the interface defined in the "interface-config" list does not exist even though other defined interfaces are up and has usable IP address configured. May be dhcp server can be started with the interfaces which are up instead of refusing to start until all interfaces defined in the list comes up.
From code snippet below
void IfacesConfigParser::parseInterfacesList(const CfgIfacePtr& cfg_iface, ConstElementPtr ifaces_list) {
for (auto const& iface : ifaces_list->listValue()) {
std::string iface_name = iface->stringValue();
try {
cfg_iface->use(protocol_, iface_name);
} catch (const std::exception& ex) {
isc_throw(DhcpConfigError, "Failed to select interface: "
<< ex.what() << " (" << iface->getPosition() << ")");
}
}
}
Here if interface is not found instead of raising an exception, it can be a warning and can be proceeded with other interfaces in the list. I am not sure how feasible it is and its side effect.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3225when applying MT settings from CB the libs compatibility is not rechecked2024-03-27T13:50:40ZRazvan Becheriuwhen applying MT settings from CB the libs compatibility is not recheckedMT disabled -\> check libs (success) -\> load libs -\> CB load config -\> MT enabled -\> no checking of libs -\> could end up with non MT compatible libs loaded and used in MTMT disabled -\> check libs (success) -\> load libs -\> CB load config -\> MT enabled -\> no checking of libs -\> could end up with non MT compatible libs loaded and used in MTnext-stable-3.0https://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/3206subnet-get commands should fetch leases for selected subnets with pagination2024-03-22T13:15:53ZMarcin Siodelskisubnet-get commands should fetch leases for selected subnets with paginationIn HA, we use lease commands to synchronize the database. The lease commands fetch all leases with pagination. However, in the hub-and-spoke model it would be useful to fetch the leases only for selected subnets because the relationships...In HA, we use lease commands to synchronize the database. The lease commands fetch all leases with pagination. However, in the hub-and-spoke model it would be useful to fetch the leases only for selected subnets because the relationships are partitioned by subnet. Today, all leases have to be fetched by each relationship and those that do not belong to the relationship are discarded. This is inefficient. One thing to consider is that subnet identifiers are listed explicitly in the commands.next-stable-3.0