... | ... | @@ -4,21 +4,27 @@ Welcome to Kea 1.9.1, the second monthly release of the new 1.9 development bran |
|
|
|
|
|
The most significant changes introduced in this version are:
|
|
|
|
|
|
1. **Multiple MAC reservations for the same IP**. Under normal circumstances having more than one reservation for the same IP may cause conflicts and thus Kea considers it a configuration error and doesn't allow it. However, in some deployments it is useful to have two reservations if some external constraints are present. For example, imagine a situation when a device has two interfaces, but at any given time only one of them will be connected. To enable this mode of operation, a new parameter ``ip-reservations-unique`` has been added. The default behavior remains unchanged. Multiple reservations are forbidden, unless explicitly allowed. Care should be taken to never allow a situation where two or more devices are active with reservations for the same IP. Kea has no way to meaningfully resolve such a conflict. When in doubt, don't use this feature! #1428.
|
|
|
1. **Multiple MAC reservations for the same IP**. Having more than one reservation for the same IP may cause conflicts, thus Kea considers it a configuration error and doesn't allow it. However, if the client has two interfaces, but at any given time only one of them will be connected, it is useful to have two reservations. To enable this mode of operation, a new parameter ``ip-reservations-unique`` has been added. The default behavior remains unchanged. Multiple reservations are forbidden, unless explicitly allowed. Care should be taken to never allow a situation where two or more devices are active with reservations for the same IP. Kea has no way to meaningfully resolve such a conflict. When in doubt, don't use this feature! #1428.
|
|
|
|
|
|
2. **DDNS improvements**. It is now possible to configure Kea to perform DNS Updates while client is renewing. Typically this is redundant as the DNS update done during initial client configuration is sufficient. However, if there were problems with the DNS (e.g. misconfigured TSIG keys or perhaps the server was down), it may be useful to turn on the new ``ddns-update-on-renew`` parameter. This will force updating all DNS records for active clients. After some time (roughly equal to your ``renewal-timer``), this will ensure that all records for current clients are properly updated #1385. By default, Kea generates DHCID DNS records to keep a record in the DNS regarding who is the current owner of an address. When attempting to do updates, Kea and other software that implements Conflict Resolution protocol as defined in RFC4703, check for presence and content of the DHCID records. Kea can now be optionally told to ignore the records, using a new ``ddns-use-conflict-resolution`` parameter. The DHCID records still will be created, but their presence will not prevent Kea from overwriting older records. Implemented this way, Kea will not have a history gap if conflict resolution is disabled and later enabled. #1386.
|
|
|
2. **DDNS improvements**. It is now possible to configure Kea to perform DNS Updates when the client renews a lease. Typically this is redundant, as the DNS update done during initial client configuration is sufficient. However, if there were problems with the DNS (e.g. misconfigured TSIG keys or perhaps the server was down), it may be useful to turn on the new ``ddns-update-on-renew`` parameter. This will force updating all DNS records for active clients. After some time (roughly equal to the value of the ``renewal-timer``), this will ensure that all records for current clients are properly updated #1385. By default, Kea generates DHCID DNS records to keep a record in the DNS of the current owner of an address. When attempting to do updates, Kea (per the Conflict Resolution protocol as defined in RFC4703), checks for presence and content of the DHCID records. Kea can now be optionally told to ignore the records, using a new ``ddns-use-conflict-resolution`` parameter. The DHCID records still will be created, but their presence will not prevent Kea from overwriting older records. Implemented this way, Kea will not have a history gap if conflict resolution is disabled and later enabled. #1386.
|
|
|
|
|
|
3. **Fix for HA hook with MySQL**. With the introduction of multi-threading support, the MySQL lease update mechanism has been updated slightly to protect against two or more threads updating the same lease. Sadly, under some circumstances this may caused HA hook to reject lease updates being sent by its partner. This problem has now been fixed #1434.
|
|
|
3. **Fix for HA hook with MySQL**. With the introduction of multi-threading support, the MySQL lease update mechanism has been updated slightly to protect against two or more threads updating the same lease. Sadly, under some circumstances this caused the HA hook to reject lease updates sent by its partner. This problem has now been fixed #1434.
|
|
|
|
|
|
4. **Authorization improvements**. The Control Agent now logs every authentication attempt, in particular it shows which user authorized the command to be executed. That information technically was previously available, but it required a very verbose ``DEBUG`` logging level. Right now, the information is logged on ``INFO`` level #1450. Logging entries have been updated to redact HTTP basic authentication passwords #1459.
|
|
|
4. **Authorization improvements**. The Control Agent logs every authentication attempt, showing which user authorized the command to be executed. That information was previously available at the verbose ``DEBUG`` logging level. Now the information is logged at the ``INFO`` level #1450. Logging entries have been updated to redact HTTP basic authentication passwords #1459.
|
|
|
|
|
|
5. **Performance Statistics**. A new statistic has been added that reports packet queue utilization. It reports an average for the last 10, 100 and 1000 packets. This uses the approach similar to Unix tool ``top``, which returns CPU utilization for the last 1, 5 and 15 minutes. This may be useful for fine tuning Kea performance and its queue length #1306.
|
|
|
5. **Performance Statistics**. A new statistic has been added that reports packet queue utilization. It reports an average for the last 10, 100 and 1000 packets. This uses an approach similar to the Unix ``top`` tool, which returns CPU utilization for the last 1, 5 and 15 minutes. This may be useful for fine tuning Kea performance and its queue length #1306.
|
|
|
|
|
|
6. **Better error messages for broken JSON**. JSON parser has been improved to provide a more meaningful error messages when receiving malformed JSON. This may be useful to figuring out missing quotes, incorrectly escaped characters and similar #151.
|
|
|
6. **Better error messages for broken JSON**. The JSON parser has been improved to provide a more meaningful error messages when receiving malformed JSON. This may be useful for finding syntax issues such as missing quote marks and incorrectly escaped characters. #151.
|
|
|
|
|
|
7. **Doc updates**. A lot of effort has been put into improving the documentation. First, there are new ``all-options.json`` example configurations for DHCPv4 and DHCPv6 that demonstrate how to configure all options currently defined, including defining custom and vendor options. They're available in ``doc/examples/kea4`` and ``doc/examples/kea6`` directories #1298. Database communication can sometime fail for various reasons and Kea has a mechanism to reconnect. However, the parameters for controlling this were a bit hidden. Several config examples have been updated with the ``max-reconnect-tries`` and ``reconnect-wait-time`` parameters now being more prominent #827. DHCPv6 documentation has been extended to clearly list the options that are set by Kea itself that are not supposed to be configured by hand by the administrator. Nevertheless, such a list is useful to answer the question whether a given option is supported by Kea or not #1436. Two options (link selection sub-option and subnet selection option) were supported by Kea for a long time, but their support was not clearly documented. This has been corrected #1460. An introductory text about host reservations and how to use them has been added in the ARM and a separate KB article is coming up #1299. Several ``pd-exclude`` examples have been corrected #1454. A section about configuring RADIUS to use non-standard formatting for MAC address has been added. The particular example uses Cisco's preferred format of MAC addresses as ``0123.4567.89ab``, but other syntax can be used as well #1441.
|
|
|
7. **Doc updates**. We have made numerous improvements in the Kea documentation. There are new ``all-options.json`` example configurations for DHCPv4 and DHCPv6 that demonstrate how to configure all options currently defined in Kea, including defining custom and vendor options. They're available in the ``doc/examples/kea4`` and ``doc/examples/kea6`` directories #1298.
|
|
|
Database communication can sometime fail for various reasons and Kea has a mechanism to reconnect. However, the parameters for controlling this were hard to find. Several configuration examples have been updated illustrating the use of the ``max-reconnect-tries`` and ``reconnect-wait-time`` parameters #827.
|
|
|
DHCPv6 documentation has been extended to clearly list the options that are set by Kea itself that are not supposed to be configured by hand by the administrator. Nevertheless, such a list is useful to answer the question whether a given option is supported by Kea or not #1436.
|
|
|
Two options (link selection sub-option and subnet selection option) were supported by Kea for a long time, but their support was not clearly documented. This has been corrected #1460.
|
|
|
Introductory text about host reservations and how to use them has been added in the ARM #1299.
|
|
|
Several ``pd-exclude`` examples have been corrected #1454.
|
|
|
A section about configuring RADIUS to use non-standard formatting for MAC address has been added. The particular example uses Cisco's preferred format of MAC addresses as ``0123.4567.89ab``, but other syntax can be used as well #1441.
|
|
|
|
|
|
8. **Build improvements**. Our internal build farm has been extended with Apline 3.12. As such, ``hammer``, our build tool, has been extended to support this OS #1429.
|
|
|
8. **Build improvements**. Our internal build farm has been extended with Alpine 3.12. Our build tool ``hammer`` has been extended to support this OS #1429.
|
|
|
|
|
|
## Known Issues
|
|
|
|
... | ... | |