Using the Kea Configuration Backend
  • 27 Aug 2020
  • 5 Minutes to read
  • Contributors
  • Dark
  • PDF

Using the Kea Configuration Backend

  • Dark
  • PDF

Article summary

On August 14, 2019, Alan Clegg presented a webinar on the new Configuration Backend feature in Kea DHCP. This article recaps the highlights of the webinar for those who may be interested. You can also watch a recording of the webinar here.

What is the configuration backend?

The configuration backend (also known as config backend or CB) is a new feature as of Kea 1.6. It offers scalable DHCP configuration management using MySQL as a database backend.

Config backend takes advantage of three major features of Kea:

  1. Its ability to use a configuration database backend;
  2. Its implementation as a series of hooks; and
  3. Its management through the REST API.

Why do I need it?

DHCPv4 and DHCPv6 servers need to store leases (addresses and prefixes), host reservations (per-host details), and configuration information (options, pools, subnets, shared networks, option definitions, and global parameters). All of those parameters need to be managed, but different servers often have very similar configurations. Duplicating those configurations among multiple servers can be time-consuming.

Lease and host database management backends were already available, but the config backend is new with Kea 1.6. The config backend allows administrators to easily manage and deploy configuration information across multiple Kea servers by storing the configurations in a MySQL database rather than locally on each server, reducing complexity and saving administration time.

Some config backend features

  • The MySQL server can be colocated with the DHCP server or remote.
  • Multiple Kea servers can share a single remote MySQL database.
  • The database can be modified when the DHCP servers are offline, and the servers will read the updated information the next time they come back online.
  • Changes can be made to the configuration database without needing to restart the servers; the servers update automatically using a pull model, with a configurable delay.
  • Offline configuration allows firewalling of configuration management for increased security.

What are the benefits of CB?

  1. Configurations can be shared between HA partners; there's no need to worry about missing anything while making changes among different servers.
  2. Rapidly changing configurations are easily maintained.
  3. The config backend is a huge step forward in automated configuration management; it offers basic error checking and verification of IP address structure.
  4. Large deployments are easily managed and updates are propagated nearly simultaneously across your entire network.
  5. CB lets you scale up and down easily with the "server tags" feature.
  6. The configuration backend gives you the ability to monitor the database, run reports, deploy backups, and maintain redundancy.

Are there any limitations to the configuration backend?

This is a new feature and we expect to add more to it in the future. In the meantime:

  • The config backend is currently MySQL-only; the ability to use a PostgreSQL database is being considered for a future release.
  • CB is only available on DHCPv4 and DHCPv6 servers; it does not currently work for DDNS or Control Agent, or other Kea hooks (like RADIUS, NETCONF, etc.).
  • Some parameters (like server-tag) must be configured manually via the JSON file.

How do I use CB?

With configuration backend, you can set a very minimal local configuration for new servers, and then have the servers pull all the rest of the information from the database backend. The basic info that needs to be configured is:

  • server-tag – the name of the server with respect to the configuration backend
  • interfaces-config – the information on how to communicate with the network
  • control-socket – the ability for the DHCP server to talk to its Kea configuration
  • config-control – a new feature: the database in which the config backend is stored
  • hooks-libraries – the hooks enable the configuration backend
  • lease-database – the name of the database where the lease data is to be stored
  • expired-leases-processing – the information on when to process expired leases

Many other server parameters can be retrieved via the configuration backend: global parameters, option definitions, subnets and shared networks, pools, and options. Every time the local server reaches the end of its specified refresh interval, it reaches out to the config backend to pull in any changes and update its configuration.

What is the Kea Control Agent?

The Kea Control Agent (kea-ctrl-agent), available to ISC support subscription customers, is a mechanism to communicate with the Kea servers. It listens on a configurable TCP port (web-based or JSON-based management) directly via HTTP or through a reverse proxy (nginx) via HTTPS, or on a UNIX socket per service. With the TCP port, you need to specify the individual server (DHCPv4, DHCPv6, D2, or Control Agent), whereas the UNIX socket is multiplexed so it connects directly to the appropriate service (DHCPv4, DHCPv6, D2). The Kea Control Agent consumes and emits JSON, which is convenient for users. Kea Control Agent needs to be activated before you can use the config backend management through the web or JSON service.

The subscription-only portion of kea-ctrl-agent is the ability to modify the configuration backend over JSON through the Kea Control Agent.
The configuration backend itself is a freely available Kea 1.6 hook via open source; only the kea-ctrl-agent management tool requires a paid support subscription.


How do I administer Kea servers with CB?

The kea-shell software is included with the open source Kea distribution; it builds the tool that talks to the kea-ctrl-agent over HTTP. It is not required; socat or curl can be used as well.


To make the JSON output easier to read, we recommend running it through jquery in postprocessing.


How do I specify which servers get which configurations?

Server tags allow the creation of groups, which can be used to specify which configuration options are applied to the Kea servers. Each server has exactly one tag; each object in the database can have one or more server tags associated with it. There is also a global all tag that is associated with all servers. Server tags allow you to set certain configuration parameters for specific server locations and other parameters for all servers.


How do I migrate from my previous, non-database configuration to the config backend setup in Kea?

You need to look through your existing configs and look for common elements that can be pulled out and grouped. Stay tuned for a future webinar on this topic!

For a complete description of the configuration backend, please see the Kea Administrator Reference Manual (ARM). You can see the complete list of commands available with the cb_cmds hooks library here.

We invite all users to provide feedback on the configuration backend feature. You can view the config-backend issues list in GitLab and open an issue there, if desired.