Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-21T14:50:56Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3275Kea DB allows to store too short identifier in the lease table2024-03-21T14:50:56ZSlawek FigielKea DB allows to store too short identifier in the lease tableWhile performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it b...While performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it blocks fetching this lease by API. I don't know if it has any other internal consequences.
Steps to reproduce:
1. Setup Kea 2.3.8 or above with PostgreSQL.
2. Configure lease database.
3. Insert a lease with too short DUID (e.g., `00`)
```
INSERT INTO lease6(address, duid, valid_lifetime, expire, subnet_id, pref_lifetime, lease_type, iaid, prefix_len, hwtype, hwaddr_source, state) VALUES('3001:db8:1::2', DECODE('00', 'hex'), 3600, NOW() + interval '1' MONTH, 1, 1800, 0, 1, 128, 0, 0, 1);
```
4. Send the `lease-get` command with the specified address (i.e., `3001:db8:1::2`).
5. Observe the error:
```
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command lease6-get received from remote address 127.0.0.1
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | ERROR LEASE_CMDS_GET6_FAILED lease6-get command failed (parameters: { "ip-address": "3001:db8:1::2", "type": "IA_NA" }, reason: Could not convert data to Lease6, reason: identifier is too short (1), at least 3 is required)
stork-agent-kea6-1 | ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $lease6_get registered by library with index 1 (callout address 0x7f12e8310e90) (callout duration 0.593 ms)
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_FORWARDED command lease6-get successfully forwarded to the service dhcp6 from remote address 127.0.0.1
```backloghttps://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.0https://gitlab.isc.org/isc-projects/kea/-/issues/2666some lease commands don't leave a corresponding forensic log message2023-07-31T14:08:52ZAndrei Pavelandrei@isc.orgsome lease commands don't leave a corresponding forensic log message`lease-add`, `lease-update`, `lease-del` have corresponding forensic log messages:
```
Administrator added a lease of [...]
Administrator updated information on the lease of [...]
Administrator deleted the lease for [...]
```
`lease-wi...`lease-add`, `lease-update`, `lease-del` have corresponding forensic log messages:
```
Administrator added a lease of [...]
Administrator updated information on the lease of [...]
Administrator deleted the lease for [...]
```
`lease-wipe` and `lease6-bulk-apply` do not log anything.
If logging each deleted lease in the wipe command is considered too verbose, there could be a single line mentioning the wipe.
For the argument that `lease6-bulk-apply` command is only used by HA, it's worth mentioning that forensic logs appear for peer lease updates as well.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2637Regular expressions in Stork2023-04-06T12:02:30ZPeter DaviesRegular expressions in StorkTo enable the use of regular expression is Stork
see: https://gitlab.isc.org/isc-projects/stork/-/issues/901
It may be necessary to change the behaviour of leaseX-get-* commandsTo enable the use of regular expression is Stork
see: https://gitlab.isc.org/isc-projects/stork/-/issues/901
It may be necessary to change the behaviour of leaseX-get-* commandsbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2565HA lease v6 updates use the default hwtype and hwaddr_source2023-07-31T13:51:18ZAndrei Pavelandrei@isc.orgHA lease v6 updates use the default hwtype and hwaddr_sourceNotice the discrepancy in the last two columns:
* `server1`:
```
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:5...Notice the discrepancy in the last two columns:
* `server1`:
```
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:50::11,00:03:00:01:01:03:0d:04:0b:01,4000,1663013972,1,3000,0,5946,128,0,0,,01:03:0d:04:0b:01,0,,1,0
2001:db8:50::12,00:03:00:01:01:04:0e:05:0c:02,4000,1663013972,1,3000,0,3512,128,0,0,,01:04:0e:05:0c:02,0,,1,0
2001:db8:50::d,00:03:00:01:01:05:0f:06:0d:03,4000,1663013972,1,3000,0,5918,128,0,0,,01:05:0f:06:0d:03,0,,1,2
2001:db8:50::e,00:03:00:01:01:06:10:07:0e:04,4000,1663013973,1,3000,0,4936,128,0,0,,01:06:10:07:0e:04,0,,1,2
```
* `server2`:
```
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:50::11,00:03:00:01:01:03:0d:04:0b:01,4000,1663013972,1,3000,0,5946,128,0,0,,01:03:0d:04:0b:01,0,,1,2
2001:db8:50::12,00:03:00:01:01:04:0e:05:0c:02,4000,1663013972,1,3000,0,3512,128,0,0,,01:04:0e:05:0c:02,0,,1,2
2001:db8:50::d,00:03:00:01:01:05:0f:06:0d:03,4000,1663013972,1,3000,0,5918,128,0,0,,01:05:0f:06:0d:03,0,,1,0
2001:db8:50::e,00:03:00:01:01:06:10:07:0e:04,4000,1663013973,1,3000,0,4936,128,0,0,,01:06:10:07:0e:04,0,,1,0
```
The ones with `hwaddr_source = 0` are updated from the other peer. `hwtype = 1` is also likely a default that happens to match its source in the examples above.
It looks like `Lease6::toElement()` and `Lease6Parser::parse()` need the `hwtype` and `hwaddr_source` capabilities.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1444LeaseX-update and leaseX-del cmds must be propaged to ha members2021-10-19T07:34:04Zmirackle-spbLeaseX-update and leaseX-del cmds must be propaged to ha members---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request ...---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request to primary is not enough. I need to send same request to stand-by member.
**Describe the solution you'd like**
Send update and del cmds to all ha members after completion on one node to maintain sync.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/479HA peer should drop leases not present on the partner during sync2022-11-02T15:10:19ZMarcin SiodelskiHA peer should drop leases not present on the partner during syncLet's suppose there are two HA peers A and B. The peer B dies. While the peer B is offline, the admin sends `lease4-del` command to the A. The peer B starts up and synchronizes its lease database with A. It correctly adds new leases and ...Let's suppose there are two HA peers A and B. The peer B dies. While the peer B is offline, the admin sends `lease4-del` command to the A. The peer B starts up and synchronizes its lease database with A. It correctly adds new leases and updates existing leases based on the list received from A. However, it doesn't remove the lease deleted on A while it was offline. The server admin would need to send `lease4-del` command to B to remove the lease.
In order to address this problem we have to fetch all leases from the B's backend and iterate over them to see if they are also present on A. In order to do so, we will have to keep the local copy of leases received from A. For Memfile, MySQL and Postgres we could do it more efficiently by comparing ranges of leases as they are ordered by IP addresses. After comparing a range of leases we could simply drop the local copy of the lease ranges. However, this won't work for Cassandra which returns leases out of order. In the Cassandra case we will have to collect all leases returned by the peer.backlogMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/382Propagate lease updates between HA peers2022-11-02T15:08:41ZMarcin SiodelskiPropagate lease updates between HA peersHigh Availability setup includes at least two servers paired to provide reliable service. We have the lease_cmds hooks library which is utilized by the HA hooks library to send lease updates between the peers. Sometimes, though, an admin...High Availability setup includes at least two servers paired to provide reliable service. We have the lease_cmds hooks library which is utilized by the HA hooks library to send lease updates between the peers. Sometimes, though, an administrator may want to update lease information via the control channel, e.g. remove stale lease. Currently, he'd need to send appropriate command to all HA peers that (potentially) share the lease information. It is useful to be able to send the command to only one of the HA peers and let it propagate it down to other servers. For that, the HA peer would need to somehow identify that the command has been sent by the administrator rather than the HA peer, otherwise it would trigger circular updates.
The details how to implement it are TBD.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/349Restricting timestamps in Kea backends to max supported values2022-11-02T15:08:42ZMarcin SiodelskiRestricting timestamps in Kea backends to max supported valuesThe following chapter of the Kea User's Guide `Limitations Related to the use of SQL Databases` claims that we restricted timestamps to 32 bit value past the epoch. I don't see us restricting this anywhere. Maybe we should revise which d...The following chapter of the Kea User's Guide `Limitations Related to the use of SQL Databases` claims that we restricted timestamps to 32 bit value past the epoch. I don't see us restricting this anywhere. Maybe we should revise which databases have which limitation and explicitly report an error upon an attempt to add higher timestamps.backlog