Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-01-18T14:52:27Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3201Allow static leases by hostname like in the old ISC dhcpd2024-01-18T14:52:27ZLuigi BaldoniAllow static leases by hostname like in the old ISC dhcpd---
name: Allow reservations by hostname
about: Allow creating reservations by hostname like in the old ISC dhcp server
---
**Describe the solution you'd like**
In the old ISC dhcpd one could add entries like:
```
host myhost {
hard...---
name: Allow reservations by hostname
about: Allow creating reservations by hostname like in the old ISC dhcp server
---
**Describe the solution you'd like**
In the old ISC dhcpd one could add entries like:
```
host myhost {
hardware ethernet 08:00:aa:bb:cc:dd;
fixed-address myhost;
}
```
Kea allows this:
```
"reservations": [
{
"hw-address": "08:00:aa:bb:cc:dd",
"ip-address": "192.0.2.10"
}
]
```
Would it be possible to implement this feature in Kea so to have something like:
```
"reservations": [
{
"hw-address": "08:00:aa:bb:cc:dd",
"hostname-address": "myhost"
}
]
```
?
**Describe alternatives you've considered**
I am aware of the possibility of using ddns and RFC2136 to supply data to a domain name server.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2828Document or fix database conflicts between v4 hosts and v6 hosts2023-04-20T13:38:11ZAndrei Pavelandrei@isc.orgDocument or fix database conflicts between v4 hosts and v6 hostsSay there are a kea-dhcp4 server and a kea-dhcp6 server with both their `hosts-databases` set to the same database.
If an administrator wants to reserve v4 resources and v6 resources for the same client identified by a common identifier...Say there are a kea-dhcp4 server and a kea-dhcp6 server with both their `hosts-databases` set to the same database.
If an administrator wants to reserve v4 resources and v6 resources for the same client identified by a common identifier type, say hardware address, the host schema goes out if its way to allow this, having separate `dhcp4_subnet_id` and `dhcp6_subnet_id` columns, separate `dhcp4_options` and `dhcp6_options` tables, and so on.
However, the response to the second of the two `reservation-add` commands that are issued for each server, is `Database duplicate entry error`.
What's worse is that the administrator might assume that there is already a reservation with that identifier in the database, but if you follow up with a `reservation-get-all` to check it out, it doesn't show up, because it only shows hosts from the server version that is queried and the duplicate is for the other server version.
I'm suggesting that this needs to be either documented in the ARM, or fixed which is not difficult and is doable, and backwards-compatible, by including `dhcp4_subnet_id` and `dhcp6_subnet_id` as part of the primary key in the `hosts` table.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1597reservations-* fields does not reflect changes made to reservation-mode2022-11-02T15:10:18ZMichal Nowikowskireservations-* fields does not reflect changes made to reservation-modeIf `reservation-mode` is changed using `remote-global-parameter{46}-set` then `config-get` shows unchanged values of `reserveraions-global`, `reservations-in-subnet` and `reservations-out-of-pool`.
Forge tests:
```
tests/dhcpv4/kea_only...If `reservation-mode` is changed using `remote-global-parameter{46}-set` then `config-get` shows unchanged values of `reserveraions-global`, `reservations-in-subnet` and `reservations-out-of-pool`.
Forge tests:
```
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v4-None]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v4-all]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v4-out-of-pool]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v4-global]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v4-disabled]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v6-None]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v6-all]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v6-out-of-pool]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v6-global]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_override_init[v6-disabled]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_in_globals[v4]
tests/dhcpv4/kea_only/config_backend/test_reservations.py::test_reservation_mode_in_globals[v6]
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1566host entry conflict: same identifier, identifier type and subnet id2022-10-25T13:27:59ZFrancis Duponthost entry conflict: same identifier, identifier type and subnet idThis comes from the test_v4_host_reservation_conflicts_duplicate_reservations forge test.
The question is what happens with 2 host reservations using the same identifier, identifier type and subnet id.
In the config the host container ...This comes from the test_v4_host_reservation_conflicts_duplicate_reservations forge test.
The question is what happens with 2 host reservations using the same identifier, identifier type and subnet id.
In the config the host container uses 3 different not unique indexes for the identifier+type, subnet id v4 and v6. As far I know there is no conflict check at config time. The get methods throw DuplicateHost.
MySQL database since schema 5.0 (Kea 1.1.0) uses unique key_dhcp[46]_identifier_subnet_id indexes so does not allow the same identifier + type with the same not null subnet id. The not null matters because the host reservation table is shared between v4 and v6 so same identier and type is allowed with for instance different v4 subnet ids even both v6 subnet ids are null.
MySQL backend get methods do not check: they return the first host if the query returns at least one.
PostgreSQL database is very close to MySQL with a small difference introduced in schema 3.2 (Kea 1.4.0): the unique constraint does not apply when the subnet id is 0.
Cassanda/CQL schema has no constaint. The get methods check if more than one host is found and throw MultipleRecords.
On the forge side:
- test_v4_host_reservation_conflicts_duplicate_reservations verifies that the configuration case allows conflicts
- test_v4_host_reservation_conflicts_duplicate_reservations_mysql verifies that the MySQL case allows conflicts and fails because it is not allowed
There is no check for PostgreSQL but it should fail if reservations are not global.
Note a similar constraint was removed on the same address and subnet id by #1428 in 1.9.1 (search for ip-reservations-unique).
Proposed action: reverse forge tests, add a PgSQL one and consider to add a check for the configuration case: at least an unit test should verify an incorrect configuration giving failures at run time is rejected.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1564possible host retrieval optimization2022-11-02T15:10:18ZFrancis Dupontpossible host retrieval optimizationallocateLeases6 retrieves client leases using IA type, DUID and IAID, and filters the result using the subnets of the shared network.
renewLeases6 retrieves client leases using IA type, DUID, IAID and subnet ID, and merges results itera...allocateLeases6 retrieves client leases using IA type, DUID and IAID, and filters the result using the subnets of the shared network.
renewLeases6 retrieves client leases using IA type, DUID, IAID and subnet ID, and merges results iterating the subnets of the shared network.
Both ways get exactly the same list of leases but with different database queries.
Outside shared network the subnet ID narrows the search so it lightly more efficient. In a shared network it uses one query per subnet so is clearly less efficient.
In conclusion the idea is to factor the two retrievals and to use the best way according to in/outside a shared network.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1541Add backend call counters2020-12-21T13:08:48ZFrancis DupontAdd backend call countersThe idea is to add simple counters (vs full stats) for backend API method calls. For instance in #1418 it would be very fine to confirm that a lease is not updated twice. I know that profiling can get the same information but this is far...The idea is to add simple counters (vs full stats) for backend API method calls. For instance in #1418 it would be very fine to confirm that a lease is not updated twice. I know that profiling can get the same information but this is far more immediate for a low cost (i.e. I am sure the cost will be more than recovered by optimizations it is expected to allow).
Note we do not need large counters: it does not matter if a counter wraps as soon as it takes a long time to happen...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/997Remove commit and rollback methods from lease and host manager APIs.2022-11-02T15:10:18ZFrancis DupontRemove commit and rollback methods from lease and host manager APIs.They are unused so useless. Note they make sense only with transactions which span over more than one service method and such transactions (nor a way to manage them) do not exist.They are unused so useless. Note they make sense only with transactions which span over more than one service method and such transactions (nor a way to manage them) do not exist.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/681Synchronize reservations between HA partners2022-11-02T16:23:36ZGhost UserSynchronize reservations between HA partnersI have bought Kea Premium hook package and I am using it for IP reservation but I have a problem not sure if that's how should be or not.
I am running kea DHCP in HA(Active/HotStandBY)- When I add a reservation on Active node it doesn't...I have bought Kea Premium hook package and I am using it for IP reservation but I have a problem not sure if that's how should be or not.
I am running kea DHCP in HA(Active/HotStandBY)- When I add a reservation on Active node it doesn't get replicated to HotStandBy node. Due to this, I am unable to use my hot standby node. Can you please have a look asap.
And what will happen if I add some reservation while other node is down - will they get replication when the node comes back online?
Kea DHCP 1.5outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/445add support for mongo db2019-02-07T17:00:17ZGhost Useradd support for mongo db---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is you...---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is your feature request related to a problem? Please describe.**
- Reduction of the numbers of databases on the client's systems
**Describe the solution you'd like**
- allow kea administrators to configure mongodb in kea
**Describe alternatives you've considered**
- Not really.
**Additional context**
- No.
**Funding its development**
- Sure to some very small degree.
**Participating in development**
- design discussions and testing
**Contacting you**
- Private messages to my gitlab.isc.org registered email address are fine.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/435A design for "backends in hooks"2022-04-21T10:39:03ZTomek MrugalskiA design for "backends in hooks"We had a discussion about Kea packaging in 1.6 (see meeting notes 2019-01-24). The conclusion was that we want to prepare for Kea packaging better. In particular, the database backends should be moved to hooks that are loaded dynamically...We had a discussion about Kea packaging in 1.6 (see meeting notes 2019-01-24). The conclusion was that we want to prepare for Kea packaging better. In particular, the database backends should be moved to hooks that are loaded dynamically, rather than included during compilation time.
The overall intention is to have a directory where hooks could be loaded from. This is similar to Apache modules. They have 2 directories: mods-available and mods-enabled. The first one contains a list of modules (hooks). The second one has symlinks to those modules (hooks) that will be loaded. This approach is super easy to understand and use. Also, very extensible, because you can package backends and other hooks in independent RPM or DEB packages.
It's different than what we do now and several things have to be changed before we get there:
1. When Kea parses configuration, it has to know what lease-database and hosts-database backends are supported. Right now it's hardcoded* (but see below). We'd need to load the hooks first and they would register available backends, then we'd process rest of the configuration.
1. RADIUS is implemented as a hook and it does provide hosts backend. Before doing anything, please investigate how it registers "radius" hosts-backend type. This is not exactly a ready to use solution (because you can't configure "radius" backend in the config yet), but they underlying implementation of backend type registration is good.
1. we need to develop a code that would load all the hooks from a directory
Things to consider:
1. name the directory properly (people complained that the hooks have incorrect name libdhcp- and also are placed in incorrect directory)
2. perhaps we could have hooks that are loaded always (call them permanent hooks maybe?). Those would be put in the hooks-enabled directory and would be loaded at kea startup and not unloaded during reconfiguration? This would be most useful for parameter-less hooks (such a config backends)
3. apache allows having a separate config file for each module. IMHO this is a bit too much, but maybe it's something to look at after all?
The goal of this ticket is to write a design. It should conclude with w written design and a list of tickets needed to implement it.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/38Updating DNS entry on host reservation changing2022-11-02T15:08:42ZGhost UserUpdating DNS entry on host reservation changingI sent this questions to kea-users@lists.isc.org two days ago, but nothing happens and I can't see my message in thread list. So, I decided to create a new ticket.
My previous message:
I'm trying to bond Kea with BIND. When a new lease ...I sent this questions to kea-users@lists.isc.org two days ago, but nothing happens and I can't see my message in thread list. So, I decided to create a new ticket.
My previous message:
I'm trying to bond Kea with BIND. When a new lease is created or expired it works well. In this cases I get correct records in "forward" and "reverse" DNS zones. But, when I'm changing an IP-address in host reservation entry in MySQL database, a new address is allocated to the customer and new correct entries appear in DNS. However, an old entry for previous IP-address still remains in "reverse" DNS zone. Thus, now I have a "ghost" entry in my DNS.
I would manually remove the lease BEFORE changing the reservation entry. I guess it should work. But maybe there is a routine solution for this issue?backlog