Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-28T15:01:04Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3302Is Host Cache required for RADIUS?2024-03-28T15:01:04ZFrancis DupontIs Host Cache required for RADIUS?The Host Cache was designed for RADIUS in order to not perform an access/auth exchange with the RADIUS server for each query: when the query comes from an already seen client (same RADIUS idenfier) the answer from the RADIUS server is av...The Host Cache was designed for RADIUS in order to not perform an access/auth exchange with the RADIUS server for each query: when the query comes from an already seen client (same RADIUS idenfier) the answer from the RADIUS server is available from the host cache. This was critical when both were designed because the access/auth exchange was synchronous (i.e. blocking until the answer is received) and single threaded (i.e. blocking the whole DHCP service). Perhaps it is less true today but the host cache is in memory when RADIUS exchanges are over the network so far slower, and the Host Cache also handles negative answers so covers (excepting for the bug described in #3269) all cases.
The Host Cache has a second function for RADIUS: when the RADIUS server returns an address (vs a pool name which is translated into a client class name directly added to the query object) a host entry for this reserved address is inserted in the Host Cache. The idea is the host lookup will be able to find it. This is not essential: the host entry can be attached to the callout handle associated to the query and got back latter as the current code does for the [re]selected subnet.kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/1345Ability to always-respond to all requests in HA active-active mode to support...2021-01-22T13:30:51ZEwald van GeffenAbility to always-respond to all requests in HA active-active mode to support anycast DHCPMy impression is that ISC KEA doesn't always respond to all requests. I think this is due to the 1/n split.
I run two KEA instances sharing a single BGP anycast /32 IP prefix. DHCP Requests get routed via a DHCP relay towards the closes...My impression is that ISC KEA doesn't always respond to all requests. I think this is due to the 1/n split.
I run two KEA instances sharing a single BGP anycast /32 IP prefix. DHCP Requests get routed via a DHCP relay towards the closest ISC KEA instance according to BGP. Load balancing is externally handled. This means KEA should respond to all requests it receives and not impose any load-balancing logic.
I think this is where the magic happens [1]
From my understanding active_servers needs to reflect the current server instance id (pri,sec).
[1] https://github.com/isc-projects/kea/blob/457111f9db051723ff9f8e7fb621872d0aa10363/src/hooks/dhcp/high_availability/query_filter.cc#L316outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1282too late hook library effective unload2020-06-30T17:28:11ZFrancis Duponttoo late hook library effective unloadThe thread sanitizer shows too late effective unload of the HA hook library.The thread sanitizer shows too late effective unload of the HA hook library.kea1.7.10Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1028New classification design.2023-07-31T11:54:22ZFrancis DupontNew classification design.Some proposals for a new classification design:
- replace the list+set by a multi-index
- replace the required-xxx by a more direct add-client-classes.
- add this new add-client-classes to host reservations as an alias of the existing...Some proposals for a new classification design:
- replace the list+set by a multi-index
- replace the required-xxx by a more direct add-client-classes.
- add this new add-client-classes to host reservations as an alias of the existing client-classes (same entry with the same behavior for all objects which add a class to the query)
- complete the list of class evaluation points:
* new points after the deferred unpack, pkt*_receive hook, etc
* make clear in the doc that which a classification point is for:
+ dependency on a packet procession phase (e.g. KNOWN/UNKNOWN)
+ usage for the next packet processing step (e.g. subnet selection, pool guard, output option)
* add an enum (vs a few flags) for the point where a class must be evaluated
* add a meta-data with the value of its enum and make it visible to users
- same rules on dependency (use of member in expression):
* no forward reference (the user class in a member clause must be already defined)
* get the last classification point
* perhaps a new built-in class for instance for the pkt*_receive hook
- document the way to switch from expired-* to this new stuff (but do not develop a tool to translate configurations)
- (next steps?) new uses of classes (e.g. lifetime), new expressions (e.g. in the response vs the query): in almost all cases this means new classification pointsnext-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/991Build some multi-threading unit tests for lease backends.2020-12-10T19:40:56ZFrancis DupontBuild some multi-threading unit tests for lease backends.kea1.9.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/956investigate scenario with two servers sharing lease database and pools2021-06-18T10:47:35ZFrancis Dupontinvestigate scenario with two servers sharing lease database and poolsClearly it is a pretty bad setup but it seems to be used by some customers so it is a bit late to say it is not supported so:
- analyze the behavior of the current code
- decide what should be the lease worst behavior
- update code an...Clearly it is a pretty bad setup but it seems to be used by some customers so it is a bit late to say it is not supported so:
- analyze the behavior of the current code
- decide what should be the lease worst behavior
- update code and documentationKea1.9-backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/687Add the sender's address to kea-ctrl-agent log messages [ISC-support #14906]2022-04-25T13:00:37ZCathy AlmondAdd the sender's address to kea-ctrl-agent log messages [ISC-support #14906]As requested in [Support RT #14906](https://support.isc.org/Ticket/Display.html?id=14906)
(And also, this sounds like a really useful idea).
The requestor of this feature says:
For us, the source ip address is an important piece of in...As requested in [Support RT #14906](https://support.isc.org/Ticket/Display.html?id=14906)
(And also, this sounds like a really useful idea).
The requestor of this feature says:
For us, the source ip address is an important piece of information.
We would like to see in the kea-ctrl-agent log messages the received command together with the source ip address - something like this:
Jun 20 10:21:52 myserver.example.com kea-ctrl-agent[58456]: 2019-06-20 10:21:52.771 INFO [kea-ctrl-agent.commands/58456] COMMAND_RECEIVED Received command 'config-get’ from 192.0.2.25
From my perspective as an operator, it is a great advantage if the log messages contain all information related to the context.
We would like to see the source address without switching to the debug level.
How do you see this request? Is this an improvement that other users also would appreciate?kea2.1.5Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/616error msgs contain references to config file while config-backend is used2019-07-22T10:49:20ZMichal Nowikowskierror msgs contain references to config file while config-backend is usedI got an error message:
```Config reload failed:configuration error using file '/usr/local/etc/kea/kea.conf': a pool of type V4, with the following address range: 192.168.50.1-192.168.50.100...```
while this config file did not contain ...I got an error message:
```Config reload failed:configuration error using file '/usr/local/etc/kea/kea.conf': a pool of type V4, with the following address range: 192.168.50.1-192.168.50.100...```
while this config file did not contain any subnet definitions - subnets were defined over config-backend.
Error messages should not refer to config file if config is stored in config-backend.Kea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/610validation of option definitions in cb_cmds2019-07-22T10:49:12ZWlodzimierz Wencelvalidation of option definitions in cb_cmdsAt this moment using cb_cmds hook you can define new non-standard options using standard options codes. When kea will fetch this configuration it will fail. I propose to introduce validation of option codesAt this moment using cb_cmds hook you can define new non-standard options using standard options codes. When kea will fetch this configuration it will fail. I propose to introduce validation of option codesKea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/486No longer use bison is yacc emulation mode.2019-03-11T12:55:19ZFrancis DupontNo longer use bison is yacc emulation mode.The autoconf AC_PROG_YACC used in configure sets the YACC variable to "bison -y" but:
- we do not use any feature of the yacc emulation mode, in particular for output file names.
- we use a lot of bison specific features: this gives a ...The autoconf AC_PROG_YACC used in configure sets the YACC variable to "bison -y" but:
- we do not use any feature of the yacc emulation mode, in particular for output file names.
- we use a lot of bison specific features: this gives a lot of warnings with recent bison versions.
Note an alternative is to disable yacc mode warnings (-Wno-yacc) but even it requires more testing avoid the yacc mode is a far cleaner solution.Kea1.6Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/485Stricter check for flex in configure.2019-03-11T13:10:02ZFrancis DupontStricter check for flex in configure.I propose to change
```
if test "x$LEX" == "x"; then
```
into
```
if test "x$LEX" != "xflex"; then
```
in the unlikely but possible case where lex but but not flex is available as recommended in AC_PROG_LEX documentation.I propose to change
```
if test "x$LEX" == "x"; then
```
into
```
if test "x$LEX" != "xflex"; then
```
in the unlikely but possible case where lex but but not flex is available as recommended in AC_PROG_LEX documentation.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/474RADIUS with shared networks2019-05-15T12:50:03ZTomek MrugalskiRADIUS with shared networksWhen RADIUS was implemented, we didn't have shared networks support. As a result, there was a mechanism designed (subnet-reselect) to do something a bit similar to shared networks.
We need to look at the code and see:
- what is needed t...When RADIUS was implemented, we didn't have shared networks support. As a result, there was a mechanism designed (subnet-reselect) to do something a bit similar to shared networks.
We need to look at the code and see:
- what is needed to make RADIUS work with shared network
- what the limitations would be
RADIUS has some substantial limitations as a database-like system, but the basic assumption that it can return attributes that are mapped to client classes should be viable.
#403 has a discussion about current (1.5) code and its limitations.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/472Documentation about congestion recovery2020-09-10T15:52:00ZFrancis DupontDocumentation about congestion recoveryTwo points:
- make clearer that the congestion recovery is not congestion avoidance (or any variant in terms which can suggest it) in the documentation
- findings about the impact on performance of the congestion recovery.Two points:
- make clearer that the congestion recovery is not congestion avoidance (or any variant in terms which can suggest it) in the documentation
- findings about the impact on performance of the congestion recovery.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/419subnet prefix ("subnet" parameter) ambiguity2019-07-22T10:48:11ZFrancis Dupontsubnet prefix ("subnet" parameter) ambiguityCurrently you can create two subnets with the same [begin,end) prefix as soon as the "subnet" parameter is not the same. Some customers already use this trick so create "192.0.2.0/24", "192.0.2.1/24", etc, subnets.
There are three solut...Currently you can create two subnets with the same [begin,end) prefix as soon as the "subnet" parameter is not the same. Some customers already use this trick so create "192.0.2.0/24", "192.0.2.1/24", etc, subnets.
There are three solutions:
- ignore (this is what we did not it is not a real solution!)
- make this illegal (ref #36 and #37)
- accept the trick
In the last case we should create a ticket to add unit tests (so if a code change makes it no longer to work it will be detected) and document it.
BTW the criterion to choose between to make illegal or to accept is the use of the prefix as an unique key in config backend database or things like the remote-subnet4-del-prefix CB command which makes sense only if a prefix can identify without ambiguity a subnet. So it is a design choice and IMHO it must be explicitly done.Kea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/328Using a model which is installed but unknown.2022-11-02T15:08:42ZFrancis DupontUsing a model which is installed but unknown.This issue is about the third case in this method called with the model for a managed server entry:
```
bool
NetconfAgent::checkModule(const string& module_name) const {
if (module_name.empty()) {
return (true);
}
auto modul...This issue is about the third case in this method called with the model for a managed server entry:
```
bool
NetconfAgent::checkModule(const string& module_name) const {
if (module_name.empty()) {
return (true);
}
auto module = modules_.find(module_name);
if (module == modules_.end()) {
LOG_ERROR(netconf_logger, NETCONF_MODULE_MISSING_ERR)
.arg(module_name);
return (false);
}
auto modrev = YANG_REVISIONS.find(module_name);
if (modrev == YANG_REVISIONS.end()) {
// Can't check revision?!
// It can happen only with a module which is not in
// YANG_REVISIONS but installed so likely on purpose.
return (true);
}
if (modrev->second != module->second) {
LOG_ERROR(netconf_logger, NETCONF_MODULE_REVISION_ERR)
.arg(module_name)
.arg(modrev->second)
.arg(module->second);
return (false);
}
return (true);
}
```
Tomek requested a warning, I added the comment after ```Can't check revision?!``` and answered:
No warning. In fact it means the module is installed but is not in yang revisions so either it is on purpose and the check was simply disabled, or it is a real error and the translator will raise a better error.
I am creating an issue in the case a better option could be found.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/301Report a hook DSO version when it is loaded2022-11-02T15:08:41ZThomas MarkwalderReport a hook DSO version when it is loadedIt would be useful, if Hook DSO versions were emitted when they are loaded, or if they were included in response to the version report command.It would be useful, if Hook DSO versions were emitted when they are loaded, or if they were included in response to the version report command.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/300Installing *messages.h files doesn't seem to be trivial2019-05-13T19:25:36ZMarcin SiodelskiInstalling *messages.h files doesn't seem to be trivialFor Kea 1.5.0 beta2 we attempted to install all *_messages.h files which contain labels of log messages used by loggers. That turned out to be a problem for `make distcheck` because it requires to compile .mes files using the message com...For Kea 1.5.0 beta2 we attempted to install all *_messages.h files which contain labels of log messages used by loggers. That turned out to be a problem for `make distcheck` because it requires to compile .mes files using the message compiler from the `$(top_builddir)` where the kea-msg-compiler is not available. At the stage where the compiler is needed the compiler is presumably available in the $(top_distdir) instead. We haven't figured out why this issue occurs when we attempt to install the files and not when we don't. Because this issue was found right before the Kea 1.5.0 beta2 release we didn't have time to investigate it and find the proper solution. We simply backed off the changes (we don't install message headers) hoping for some solution for it later.
We should also consider whether the messages files should be installed at all. It seems they will only be needed if there are any header files installed which require the message files. That could be the case if we have a template class implemented within the header file which requires logging. As far as we can tell today, we don't have such cases in the code. So, backing off the changes seemed safe for Kea 1.5.0 beta2.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/273Warn about legacy top-level entries2019-05-23T20:24:14ZFrancis DupontWarn about legacy top-level entriesAnnounce in ~~1.5~~ 1.6 release that a Dhcp6 entry in a DHCPv4 server configuration is ignored and will raise an error in the next release.Announce in ~~1.5~~ 1.6 release that a Dhcp6 entry in a DHCPv4 server configuration is ignored and will raise an error in the next release.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/257Improve doxygen for IfaceMgr2022-11-02T15:08:44ZThomas MarkwalderImprove doxygen for IfaceMgrThe class commentary for IfaceMgr is extremely terse and needs to be expanded.The class commentary for IfaceMgr is extremely terse and needs to be expanded.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/219allow an option value to be set from an expression2019-10-25T09:31:24ZFrancis Dupontallow an option value to be set from an expressionISC DHCP has two ways to set an option value: the static one and the dynamic one where an expression is evaluated to give the value to use. Kea has the basic mechanism for expression evaluation so this feature should be implementable wit...ISC DHCP has two ways to set an option value: the static one and the dynamic one where an expression is evaluated to give the value to use. Kea has the basic mechanism for expression evaluation so this feature should be implementable without a large work.kea1.7.1Francis DupontFrancis Dupont