Kea 1.4 is ready for download and use. This is a big release, with several significant new features.
For users who have adopted Kea because they love the database backend, for lease and host reservations storage, we have added a new database and improved our statistics:
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.
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 reconnect after the database connection is lost for whatever reason, and this has been implemented. NOTE: you will need to upgrade any existing MySQL and PostgreSQL Kea databases to the new schema versions.
For users who need complex client classification options, 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.
NB: Client Classification changes coming
Both Kea and ISC DHCP assign options to clients based on a fixed option precedence order. However, the configuration categories are not evaluated in the same order in both servers.
In a future version of Kea, probably in Kea 1.5, we would like to adjust the option precedence order for Kea so that it matches the order for ISC DHCP (to simplify configuration for users migrating to Kea). Because this is a potentially disruptive change to existing Kea users, we want to give advance notice that we are planning this. To express your feedback about this pending change, please send your comments to firstname.lastname@example.org.
For users who may have been waiting for some feature equivalent for DHCPv4 failover in Kea, we have added:
To provide a highly available service, despite server failure, two Kea instances can now be configured to run as a pair.
Two modes are supported.
In load balancing mode both partners are active and are 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.
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.
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.
The solution supports both IPv4 and IPv6 and can work with any backend, including memfile. Note that this is NOT an implementation of the IETF standard DHCPv4 failover (which does not support DHCPv6).
This ISC KB article compares the Kea 1.4 HA feature with ISC DHCP’s DHCPv4 failover.
-> High Availability was planned to be a premium feature, but during the beta, we decided instead to release this in the open source, to help more ISC DHCP users migrate to Kea!
We have also added a new premium hook library:
Kea can now be integrated with a RADIUS server. 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), client can be assigned to 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.
Time to update!
We are actively developing Kea, so we continue to commit to supporting two versions at a time only: With the release of Kea 1.4, we plan to end maintenance of Kea 1.2 (at the end of June 2018). We also have slightly changed the instructions for installing hook libraries, which unfortunately means that your older Kea hook libraries will need to be updated to install with Kea 1.4. Anyone who purchased the Kea 1.3 Premium Hook package will be getting an email with instructions on how to get a free upgrade to the Kea 1.4 Premium package.
We have published, and plan to maintain going forward, a Kea Significant Features Matrix showing when we introduced each of the major Kea features.