Kea 1.4 beta Adds Cassandra Backend

We are excited to share our latest Kea release, Kea 1.4. This is the beta test version, posted so users and prospective users can do some testing and give us feedback. We anticipate posting a final version on June 15th, so please get us your feedback in time to make any needed changes.

New Features in 1.4

Database improvements

Many Kea users report using multiple Kea instances sharing a single database backend, or cluster of databases. One of the frequently requested features was the ability to report accurate statistics in this case. This surprisingly tricky problem was solved for MySQL and PostgreSQL by a new stat_cmds hook library and schema updates. Users also requested the ability to automatically reconnect after the database connection is lost for whatever reason.

Kea has had experimental support for an Apache Cassandra database backend for a while, but the feature hadn’t been finished or fully tested. This has changed; the code now supports host reservations and has a great number of new smaller fixes and improvements. It is now both easier to install and much better documented. Thank you to Deutsche Telekom AG for sponsoring this work. We have done some initial performance testing of the Cassandra backend, but this is not a core expertise of ours. If any beta testers have experience with tuning Cassandra for optimal performance, we would welcome this input.

Classification

It is now possible to specify client classes on a pool level, so you can control who is able to use specific pools, group similar clients together, or even reject clients that don’t meet certain class requirements. Class expressions have expanded capabilities. The most popular seems to be a member operator, which determines whether a packet is a member of a given class. Complex boolean logic is available. Ever wanted to do member(foo) and not member(bar)? Now you can.

We hope this meets the needs ISC DHCP users have for permit/deny type statement. We would love to hear from beta testers if it does – or doesn’t – cover all your use cases.

Bug fixes and quality-of-life improvements

With 134 tickets closed, 1.4.0 beta is by far the biggest release we’ve ever done. We hope it will improve your quality of life!

We have also added 2 new features which are dependent on premium hook libraries. Premium hook libraries are a great way to provide financial support for the project, and get some additional functionality in return.

RADIUS

Kea can now be integrated with a RADIUS server, such as FreeRADIUS. Both access and accounting roles are supported. Kea is able to send Access-Request messages and alter its behavior depending on the responses. Specific IP addresses may be assigned (if Framed-IP-Address or Framed-IPv6-Address is received), and clients can be assigned to a specific pool (if Framed-Pool or Framed-IPv6-Pool is received) or denied service altogether (if Access-Reject is received). Kea can also send accounting messages to RADIUS accounting servers. As with other features, this supports both IPv4 and IPv6.

Some of the database backends may be slow to respond, compared to the expected response times for a DHCP request. To minimize the impact and improve performance, a new Host Cache library provides a way to cache responses from other hosts. This includes negative caching, i.e. the ability to remember that there is no client information in the database. We have included some simple cache management commands.

(The Host Cache library has been tested only with the RADIUS backend, which is particularly slow because RADIUS was originally designed for dial-up connection control. We would love to hear from beta testers if it is useful for the other database backends. We would also love to get feedback on how the host cache feature works in your network and whether you would like to see more cache management controls.)

High Availability

Many users have been accomplishing a kind of high-availability deployment by using a shared database backend. We wanted to make it possible to have high availability, even without using a database backend.

Two Kea instances can now be configured to run as a pair. Two modes are supported. In hot standby mode there is a primary instance handling all traffic and sending updates to its secondary partner. The secondary monitors the health of the primary and is able to take over automatically in case the primary fails. In load-balancing mode both partners are active and are each handling approximately half of the traffic. In case of a failure of either server, the partner is able to take over, responding to all traffic directed to both servers. Support for additional backup servers is implemented. The backup server’s database is updated as soon as possible after changes are made to the primary server’s database, so that it can be used as an almost drop-in replacement in case of catastrophic failures that take out both primary and secondary servers.

This solution supports both IPv4 and IPv6 and can work with any backend, including the default memfile. Note that this is NOT an implementation of the IETF standard DHCPv4 failover (which does not support DHCPv6). It is much simpler than the failover feature of ISC DHCP, which permits, for example, load-balancing machines to split the load 30/70 or 60/40 or any other arbitrary way.

We have tested the crap out of this feature, so we sure hope you don’t find any issues with it. 😉

Testing premium hooks

ISC Kea support customers will receive tickets inviting them to beta test the premium hooks, which are included with the support subscription. If you are interested in testing premium hooks and do not have a Kea support contract, please contact info at isc dot org to apply to beta test. We will give you a 100% discount coupon in exchange for your help in improving the software. Please let us know when you email which premium hook package(s) you want to test.

License

Kea 1.4.0-beta is released under the Mozilla Public License, version 2.0.

The premium hook libraries are provided in source code form, under the terms of an End User License Agreement (you are not permitted to redistribute).

Download the beta and start testing!

The Kea 1.4.0-beta source may be downloaded from this website or from our FTP site.

Other stuff about Kea

ISC provides detailed documentation, including installation instructions and usage tutorials in the Kea Administrator Reference Manual. Documentation is included with the installation or via https://kea.isc.org/docs in HTML, plain text, or PDF formats. ISC maintains a public open source code tree on Github and wiki pages with roadmap and issue tracking at kea.isc.org.

Limitations and known issues with this release can be found at https://gitlab.isc.org/isc-projects/kea/-/wikis/known-issues-list.

We’d like users of this software to please let us know how it worked for you and what operating system you tested on. Feel free to share your configuration or use case. Also we would like to hear whether the documentation is adequate and accurate (please open tickets for documentation omissions and errors). We want to hear from you even if everything worked.

Support

Professional support for Kea is available from ISC. We encourage all professional users to consider this option; Kea maintenance is funded with support subscriptions. For more information on ISC’s software support, please visit our Support page. Free best-effort support is provided by our user community via a mailing list. Information on all public email lists is available at https://www.isc.org/mailinglists.

If you have any comments or questions about working with Kea, please share them on the kea-users list.

Bugs and feature requests may be submitted via our GitLab repository at https://gitlab.isc.org/isc-projects/kea/-/issues.