Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2019-04-11T15:21:22Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/16Make Cassandra connection parameters configurable [ISC-support #13376]2019-04-11T15:21:22ZBrian ConryMake Cassandra connection parameters configurable [ISC-support #13376]The request from the customer:
> I have been spending some time setting Kea up with Cassandra across multiple datacenters, and I believe there is a configuration issue with the current CQL connection manager. It forces consistency to CA...The request from the customer:
> I have been spending some time setting Kea up with Cassandra across multiple datacenters, and I believe there is a configuration issue with the current CQL connection manager. It forces consistency to CASS_CONSISTENCY_QUORUM (and I believe it does so for both reads and writes).
>
> Cassandra considers a "cluster" to include all servers across all datacenters. In a deployment with 3 servers in Site1, 3 servers in Site2, and a replication factor of 3 at each site (each node holding a copy of all data), a quorum is 4 servers. This means that any read or write to Site1 must cross the country from Site1 to at least one node in Site2. This ensures strong consistency but doesn't work well with multi-datacenter latency. Worse yet, it means that a datacenter-wide failure of Site2 creates a failure of Site1 because a quorum can't be achieved, as only 3 servers would be available.
>
> I think CASS_CONSISTENCY_LOCAL_QUORUM is probably a better default- it still requires a quorum but is aware of the Cassandra network topology when calculating the servers required for a quorum. In this case, a write to Site1 would require 2 of the 3 servers at that site. This also works with Cassandra's 'SimpleStrategy' if multiple data centers aren't being used- and it would be equivalent to CASS_CONSISTENCY_QUORUM in SimpleStrategy. Replication across datacenters would be eventually consistent, but there would be strong consistency within a datacenter.
>
> Ideally, the consistency for reads and writes would be independently configurable via the backend configuration. This would let the user assess the risk of conflicts and pick the consistency that makes the most sense for their deployment.
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigConsistency.htmlKea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/33CB: Add support for 'reload-subnets' command2019-02-19T12:25:11ZGhost UserCB: Add support for 'reload-subnets' commandOnce all other configuration scaling tickets are done (#3579-#3584), a command that triggers the server to reload subnet configuration would be useful.Once all other configuration scaling tickets are done (#3579-#3584), a command that triggers the server to reload subnet configuration would be useful.Kea1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/35local d2 (dhcp-ddns) client config2019-10-30T15:37:54ZGhost Userlocal d2 (dhcp-ddns) client configCurrently the d2 (dhcp-ddns) config is global. The idea allows to make it locally, e.g.., in subnet and client class scopes. Cf Migration #5224.Currently the d2 (dhcp-ddns) config is global. The idea allows to make it locally, e.g.., in subnet and client class scopes. Cf Migration #5224.kea1.7.1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/145feature request: ability to get lease count per pool2023-07-17T13:58:21ZGhost Userfeature request: ability to get lease count per pooltoday, when using the api command - "statistic-get-all"
we are getting a lease count at the subnet level,
i'm asking to get a count at the pool level.
thank you
#huge-sorrytoday, when using the api command - "statistic-get-all"
we are getting a lease count at the subnet level,
i'm asking to get a count at the pool level.
thank you
#huge-sorrykea2.3.8Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/149[ISC-support #20800] Improvements to Kea client packet processing - handling ...2022-05-20T15:00:02ZCathy Almond[ISC-support #20800] Improvements to Kea client packet processing - handling host reservationsOption to perform earlier host reservation lookup and then (optionally) to suppress this later if it has already been done.
---
This feature request originated in Support ticket https://support.isc.org/Ticket/Display.html?id=13430
The...Option to perform earlier host reservation lookup and then (optionally) to suppress this later if it has already been done.
---
This feature request originated in Support ticket https://support.isc.org/Ticket/Display.html?id=13430
The use case from this production environment is slightly complicated - multiple client requests for different services that 'look' like different and independent clients, whereas they're all originating from the same consumer provisioning. They can be associated with their consumer via the MAC address of the CPE device at the consumer premises. These all have host reservations in Kea; the CPE device MAC address can be added to the client packet.
The problem then is that host reservation processing takes place after subnet allocation, so it's not possible to use built-in host reservation process (e.g. against flex-id) for classification and subnet selection - it's too late.
The host reservation lookup is easily done earlier by means of a custom hook using a callout at pkt4_receive that:
- pulls the info from the packet
- uses that to call HostMgr to retrieve the global host reservation using the identifier retrieved from the client packet (as opposed to the client's own source MAC address)
- from that information sets class values
- lets Kea assign subnet appropriately
The downside of this approach is that this adds an additional host reservation lookup to the client packet processing flow.
Some environments might actually want the second host reservation lookup (it depends where the second MAC address has been added to the client packet and whether or not this involves flex-id), or they might not.
This feature request is raised to look at the use cases vs. processing flow/ordering to see if there's scope to add more flexibility/tuning.
(I would also hope that any work in this area tries hard to keep the configuration control for this as simple and as intuitive as possible).kea2.1.6https://gitlab.isc.org/isc-projects/kea/-/issues/150[ISC-support #13437] Have vendor option processing made accessible to classif...2019-09-13T13:17:38ZCathy Almond[ISC-support #13437] Have vendor option processing made accessible to classification for subnet allocationThere's a chicken-and-egg problem. Option 43 syntax is vendor specific, so Kea allows adding option definitions to client class, so you can have vendor dependent parsing. However, to use this the packet needs to be classified first. But...There's a chicken-and-egg problem. Option 43 syntax is vendor specific, so Kea allows adding option definitions to client class, so you can have vendor dependent parsing. However, to use this the packet needs to be classified first. But what if you want to use values in option 43 suboptions to assist with classification? Parsing them using "substring" relies on all client packets having the same vendor options/suboptions in the same order - this can't be guaranteed.
---
This feature request originated in Support ticket https://support.isc.org/Ticket/Display.html?id=13437
The use case from this production environment is from the same environment as presented in https://gitlab.isc.org/isc-projects/kea/issues/149.
In this instance, additional classification is desired, based on the vendor options.
A workaround was created adding further processing to an already-existing custom hook with callout at pkt4_receive.
The processing flow within this hook was extended to add something along the lines of:
```
Pkt4Ptr pkt;
callout_handle->getArgument("query4", pkt);
OptionPtr option43 = pkt->getOption(43);
OptionPtr option2 = option43->getOption(2);
if (option2) {
std::string payload(option2->getData().begin(), option2->getData().end());
if ((payload == "MTA") || (payload == "EMTA")) {
pkt->addClass("MTA");
}
}
```
(Note that the above syntax is example-only and not tested in production)Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/160non-root Kea processes2021-10-25T16:03:58ZAdam Osuchowskinon-root Kea processesPlease consider using POSIX capabilities for improve security and make Kea servers not to run with root privileges. I think CAP_NET_RAW capability should be enough to run all functionality of Kea. Daemons should start with root privilege...Please consider using POSIX capabilities for improve security and make Kea servers not to run with root privileges. I think CAP_NET_RAW capability should be enough to run all functionality of Kea. Daemons should start with root privileges, then should set only required capabilities (CAP_NET_RAW or, if need be, other) and switch privileges to other non-root user.kea1.7.5https://gitlab.isc.org/isc-projects/kea/-/issues/167Log client fingerprinting data2022-06-03T11:59:27ZVicky Riskvicky@isc.orgLog client fingerprinting dataIdentifying client device types via 'fingerprinting' is a common feature of dhcp mgmt utilities. Some users who want to do this themselves are asking where they can get the raw data from Kea. They could then use one of the open source d...Identifying client device types via 'fingerprinting' is a common feature of dhcp mgmt utilities. Some users who want to do this themselves are asking where they can get the raw data from Kea. They could then use one of the open source databases such as https://fingerbank.org to determine via post processing what device type the client most likely is.
Can we log the order in which the client requests options as well as the vendor ID for use by a fingerprinting service? (e.g. options 55 and 60 from the REQUEST for DHCPv4)
This could be added to the existing forensic log hook, or we could create another hook.outstandingPeter DaviesPeter Davieshttps://gitlab.isc.org/isc-projects/kea/-/issues/204checking version of yang models2018-12-11T17:08:44ZWlodzimierz Wencelchecking version of yang modelsDo we plan for a tool/extension that will check version of an installed yang models? Something similar to kea-admin checking db schema.Do we plan for a tool/extension that will check version of an installed yang models? Something similar to kea-admin checking db schema.Kea1.5-finalFrancis DupontFrancis Duponthttps://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 Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/279Built-in Prometheus stats exporter and Grafana template [ISC-support #14725]2020-04-16T13:31:01ZVicky Riskvicky@isc.orgBuilt-in Prometheus stats exporter and Grafana template [ISC-support #14725]
Please add a feature to export Kea statistics to Prometheus
Please publish a Grafana template for displaying the statistics in a useful way. (I will open a separate ticket for this, but the two should be tested together).
**Some initia...
Please add a feature to export Kea statistics to Prometheus
Please publish a Grafana template for displaying the statistics in a useful way. (I will open a separate ticket for this, but the two should be tested together).
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
Yes
- Are you sure what you would like to do is not possible using some other mechanisms?
It is possible to manually import the Kea stats into Prometheus but this would make it easier, more automatic.
It is also possible to implement a Prometheus client in Kea. This is more work, a tighter integration and is not what I am asking for here.
- Have you discussed your idea on kea-users or kea-dev mailing lists?
No. But if we are about to implement it, I would be happy to ask on Kea-users if people want it.
This was requested by an ISC Kea support customer.
**Is your feature request related to a problem? Please describe.**
It would be nice if we could simplify the process of exporting and displaying Kea statistics for users of these two popular open source projects (Prometheus and Grafana).
**Describe the solution you'd like**
User can enable stats export to Prometheus.
User must install Prometheus and configure Prometheus 'target' system information in Kea
User may optionally select/tailor which statistics to export, or use the reasonable default we establish.
**Describe alternatives you've considered**
An alternative would be implementing a Prometheus client.https://prometheus.io/docs/instrumenting/clientlibs/
**Additional context**
https://prometheus.io/docs/instrumenting/exporters/
Direct link: [support#14725](https://support.isc.org/Ticket/Display.html?id=14725)kea1.7.7https://gitlab.isc.org/isc-projects/kea/-/issues/280Publish a Grafana template for Kea statistics2020-04-16T15:12:47ZVicky Riskvicky@isc.orgPublish a Grafana template for Kea statisticsMany operators who are monitoring multiple systems prefer to have a single dashboard from which they can monitor all those systems at once.
It would be nice to have a template for the Grafana visualization system that is organized to h...Many operators who are monitoring multiple systems prefer to have a single dashboard from which they can monitor all those systems at once.
It would be nice to have a template for the Grafana visualization system that is organized to help Kea operators quickly scan their system status and identify any anomalous traffic patterns. Then users who are using Grafana for monitoring other systems can just switch over to look at the Kea window.
This is not Kea development, it is a separate, but small, project, to produce a template and publish it.
Things users would like to be able to see at a glance:
* requests & leases per subnet over time (so you can see usage patterns)
* leases by address type (dynamic, static, prefixes)
* if possible, leases per address pool size (so you can see pool utilization go up and down) (I dk if we can get pool size via the stats)
* IPv4 vs IPv6 usage
* the time to respond (I dk the name of this stat but I know we monitor it as part of the HA feature)
* per server and possibly, aggregated over multiple servers?
* ha/failover status changes
If we also develop and support a Prometheus exporter, Prometheus has a plug-in for Grafana, so the whole system would be nicely integrated. https://grafana.com/plugins/prometheus
This feature was requested by an ISC Kea support customer.kea1.7.7Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/313Return a list of all reservations by subnet ID2019-05-02T17:33:52ZMichael McNallyReturn a list of all reservations by subnet IDKea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/314subnet based ddns / “qualifying-suffix” per subnet2020-01-16T16:29:34ZGhost Usersubnet based ddns / “qualifying-suffix” per subnet---
name: Feature request
about: Use different Subdomain on different Subnets
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
Yes
- Are you sure what you would like to do...---
name: Feature request
about: Use different Subdomain on different Subnets
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
Yes
- Are you sure what you would like to do is not possible using some other mechanisms?
Yes
- Have you discussed your idea on kea-users or kea-dev mailing lists?
https://www.mail-archive.com/kea-users@lists.isc.org/msg00646.html
There is an old same request and open Ticket: http://kea.isc.org/ticket/5048
**Is your feature request related to a problem? Please describe.**
Users on 192.168.1.x/24 get *.foo.domain.local
Users on 172.16.x.x/16 get *.bar.domain.local
**Describe the solution you'd like**
“qualifying-suffix” per subnet
I saw a pull requests for kea 1.4. But we are using kea 1.5
https://github.com/isc-projects/kea/pull/106/commits/78e56b59d47a069fa75b1e144d83407da0f3b448kea1.7.4https://gitlab.isc.org/isc-projects/kea/-/issues/318REST API health endpoint (GH#96)2020-06-04T22:25:20ZVicky Riskvicky@isc.orgREST API health endpoint (GH#96)<This issue was originally opened on Github as issue #96 by Smithx10@github.com on July 19, 2018>
**Describe the solution you'd like**
A Health Endpoint via the REST API that informs the user if the Kea Services are healthy and serving....<This issue was originally opened on Github as issue #96 by Smithx10@github.com on July 19, 2018>
**Describe the solution you'd like**
A Health Endpoint via the REST API that informs the user if the Kea Services are healthy and serving.
ex: localhost:8080/health
Would respond with a JSON object with some brief information about the KEA services running on the server and their health status.
**Describe alternatives you've considered**
```
status=keactrl status | grep "DHCPv4 server" | awk '{print $3}'
if [[ "${status}" == "active" ]] then;
_log "DHCP is healthy"
return 0
else
_log "DHCPv4 is not healthy"
return 1
fi
```
Related issue: #79https://gitlab.isc.org/isc-projects/kea/-/issues/340Make perfdhcp build optional.2019-02-05T22:19:12ZFrancis DupontMake perfdhcp build optional.Same than for the kea-shell. Two questions:
- is it a good idea?
- what should be the default (on vs off)?Same than for the kea-shell. Two questions:
- is it a good idea?
- what should be the default (on vs off)?Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/365Automatically calculate the values for options 58 and 592019-04-26T15:37:42ZCathy AlmondAutomatically calculate the values for options 58 and 59---
name: Automatically calculate the values for options 58 and 59
about: This is a request to have it be possible for Kea to calculate and send the values for renew-timer and rebind-timer (T1 and T2) using 0.5 * duration_of_lease, and ...---
name: Automatically calculate the values for options 58 and 59
about: This is a request to have it be possible for Kea to calculate and send the values for renew-timer and rebind-timer (T1 and T2) using 0.5 * duration_of_lease, and 0.875 * duration_of_lease, respectively
---
**Some initial questions**
This is a request from a customer, per ticket [#13977](https://support.isc.org/Ticket/Display.html?id=13977)
At the moment, ISC Kea defaults to not sending T1 and T2, although they can be specified explicitly using optional renew-timer and rebind-timer. What is being requested is another option in which we ask Kea to automate this - i.e. to calculate them based on the lease time being offered using the default behaviour that clients should be adopting as noted above.
The reason for requesting this is that:
a) Other DHCP servers (e.g. Nominum) do this by default (even though ISC DHCP does not)
b) It is a potential mitigation for clients that are not fully RFC-compliant
**Describe the solution you'd like**
In it's simplest form, a blanket option to request that Kea calculate the timers and send them for any lease offer, calculations being appropriate to that specific offer.
More flexibility might be appreciated however - for example being able to set this per subnet, pool or shared-network to override a global setting which might be different.
For full flexibility, the option could perhaps also have an alternative syntax in which it accepts the percentages as an override to the default of .5 and .875 - although this might be overkill - would anyone want these to be different? (Perhaps leading up to a pool/servers migration maybe?)
**Describe alternatives you've considered**
Currently, the only way to ensure that ISC Kea sends the values of T1 and T2 that are wanted is to configure them explicitly, it's not possible to have them sent automatically
**Additional context**
Note that this may be regarded as a compatibility issue by anyone migrating to ISC Kea from another DHCP server implementation that does automatically send T1 and T2.Kea1.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/465Add subnet4-update and subnet6-update commands to subnet-cmds hook [ISC-suppo...2019-04-19T11:25:18ZVicky Riskvicky@isc.orgAdd subnet4-update and subnet6-update commands to subnet-cmds hook [ISC-support #14130]In order to update an existing subnet, you (currently) have to first delete it and then add it.
When making a small change to a large number of subnets, this can create excessive amount of traffic.
Could we please have additional comman...In order to update an existing subnet, you (currently) have to first delete it and then add it.
When making a small change to a large number of subnets, this can create excessive amount of traffic.
Could we please have additional commands to update an existing subnet?
This was part of the original design, but we didn't implement it at the time (likely ran out of time)
https://gitlab.isc.org/isc-projects/kea/wikis/designs/commands#24-subnets-management
S.7. Kea MAY support the #FF0000 subnet4-update command.
S.8. Kea MAY support the #FF0000 subnet6-update command.
From the wiki:
Those two commands allow making changes to an existing subnet: changing prefix, prefix length, T1, T2, preferred lifetime, valid lifetime timers, allowed client classes, subnet specific options, and subnet-id values. It also allows modifying pools.
Kea1.6Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/470server-tag-get-command2019-08-01T19:46:01ZWlodzimierz Wencelserver-tag-get-commandWhen I was writing some tests for db backend I noticed that to set tag of a server you have to:
* add it in local config file
* use config-set
is it possible/useful to have command just for tags?When I was writing some tests for db backend I noticed that to set tag of a server you have to:
* add it in local config file
* use config-set
is it possible/useful to have command just for tags?Kea1.6-finalFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/544leaseX-del & dns [ISC-support #14379]2020-07-21T13:43:49ZShawn RouthierleaseX-del & dns [ISC-support #14379]When the lease4-del and lease6-del commands remove a lease it should also trigger a DDNS remove operation
(or perhaps have a flag to allow for removing the DDNS entries).When the lease4-del and lease6-del commands remove a lease it should also trigger a DDNS remove operation
(or perhaps have a flag to allow for removing the DDNS entries).kea1.7.10Thomas MarkwalderThomas Markwalder