Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-21T17:04:41Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2358Subnet reselection by address and class in RADIUS2024-03-21T17:04:41ZAndrei Pavelandrei@isc.orgSubnet reselection by address and class in RADIUSPresume client C has Framed-Pool P and Framed-IP-Address A in RADIUS. Reselect is enabled in Kea.
Supposition of expected behavior:
1. Kea looks for a subnet that matches both criteria, that is: address A is in the subnet's range, and ...Presume client C has Framed-Pool P and Framed-IP-Address A in RADIUS. Reselect is enabled in Kea.
Supposition of expected behavior:
1. Kea looks for a subnet that matches both criteria, that is: address A is in the subnet's range, and the subnet has a pool classified with class P.
1. If subnet not found, Kea reselects to `SUBNET_ID_UNUSED`.
Current behavior:
1. Kea looks for a subnet that has a pool classified with class P. If found, Kea settles for it and does not continue the reselection process, even though it may violate the reservation through Framed-IP-Address.
1. If subnet not found, Kea looks for a subnet that has address A in its range. If found, Kea settles for it, even though it may violate the reservation through Framed-Pool.
1. If subnet not found, Kea reselects to `SUBNET_ID_UNUSED`.
In other words, there is an OR relation between the two attributes, when, in fact, there should be an AND because both things happen in the lease allocation process: the reserved address is leased and the class is assigned to the client. In further words, Framed-Pool has priority over Framed-IP-Address in reselection, even though this is not documented, but there probably should not be any priority if the supposition above is correct.
Edge case that violates the current behavior mentioned above even if it is considered correct:
1. Kea looks for a subnet that has a pool classified with class P. Kea finds subnet S and it happens to be the same subnet assigned to the client as part of the initial subnet selection process. Kea considers this as not a reselection since the subnet ID technically did not change, and thus continues the process of reselecting, believing it has not found the right subnet yet.
1. Kea looks for a subnet that has address A in its range. It finds one and is a different subnet than S. It selects that subnet, even though the first one would have been selected were it not for the unfortunate circumstance of having the subnet already selected to S before making the RADIUS auth call.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2331Kea-Admin db-upgrade fails if using different Port for pgsql2023-07-05T10:39:19ZAlex GastKea-Admin db-upgrade fails if using different Port for pgsql---
name: Kea-Admin db-upgrade fails if using different Port for pgsql
about: Kea-Admin should respect supplied Port (-P) Parameter for doing db-upgrade
---
**Bug Description**
When doing the `db-upgrade` with `kea-admin` using a pgs...---
name: Kea-Admin db-upgrade fails if using different Port for pgsql
about: Kea-Admin should respect supplied Port (-P) Parameter for doing db-upgrade
---
**Bug Description**
When doing the `db-upgrade` with `kea-admin` using a pgsql-Backend with a port different than 5432 the update fails.
The `-P` Parameter is used and verified before but does not work in the real upgrade process.
Starting the PostgreSQL Database on the default-port and omitting the Port-Parameter the update works well.
Example:
```
kea-admin db-upgrade pgsql -h localhost -P 5435 -u kea -p "<my-fancy-password>" -n kea
Database version reported before upgrade: 8.0
Processing /usr/share/kea/scripts/pgsql/upgrade_001.0_to_002.0.sh file...
This script upgrades 1.0 to 2.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_002.0_to_003.0.sh file...
This script upgrades 2.0 to 3.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.0_to_003.1.sh file...
This script upgrades 3.0 to 3.1. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.1_to_003.2.sh file...
This script upgrades 3.1 to 3.2. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.2_to_003.3.sh file...
This script upgrades 3.2 to 3.3. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.3_to_004.0.sh file...
This script upgrades 3.3 to 4.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_004.0_to_005.0.sh file...
This script upgrades 4.0 to 5.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_005.0_to_005.1.sh file...
This script upgrades 5.0 to 5.1. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_005.1_to_006.0.sh file...
This script upgrades 5.1 to 6.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_006.0_to_006.1.sh file...
This script upgrades 6.0 to 6.1. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_006.1_to_006.2.sh file...
This script upgrades 6.1 to 6.2. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_006.2_to_007.0.sh file...
This script upgrades 6.2 to 7.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_007_to_008.sh file...
This script upgrades 7.0 to 8.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_008_to_009.sh file...
psql: error: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
```
**To Reproduce**
Steps to reproduce the behavior:
1. Use Kea with Lease-Backend on pgsql configured with a Port other than 5432
2. Do a software-upgrade (in my case via APT-Packages) [rem. might be another bug that the APT does not upgrade the db-schema itself]
3. Kea reports a wrong Schema-Version at startup.
4. Execute `kea-admin db-upgrade pgsql -h localhost -P 5435 -u kea -p "<my-fancy-password>" -n kea`
5. See that it detects the actual Schema-Version and then in the last step ends with "Connection refused" at Port 5432.
6. Run the PostgreSQL-Software at Port 5432
7. Use the above `kea-admin`-Command with the same `-P` Parameter
8. See that it can't detect the actual Schema and exits:
```
kea-admin db-upgrade pgsql -h localhost -P 5435 -u kea -p "AWlZgeouj5vkRkexSAND" -n kea
psql: error: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5435?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5435?
```
9. Omit the `-P`-Parameter and successfully upgrade the Schema.
10. Turn back the Database to the port used before
11. Start kea and see it running.
**Expected behavior**
The DB-Update Procedure should take full awareness of the changed port and update the database schema accordingly.
In the best case the APT update procedure should implement this step as well (for unattended updating purpose) - I'm not sure if it already does as the manual process already fails.
**Environment:**
- Kea version: 2.1.3 from Cloudsmith-Repository
- OS: Ubuntu 20.04.4 LTS, AMD64
- pgsql-Lease-Backend with Port different than 5432
**Additional Information**
Lease-Backend-Configuration:
```
"lease-database": {
"type": "postgresql",
"user": "kea",
"password": "<my-fancy-password>",
"name": "kea",
"port": 5435
},
```
As the mentioned update-script does take some parameters via `$@`-Variable kea-admin migth don't declare the `-p` or `--port` Parameter for the pgsql Backend.
Other commands like `lease-dump` do behave accordingly:
```
kea-admin lease-dump pgsql -h localhost -P 5435 -u kea -p "<my-fancy-password>" -n kea -4 -o output-dump.csv
psql: error: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
ERROR/kea-admin: lease-dump: psql call failed, exit code: 0
```
**Contacting you**
Please reach out via the contact information on my profile or via Twitter / GitHub.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2223HA error when partner received duplicated DHCP requests with the same Transac...2023-07-31T13:39:24ZSpencer LoweHA error when partner received duplicated DHCP requests with the same Transaction ID**Describe the bug**
Because our redundant topology the same Kea server will get the same DHCP request message with the same transaction ID from different relays. We run our kea servers in the load-balancing HA mode. Server 1 will send t...**Describe the bug**
Because our redundant topology the same Kea server will get the same DHCP request message with the same transaction ID from different relays. We run our kea servers in the load-balancing HA mode. Server 1 will send the lease4-update to server 2. Because server 1 received the same packet twice with the same transaction ID it sends both updates to server 2. Server 2 then responds with resource busy because it is still updating the lease from the first request when the second request comes in. Because server 2 errors out server 1 puts the server into unknown state. It will then resync, but it breaks on every DHCP request. We are storing leases in Postgres.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4 in load balancing mode. Send a duplicate DHCP request with the same transaction ID to a server.
2. Server 1 will process both DHCP requests and will send the lease4-update to server 2. Both of these requests happen at almost the same time.
3. Server 1 will then put server 2 into unknown state because the lease4-update command failed.
**Expected behavior**
I would expect the update to not fail, but I am not sure how DHCP servers are supposed to handle duplicate requests with the same transaction IDs
**Environment:**
- Kea dhcp4 v 2.0.0
- OS: [e.g. Debian 11 x64]
- Storing leases in Postgres
- `libdhcp_lease_cmds`, `libdhcp_ha`
**Additional Information**
- I have attached a PCAP that shows the DHCP requests and the lease4-update command
- Attached is the kea config that runs on both servers
[ss21-dhcp-debug.pcap](/uploads/f4c0beee834c75b7131e4e485af12d47/ss21-dhcp-debug.pcap)[kea-config.json](/uploads/a5a5a89cd10a736706b93ac7eabd4e9d/kea-config.json)
**Contacting you**
slowe@clairglobal.comnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2101Relative path for hooks2023-06-29T08:49:17ZTomek MrugalskiRelative path for hooksWhen preparing the first template (see #2050), it became obvious that the hooks installation dir is very OS-specific. It would be very convenient if Kea knew the hook installation dir, so the same config with just a libname could be used...When preparing the first template (see #2050), it became obvious that the hooks installation dir is very OS-specific. It would be very convenient if Kea knew the hook installation dir, so the same config with just a libname could be used. If path is absolute, it would work as before. If it's relative, the default path would be prepended.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/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/1989Issues with qualifying suffix when clients use a combination of Hostname and ...2024-03-27T12:50:32ZMarcin SiodelskiIssues with qualifying suffix when clients use a combination of Hostname and Client FQDN optionA client sends option 12 (Hostname) or option 81 (Client FQDN) to communicate the desired name to the server. The server assumes that the client sends one of these options, not both. If the Client FQDN is present in the client's message,...A client sends option 12 (Hostname) or option 81 (Client FQDN) to communicate the desired name to the server. The server assumes that the client sends one of these options, not both. If the Client FQDN is present in the client's message, it processes this option and ignores the Hostname option.
The server may append a qualifying suffix to the received name or replace the name entirely. The qualified name is terminated with a dot in Client FQDN and is never terminated with a dot in the Hostname option.
We deliberately made a change in the processing of the Hostname option several years ago when it turned out that some DHCP clients have issues with consuming the dot terminated hostname. It appears that it has implications for some clients.
We received a report about a client who uses a combination of option 12 and option 81 in the 4-way exchange. The client sends a partial name in option 12. The server qualifies the name with the suffix and sends option 12 back. The client uses the qualified name (without a dot) and sends it in the Client FQDN option as a partial name. The server qualifies the received name again on the grounds that it is a partial name. Even though the client shouldn't use a combination of these options, we could probably prevent qualifying the name twice by checking if the received name already has a suffix equal to the configured one.
One solution that comes to mind is to always append the dot to the hostnames returned in option 12. However, as mentioned before, we deliberately removed the dots because some clients did not accept them.
We can also consider whether it should be possible to explicitly include a dot via host reservations. If a host reservation has a dot for the hostname, the server would always include a dot. Thus, it would be possible to make exceptions for selected clients.
[RT #18375](https://support.isc.org/Ticket/Display.html?id=18735)
UPDATE: The original problem has been addressed in #1529. However, there's a request [see below](https://gitlab.isc.org/isc-projects/kea/-/issues/1989#note_227456) to add two parameters:
- [ ] allow the administrator to configure which field (option 12 or option 81) to prefer if both exist (RFC violation, that you can actually do now with DDNS tuning hook).
- [ ] including a trailing dot or not could be a configurable feature (or it could be left to the administrator if they include a trailing dot on the qualifying suffix itself.)next-stable-3.0https://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.0