Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2022-11-02T15:08:44Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/307queue by list of packets rather than one by one2022-11-02T15:08:44ZThomas Markwalderqueue by list of packets rather than one by oneI have created a branch which greatly simplifies the PacketQueue<> interface to provide implementations with much more latitude. Lower level functions, such as push, peek, and pop were moved down into PacketQueueRing<> (the default impl...I have created a branch which greatly simplifies the PacketQueue<> interface to provide implementations with much more latitude. Lower level functions, such as push, peek, and pop were moved down into PacketQueueRing<> (the default implementation base). It also replaces queuing a single packet, to queuing a list of packets. The latter change should reduce thread contention by enabling the receiving thread to read all ready packets and pass them into the queue in one call. Lastly, I split out the PacketQueueRing<> from dhcp/packet_queue.h into its own header, dhcp/packet_queue_ring.hbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/199Integrate DHCPv6 reconfigure message feature2022-11-02T15:08:42ZMayyaSunilIntegrate DHCPv6 reconfigure message featureReconfiguration feature was implemented partially as a part of GSoC 2018 project. This issue is to track the integration of the remaining feature into kea repo.Reconfiguration feature was implemented partially as a part of GSoC 2018 project. This issue is to track the integration of the remaining feature into kea repo.backlogMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/72Radius option definitions2023-06-19T11:01:38ZGhost UserRadius option definitionsThe RadiusDesign calls for an optional mechanism that will query the Radius server about specific client. Typically this functionality has been done by a relay, which then inserted Radius options into DHCP message before forwarding it to...The RadiusDesign calls for an optional mechanism that will query the Radius server about specific client. Typically this functionality has been done by a relay, which then inserted Radius options into DHCP message before forwarding it to the server.
Kea should be able to understand such options. See RFC4014 (v4) and RFC7037 (v6) for details. Kea should be able to represent radius attributes as sub-options, so general mechanisms, like client classification could be used.
This ticket calls for option definitions only. No special handling logic should be implemented.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/849Kea MySQL CB accepts an option for non-existing subnet2022-11-02T15:10:18ZMarcin SiodelskiKea MySQL CB accepts an option for non-existing subnetIt is possible to set a DHCP option with the `remote-option4-subnet-set` for non-existing subnet. It is possible that the same issue is present for other similar commands.It is possible to set a DHCP option with the `remote-option4-subnet-set` for non-existing subnet. It is possible that the same issue is present for other similar commands.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/688cb_cmds new remote-{subnet,shared-network}[46]-detach commands2022-11-02T15:10:17ZFrancis Dupontcb_cmds new remote-{subnet,shared-network}[46]-detach commandsThis is about config backend shareable objects so subnets and shared networks.
A subnet is shareable between several servers but remote-subnet[46]-del-by-* deletes the subnet object from the database so for all servers (MySQL schema cas...This is about config backend shareable objects so subnets and shared networks.
A subnet is shareable between several servers but remote-subnet[46]-del-by-* deletes the subnet object from the database so for all servers (MySQL schema cascade the delete on subnet_id so there is no dangling references in *_subnet_server tables).
IMHO we need new commands to detach a subnet (or a shared network) from a particular server so after the operation it still belongs to other servers (possibly none).
Note that remote-subnet[46]-set can be used to attach a subnet to a server so we do not need the opposite command.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/501remote-option4-global-set accepts option with empty data2022-10-24T08:02:55ZWlodzimierz Wencelremote-option4-global-set accepts option with empty data```
{
"arguments": {
"options": [
{
"code": 6
}
],
"remote": {
"type": "mysql"
},
"server-tags": [
"abc"
]
},
"command": "remote-option4-global-set"
}
```
Response:
```
{
"a...```
{
"arguments": {
"options": [
{
"code": 6
}
],
"remote": {
"type": "mysql"
},
"server-tags": [
"abc"
]
},
"command": "remote-option4-global-set"
}
```
Response:
```
{
"arguments": {
"options": [
{
"code": 6,
"space": "dhcp4"
}
]
},
"result": 0,
"text": "DHCPv4 option successfully set."
}
```
Kea should not be configured with empty option. Possible that it's not yet implemented.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/449Create AuditRevision object to carry supplementary information for audit entries2020-09-10T15:49:35ZMarcin SiodelskiCreate AuditRevision object to carry supplementary information for audit entriesThe CB database includes `dhcp4_audit_revision` table which holds general information about the changes applied in the database. Currently it holds a timestamp and the log message. The timestamp is and will remain being generated automat...The CB database includes `dhcp4_audit_revision` table which holds general information about the changes applied in the database. Currently it holds a timestamp and the log message. The timestamp is and will remain being generated automatically. The log message is also generated automatically at the moment but the idea is to be able to specify the log message in the command. Some examples can be found here:
https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-design#configuration-management
In the future we may store more information in the revision table. For example: name of the user who applied a change, IP address from which the command has been sent etc. This information must be encapsulated in a new object, e.g. AuditRevision and passed via the CB API to the commands that modify the information in the database, i.e. set and del commands.
Even though we could postpone this change to later Kea release, it may be actually better to add it now to keep the API stable in next releases.outstandinghttps://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/316Update DHCPv6 server to fully support RFC7550 (obsoleted by RFC 8415)2022-11-02T15:08:41ZMarcin SiodelskiUpdate DHCPv6 server to fully support RFC7550 (obsoleted by RFC 8415)While addressing https://gitlab.isc.org/isc-projects/kea/issues/288 I realized that DHCPv6 server logic follows rather simplified approach when it comes to Renew/Rebind processing. The following is the todo comment inserted as part of th...While addressing https://gitlab.isc.org/isc-projects/kea/issues/288 I realized that DHCPv6 server logic follows rather simplified approach when it comes to Renew/Rebind processing. The following is the todo comment inserted as part of the #288:
We should consider unification of the server behavior for address assignment and prefix delegation with respect to Rebind message processing. The RFC 8415, section 18.3.5 doesn't really differentiate between IA_NA and IA_PD in how they should be processed by the server. The intention of the spec is as follows:
- If the server finds a lease but addresses and/or prefixes are not
appropriate anymore, it sends them with zero lifetimes.
- If the server doesn't find a lease the server checks if the addresses
and/or prefixes the client sends are appropriate and sends them back
with zero lifetimes if they aren't.
- The server may choose to not respond at all, if it cannot determine
whether the addresses and/or prefixes are appropriate and it doesn't
allocate any other addresses and/or prefixes.
- If the server cannot find the leases included in the Rebind, the
server may either allocate the leases or simply return NoBinding.
The extendIA_PD function drops the Rebind message if it cannot find the client entry (as a result of not finding a subnet for the client), the extendIA_NA function sends NoBinding status code in that case. Perhaps we should introduce an "Authoritative" configuration flag which, if enabled, would cause the server to always respond, either indicating that the address/prefix is inappropriate (with zero lifetimes) or that there is no binding (NoBinding status code) for both addresses and prefixes. When the "Authoritative" flag is disabled the server would drop the Rebind for which there is neither subnet selected nor client entry found (as it could be handled by another DHCP server). If nothing else we could consider unifying the behavior of extendIA_NA and extendIA_PD with respect to Rebind processing.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/234ISC DHCP log executable statement2023-07-13T18:33:07ZFrancis DupontISC DHCP log executable statementAccording to ISC DHCP dhcp-eval(5):
>>>
log (priority, data-expr)
Logging statements may be used to send information to the standard
logging channels. A logging statement includes an optional priority
...According to ISC DHCP dhcp-eval(5):
>>>
log (priority, data-expr)
Logging statements may be used to send information to the standard
logging channels. A logging statement includes an optional priority
(fatal, error, info, or debug), and a data expression.
Logging statements take only a single data expression argument, so if
you want to output multiple data values, you will need to use the
concat operator to concatenate them.
>>>
It is an interesting feature which was discussed before (cf #4124).
To implement it in the ISC DHCP style we need 3 parameters:
- a boolean expression
- a priority
- a string expression to log
It does not seem so hard to do...backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/232Kea supports only Ethernet hardware type2022-11-02T15:08:43ZFrancis DupontKea supports only Ethernet hardware typeISC DHCP supports some other (real) hardware as FDDI... IMHO it should be allowed to use a number for the hardware type in >= 1.6.ISC DHCP supports some other (real) hardware as FDDI... IMHO it should be allowed to use a number for the hardware type in >= 1.6.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/226ISC DHCP server config option adaptive-lease-time-threshold2022-11-02T15:08:42ZFrancis DupontISC DHCP server config option adaptive-lease-time-threshold>>>
The adaptive-lease-time-threshold statement
**adaptive-lease-time-threshold** percentage;
When the number of allocated leases within a pool rises above the
percentage given in this statement, the DHCP server decreases the
lease len...>>>
The adaptive-lease-time-threshold statement
**adaptive-lease-time-threshold** percentage;
When the number of allocated leases within a pool rises above the
percentage given in this statement, the DHCP server decreases the
lease length for new clients within this pool to min-lease-time sec-
onds. Clients renewing an already valid (long) leases get at least
the remaining time from the current lease. Since the leases expire
faster, the server may either recover more quickly or avoid pool
exhaustion entirely. Once the number of allocated leases drop below
the threshold, the server reverts back to normal lease times. Valid
percentages are between 1 and 99.
>>>
A good idea for a lease allocation hook library.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/221Kea vs ISC DHCP timers2022-11-02T15:08:43ZFrancis DupontKea vs ISC DHCP timersISC DHCP uses 3 values (max, min and default) values for lease-time (valid-lifetime) in Kea).
These 3 values are in the Kea code (aka the triplet class) but are not reflected in config. (note I don't say a solution is better but they are...ISC DHCP uses 3 values (max, min and default) values for lease-time (valid-lifetime) in Kea).
These 3 values are in the Kea code (aka the triplet class) but are not reflected in config. (note I don't say a solution is better but they are different). As the valid-lifetime is a mandatory config parameter this means Kea is rigid (same comment).
For other timers ISC DHCP has preferred-lifetime but derives t1 and t2 (aka renew and rebind timers) from the valid one using standard formula. ISC DHCP follows more the client query, i.e., it uses configured values including computed values only as default and bounds.
This is not a call to change something: it is just a summary for documentation and some infos in the case a customer requests more flexibility.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/218ISC DHCP server config option stash-agent-options2023-07-12T16:34:35ZFrancis DupontISC DHCP server config option stash-agent-optionsThe stash-agent-options statement
>>>
**stash-agent-options flag;**
If the stash-agent-options parameter is true for a given client,
the server will record the relay agent information options sent
during the client's initial DHCPREQUEST...The stash-agent-options statement
>>>
**stash-agent-options flag;**
If the stash-agent-options parameter is true for a given client,
the server will record the relay agent information options sent
during the client's initial DHCPREQUEST message when the client
was in the SELECTING state and behave as if those options are
included in all subsequent DHCPREQUEST messages sent in the RENEWING
state. This works around a problem with relay agent information
options, which is that they usually not appear in DHCPREQUEST
messages sent by the client in the RENEWING state, because such
messages are unicast directly to the server and not sent through a
relay agent.
>>>
It is a real issue (for DHCPv4, in DHCPv6 the server controls the use of unicast (i.e. direct communication) by the client) but I have no idea how (or whether) it is handled by Kea...backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/217scoped D2 client config2022-11-02T15:08:43ZFrancis Dupontscoped D2 client configReading Dan's ISC DHCP config it seems the really useful scoped D2 client config extension is to be able to enable or disable D2 (using enable-updates) in some specific scopes (e.g. a subnet or a class).
Perhaps there is another issue a...Reading Dan's ISC DHCP config it seems the really useful scoped D2 client config extension is to be able to enable or disable D2 (using enable-updates) in some specific scopes (e.g. a subnet or a class).
Perhaps there is another issue about this but if we do the minimum it should be this.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/133Discussion about ordering in configurations.2022-11-02T15:08:43ZFrancis DupontDiscussion about ordering in configurations.It concerns mainly subnets and client classes but most of this is generic, e.g. can be applied to shared networks:
- memory representation must use a multi index container with a sequenced or random access index to implement the order, ...It concerns mainly subnets and client classes but most of this is generic, e.g. can be applied to shared networks:
- memory representation must use a multi index container with a sequenced or random access index to implement the order, in particular we must to not add previous or next field to objects themselves.
- database representation must use previous and next columns in rows to implement a double linked list. First and last rows have a reserved previous or next value (e.g. id 0 for subnets).
- command hooks must add a before or after to insert command (vs always nsert at the end) and an easy way to get the order itself, e.g. the order list of entries used as index (subnet id, client class name, ...).
- optionally (i.e. not in 1.5) we can add a relocate command.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/77memfile: add a command to force writing in-memory DB to file2022-11-02T15:08:43ZGhost Usermemfile: add a command to force writing in-memory DB to filememfile keeps leases in memory and writes changes to disk. If the leasefile is lost for whatever reason, it may be useful to tell Kea to write is entire lease file to disk.memfile keeps leases in memory and writes changes to disk. If the leasefile is lost for whatever reason, it may be useful to tell Kea to write is entire lease file to disk.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/46Please add circuit-ID to result of get lease-42022-11-02T15:08:42ZGhost UserPlease add circuit-ID to result of get lease-4We want to identify leases with circuit ID, how can we get the circuit ID with the lease4-get?
I want to search for a lease with the circuit ID with lease-get.
Vennlig hilsen / Best regards
Frode SætreWe want to identify leases with circuit ID, how can we get the circuit ID with the lease4-get?
I want to search for a lease with the circuit ID with lease-get.
Vennlig hilsen / Best regards
Frode Sætrebackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/41Kea should be able to print performance metrics2023-01-09T12:25:26ZGhost UserKea should be able to print performance metricsWhen debugging an issue, it became clear that finding out how long it takes Kea to process a packet and actually send a response is difficult. It requires matching different log entries, which sometimes is very problematic if there are m...When debugging an issue, it became clear that finding out how long it takes Kea to process a packet and actually send a response is difficult. It requires matching different log entries, which sometimes is very problematic if there are multiple packets sent from a client.
We should develop a way to measure how long it takes to process a packet. The easiest way will be to use a stopwatch (see src/lib/util/stopwatch.h). I think we should remember the timestamp somewhere in Pkt4 (and possibly Pkt6) very early when the packet is received (perhaps in Pkt4 constructor?) and then print the interval value once the response packet is being sent out.
I think it would be useful to have separate logger for this, maybe call it performance or perf? If the concept proves to be useful, we may soon extend it to print out more detailed information about different stages (it took X ms to find host reservation, Y ms to select a lease, Z ms to do DNS update etc).backlog