Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-06-15T16:13:14Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2875perfdhcp enhancements: do not allow -6 -J usage without -A2023-06-15T16:13:14ZPiotrek Zadrogaperfdhcp enhancements: do not allow -6 -J usage without -AWhile working on #2834 it occurred to me that using `perfdhcp -6 -J` without `-A1` makes no sense.
It could be considered as an exception and some nice hint could be returned to the user.While working on #2834 it occurred to me that using `perfdhcp -6 -J` without `-A1` makes no sense.
It could be considered as an exception and some nice hint could be returned to the user.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3250Unattended terminated state and a reboot2024-03-27T21:53:51ZMarcin SiodelskiUnattended terminated state and a rebootConsider the following case. The clocks on two HA-enabled servers diverge and the clock skew eventually exceeds 60 seconds. As a result, both servers transition to the terminated state. In this state, the servers continue serving DHCP cl...Consider the following case. The clocks on two HA-enabled servers diverge and the clock skew eventually exceeds 60 seconds. As a result, both servers transition to the terminated state. In this state, the servers continue serving DHCP clients but do not exchange the lease updates nor heartbeats. An administrator neglects to correct the clocks and one of the servers reboots. The server enters the `waiting` state and remains in this state hoping that the other server is restarted so they can continue the lease database synchronization and start normal operation. However, the server is unaware that its reboot was not triggered in the course of fixing the clocks, so it will wait for the partner endlessly (or until the administrator comes to work in the morning). The waiting server is not responding to the DHCP traffic until then.
This situation should not occur in a setup where NTP has been enabled. It also should not occur if there is a proper monitoring to detect that the clocks diverge early enough. However, there are chances this situation may happen when all of this is neglected.
The proposed solution is to apply a timeout (could even be several to 10 minutes long) for a server in the waiting state. If the transition of its partner does not occur until this timeout elapses, the server in the waiting state transitions back to the terminated state and continues serving the clients. The waiting server MUST NOT transition to the waiting state immediately after it detects that its partner is in the terminated state to allow enough time to the administrator to reboot the server sequentially after correcting the clocks.
[SF1598](https://isc.lightning.force.com/lightning/r/Case/500S6000003jBs3IAE/view)kea2.5.8https://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/2824Optimizations in the allocator selection: copy the existing state2023-04-13T13:49:14ZMarcin SiodelskiOptimizations in the allocator selection: copy the existing stateThe random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and ...The random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and the subnet pools, we could perhaps avoid re-building the allocator state but keeping the existing state aside, and then copying the pointer to the allocation state to the new subnet instance. In that case we'd only have the overhead during the startup, renumbering and an allocator change. In all other cases, the reconfiguration would be smooth.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2771Optionally fuse sent vendor options2023-03-16T14:32:36ZFrancis DupontOptionally fuse sent vendor optionsCurrently with multiple vendors one vendor option is sent for each vendor: this is RFC compliant but can disturb clients: the idea is to create new builtin client classes which fuse vendor options when set (and when sizes permit).
(this...Currently with multiple vendors one vendor option is sent for each vendor: this is RFC compliant but can disturb clients: the idea is to create new builtin client classes which fuse vendor options when set (and when sizes permit).
(this ticket is mostly to save the idea i.e. not to be addressed before a problem is reported)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2763Lease start time of state2023-04-28T07:24:29ZFrancis DupontLease start time of stateBoth v4 Bulk Leasequery (BLQ) and RADIUS accounting have use of keeping the start time of state for assigned leases i.e. the date of the transistion to the default (0) state. This ticket proposes to keep it in the user context, the RADIU...Both v4 Bulk Leasequery (BLQ) and RADIUS accounting have use of keeping the start time of state for assigned leases i.e. the date of the transistion to the default (0) state. This ticket proposes to keep it in the user context, the RADIUS table keeping it can be reused for the design.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2592partner-down state transition when max-unacked-clients reached2022-11-24T14:45:22ZMarcin Siodelskipartner-down state transition when max-unacked-clients reachedSuppose the server lost the connection with its partner. The server begins the failover procedure by checking whether or not the partner responds to the DHCP queries. The `max-unacked-clients` setting controls how many different clients ...Suppose the server lost the connection with its partner. The server begins the failover procedure by checking whether or not the partner responds to the DHCP queries. The `max-unacked-clients` setting controls how many different clients should retry getting the lease with the increased value of the `secs` field before the server considers partner dead. One would expect the server to make `partner-down` transition as soon as the number of unacked clients reaches the configured number. In fact, the state transitions are generally performed when the server completes a heartbeat or a lease update. It is possible that under heavy traffic there will be much larger number of unacked clients and the server still sits in the normal state (e.g. hot-standby), waiting for the heartbeat trigger. Assuming the heartbeat interval is reasonable, it should probably be fine. However, we may consider starting the transition as soon as the number of unacked clients reaches the configured maximum.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2256Prepare subnet selection speedup: patrica trees2023-06-19T12:08:06ZFrancis DupontPrepare subnet selection speedup: patrica treesPatricia trees are the optimal general data structure for IP prefix lookup: the number of comparisons is bounded by the number of bits so 32 or 128 for IP, the real number depends on the number of nodes where children differs and in the ...Patricia trees are the optimal general data structure for IP prefix lookup: the number of comparisons is bounded by the number of bits so 32 or 128 for IP, the real number depends on the number of nodes where children differs and in the real world is far lower.
BTW the current code just iterates on all subnetworks so is linear in the number of subnets (average case N/2, N for the worst case which includes the not found case). The patricia tree gives also overlaps (equality or inclusion).backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2255Prepare subnet selection speedup: auxiliary tables2023-07-31T13:32:51ZFrancis DupontPrepare subnet selection speedup: auxiliary tablesThere are at least two cases where an index can or should not be used/added to a multi index:
- when the corresponding data structure is not supported, e.g. patricia tree for IP prefixes
- when the default is very common: the multi ind...There are at least two cases where an index can or should not be used/added to a multi index:
- when the corresponding data structure is not supported, e.g. patricia tree for IP prefixes
- when the default is very common: the multi index works but gives a lot of values for this default value so it doubles the insert/delete operation time
- when a direct index value change is convenient: this breaks the multi index so must not be done (instead the multi index must be updated which is a complex (to code) and slow (to execute) operation)
The solution is to add in parallel of a multi index soem auxiliary tables which provide a specific lookup. The auxiliary table is a base type with add, delete and change (which is in general delete followed by add).backlogRazvan BecheriuRazvan Becheriuhttps://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/1942Refactor ClientClassDictionary to provide indexing2022-11-02T15:10:41ZMarcin SiodelskiRefactor ClientClassDictionary to provide indexingI would like to propose refactoring the `ClientClassDictionary` internals to support indexing classes by various parameters. Right now we index by class names and we have an ordered index. In #1836 we are adding a change which matches cl...I would like to propose refactoring the `ClientClassDictionary` internals to support indexing classes by various parameters. Right now we index by class names and we have an ordered index. In #1836 we are adding a change which matches classes with configured server identifiers. Without indexing, such matching is sub-optimal. Perhaps, if we migrate the class collection to multi index container we could easily add additional indexing if necessary.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1532rawip interface support2020-11-26T16:59:22ZFrancis Dupontrawip interface supportA patch (https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/66) was proposed for ISC DHCP to add support for interfaces using the rawip ARP hardware type. I propose when the ISC DHCP part will be ready to do the same for Kea.
(tr...A patch (https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/66) was proposed for ISC DHCP to add support for interfaces using the rawip ARP hardware type. I propose when the ISC DHCP part will be ready to do the same for Kea.
(triage proposal: put it in 1.x and re-triage it when the ISC DHCP part will be ready)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1420Speedup subnet selection: less indexes2023-07-31T12:45:46ZFrancis DupontSpeedup subnet selection: less indexesChild of #554
Subnet and shared network collections have subnet4 4, subnet6 3, shared network4 5 and shared network6 4 indexes. Some are clearly useless and can be removed, including the one making a difference between v4 and v6.Child of #554
Subnet and shared network collections have subnet4 4, subnet6 3, shared network4 5 and shared network6 4 indexes. Some are clearly useless and can be removed, including the one making a difference between v4 and v6.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1133Modify perfdhcp to track stats per subnet, when mulitple subnets are targetted2022-11-02T15:10:20ZThomas MarkwalderModify perfdhcp to track stats per subnet, when mulitple subnets are targettedIt would be handy if perfdhcp could track statistics for each subnet it has been told to send target.It would be handy if perfdhcp could track statistics for each subnet it has been told to send target.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1029New built-in client class for incomplete unpacking2020-01-09T16:56:32ZFrancis DupontNew built-in client class for incomplete unpackingCurrent Kea accepts packets which have a not fatal error during unpacking. I believe it was added by @tmark: in such case the SkipRemainingOptionsError exception is thrown and processing continue.
I'd like to put such packets in a new b...Current Kea accepts packets which have a not fatal error during unpacking. I believe it was added by @tmark: in such case the SkipRemainingOptionsError exception is thrown and processing continue.
I'd like to put such packets in a new built-in class so a "not option[xxx].exist" can't be mislead: it will be enough to add "add not member("<new-class-name>')".
This allows too to classify such packets in the DROP class so by configuration accept or drop them.outstandinghttps://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/1009Provide a standard queue choice for packet queue2019-12-12T16:57:24ZFrancis DupontProvide a standard queue choice for packet queueToday we have only the ring but even with an infinite (0) capacity it is not the same than a queue.
Whether this should stay internal to the dhcp library or available to DHCP server syntaxes is still a subject for discussion.Today we have only the ring but even with an infinite (0) capacity it is not the same than a queue.
Whether this should stay internal to the dhcp library or available to DHCP server syntaxes is still a subject for discussion.outstandinghttps://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/822Consider returning a list of shared networks, subnets etc for which options h...2022-11-02T15:10:17ZMarcin SiodelskiConsider returning a list of shared networks, subnets etc for which options have been setThe #418 introduced commands that allow for adding new option within the shared network, subnet etc. The response contains a list of options that have been set but it lacks the list of parent objects. We may consider also returning the p...The #418 introduced commands that allow for adding new option within the shared network, subnet etc. The response contains a list of options that have been set but it lacks the list of parent objects. We may consider also returning the parent objects but this is not critical in 1.6.0 release. Therefore, creating this ticket to address this in the future.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/792quality of life improvement: kea-admin db-version fails on empty db2022-03-31T08:12:51ZTomek Mrugalskiquality of life improvement: kea-admin db-version fails on empty dbkea-admin db-version prints the following error:
```
# kea-admin db-version mysql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1146 (42S02) at line 1: Table 'keatest.schema_version' doesn't exis...kea-admin db-version prints the following error:
```
# kea-admin db-version mysql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1146 (42S02) at line 1: Table 'keatest.schema_version' doesn't exist
```
when run on an empty DB (without any schema).
Instead, it should catch the fact that schema_version does not exist and should point user to kea-admin db-init command.
This is a quality of life improvement, so it's not terribly important.outstanding