Kea DHCP Documentation

Hammer is a Python 3 script used to automate Kea build tasks, including setting up virtual machines (LXC or VirtualBox), installing dependencies, compiling Kea with various options, and running unit tests.

Important Notes:

• Hammer is an internal tool and is not included in the official Kea distribution (though it is available in the Kea git repository).
• ISC does not guarantee its operation; use it at your own discretion.
• All Hammer functionality can be performed manually if preferred.

The kea-lfc process is a service designed to remove redundant information from files used for persistent storage in the Kea DHCP memfile database backend.

It is typically run periodically by Kea DHCP servers. Since Kea version 3.1.2, it can be started using the kea-lfc-start command. While it can be started externally, it is primarily intended to be managed by the DHCP server processes. The process uses a specific set of files for input, output, and bookkeeping to ensure data integrity even if the process is interrupted.

Kea provides a hook functionality to customize servers without modifying core code. ISC provides several hook libraries that can be loaded into Kea processes. As of Kea 3.0.0, most are open source, while some require paid ISC support contracts.

Important: When a library does not work as expected, verify that it has been loaded by the correct Kea process (e.g., kea-dhcp4, kea-dhcp6, or kea-dhcp-ddns) as specified in the library's documentation.

The DHCP-DDNS server supports the following standards:

• TSIG (RFC 2845): Secret Key Transaction Authentication for DNS. All DNS update packets can be protected by TSIG signatures.
• DNS UPDATE (RFC 2136): The complete DNS update mechanism is supported.
• FQDN Conflict Resolution (RFC 4703): Handles conflict resolution for both DHCPv4 and DHCPv6 servers.
• DHCID RR (RFC 4701): Uses DHCID records for encoding DHCP information.

The libdhcp_subnet_cmds.so library provides a lightweight way to query and manipulate subnet and shared network configurations in Kea without requiring a full server reconfiguration. This is particularly useful for deployments with large numbers of frequently updated subnets.

Key Constraints:

• This library can only be loaded by the kea-dhcp4 or kea-dhcp6 processes.
• It is part of the open source code and available to all Kea users.

Supported Capabilities:

• Subnet Management: List, get details, add, update, delete, and perform delta updates (add/remove parts of a subnet) for both IPv4 and IPv6.
• Shared Network Management: List, get details, add, and remove shared networks, as well as adding/removing subnets from shared networks.

The kea-admin shell script is used for managing Kea databases. It provides capabilities for database initialization, version checking, schema upgrades, and lease data management (dumping and uploading).

kea-admin [command] [backend] [options]

The kea-dhcp-ddns service is a standalone process responsible for requesting DNS mapping updates based on DHCP lease-change events. It operates by receiving Name Change Requests from Kea DHCP servers.

To run the service, you must provide a configuration file using the -c flag. This configuration file contains settings for the DHCP-DDNS server and may also include configuration entries for other Kea services.

kea-dhcp-ddns -c <config-file>

The Kea Configuration Backend (CB) allows Kea servers to store almost all of their configuration in one or more databases (MySQL or PostgreSQL) instead of local JSON files. This enables a "single source of truth" for multiple Kea servers, allowing for identical configuration sections to be reused across sites and providing real-time logic checks via an API.

Key Benefits:

• Centralized configuration management.
• Real-time propagation of updates to all Kea instances.
• Integration with third-party automation and provisioning tools.
• Database-driven concurrency, consistency, and atomicity.

Important Note: Using a database for leases or host reservations is a separate feature and does not require the Configuration Backend. For those, use the host-databases and lease-database configuration directives.

Congestion occurs when client queries arrive faster than the server can process them, leading to a backlog. Kea mitigates this by using a separate thread to read packets from interface socket buffers into an internal packet queue. The main application thread then processes packets from this queue instead of directly from the socket buffers.

This architecture allows the server to make decisions on which packets to process, how to store them, and their processing order. The default implementation is a ring buffer that discards the oldest packets when it reaches capacity.

Note: Congestion handling is incompatible with multi-threading. If both are enabled, congestion handling is silently disabled.