// This is an example configuration of the Kea DHCPv4 server 2: // // - uses High Availability hooks library and Lease Commands hooks library // to enable High Availability function for the DHCP server. This config // file is for the primary (the active) server. // - uses memfile, which stores lease data in a local CSV file // - it assumes a single /24 addressing over a link that is directly reachable // (no DHCP relays) // - there is a handful of IP reservations // // It is expected to run with a primary (the active) server, which has a very similar // configuration. The only difference is that "this-server-name" must be set to "server2" on the // other server. Also, the interface configuration depends on the network settings of the // particular machine. { "Dhcp4": { // Add names of your network interfaces to listen on. "interfaces-config": { // The DHCPv4 server listens on this interface. When changing this to // the actual name of your interface, make sure to also update the // interface parameter in the subnet definition below. "interfaces": [ "enp0s8" ] }, // Control socket is required for communication between the Control // Agent and the DHCP server. High Availability requires Control Agent // to be running because lease updates are sent over the RESTful // API between the HA peers. "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea4-ctrl-socket" }, // Use Memfile lease database backend to store leases in a CSV file. // Depending on how Kea was compiled, it may also support SQL databases // (MySQL and/or PostgreSQL). Those database backends require more // parameters, like name, host and possibly user and password. // There are dedicated examples for each backend. See Section 7.2.2 "Lease // Storage" for details. "lease-database": { // Memfile is the simplest and easiest backend to use. It's an in-memory // database with data being written to a CSV file. It is very similar to // what ISC DHCP does. "type": "memfile" }, // Let's configure some global parameters. The home network is not very dynamic // and there's no shortage of addresses, so no need to recycle aggressively. "valid-lifetime": 43200, // leases will be valid for 12h "renew-timer": 21600, // clients should renew every 6h "rebind-timer": 32400, // clients should start looking for other servers after 9h // Kea will clean up its database of expired leases once per hour. However, it // will keep the leases in expired state for 2 days. This greatly increases the // chances for returning devices to get the same address again. To guarantee that, // use host reservation. "expired-leases-processing": { "reclaim-timer-wait-time": 3600, "hold-reclaimed-time": 172800, "max-reclaim-leases": 0, "max-reclaim-time": 0 }, // HA requires two hooks libraries to be loaded: libdhcp_lease_cmds.so and // libdhcp_ha.so. The former handles incoming lease updates from the HA peers. // The latter implements high availability feature for Kea. Note the library name // should be the same, but the path is OS specific. "hooks-libraries": [ // The lease_cmds library must be loaded because HA makes use of it to // deliver lease updates to the server as well as synchronize the // lease database after failure. { "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so" }, { // The HA hooks library should be loaded. "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so", "parameters": { // Each server should have the same HA configuration, except for the // "this-server-name" parameter. "high-availability": [ { // This parameter points to this server instance. The respective // HA peers must have this parameter set to their own names. "this-server-name": "server2", // The HA mode is set to hot-standby. In this mode, the active server handles // all the traffic. The standby takes over if the primary becomes unavailable. "mode": "hot-standby", // Heartbeat is to be sent every 10 seconds if no other control // commands are transmitted. "heartbeat-delay": 10000, // Maximum time for partner's response to a heartbeat, after which // failure detection is started. This is specified in milliseconds. // If we don't hear from the partner in 60 seconds, it's time to // start worrying. "max-response-delay": 60000, // The following parameters control how the server detects the // partner's failure. The ACK delay sets the threshold for the // 'secs' field of the received discovers. This is specified in // milliseconds. "max-ack-delay": 5000, // This specifies the number of clients which send messages to // the partner but appear to not receive any response. "max-unacked-clients": 5, // This specifies the maximum timeout (in milliseconds) for the server // to complete sync. If you have a large deployment (high tens or // hundreds of thousands of clients), you may need to increase it // further. The default value is 60000ms (60 seconds). "sync-timeout": 60000, "peers": [ // This is the configuration of the primary server. { "name": "server1", // Specifies the URL on which the partner's control // channel can be reached. The Control Agent is required // to run on the partner's machine with "http-host" and // "http-port" values set to the corresponding values. "url": "http://192.168.1.2:8000/", // The other server is primary. This one must be // secondary. "role": "primary" }, // This is the configuration of this server instance. { "name": "server2", // This specifies the URL of this server instance. The // Control Agent must run along with this DHCPv4 server // instance and the "http-host" and "http-port" must be // set to the corresponding values. "url": "http://192.168.1.3:8000/", // This server is secondary. The other one must be // primary. "role": "standby" } ] } ] } } ], // This example contains a single subnet declaration. "subnet4": [ { // Subnet prefix. "subnet": "192.168.1.0/24", // There are no relays in this network, so we need to tell Kea that this subnet // is reachable directly via the specified interface. "interface": "enp0s8", // Specify a dynamic address pool. "pools": [ { "pool": "192.168.1.100-192.168.1.199" } ], // These are options that are subnet specific. In most cases, you need to define at // least routers option, as without this option your clients will not be able to reach // their default gateway and will not have Internet connectivity. If you have many // subnets and they share the same options (e.g. DNS servers typically is the same // everywhere), you may define options at the global scope, so you don't repeat them // for every network. "option-data": [ { // For each IPv4 subnet you typically need to specify at least one router. "name": "routers", "data": "192.168.1.1" }, { // Using cloudflare or Quad9 is a reasonable option. Change this // to your own DNS servers is you have them. Another popular // choice is 8.8.8.8, owned by Google. Using third party DNS // service raises some privacy concerns. "name": "domain-name-servers", "data": "1.1.1.1,9.9.9.9" } ], // Some devices should get a static address. Since the .100 - .199 range is dynamic, // let's use the lower address space for this. There are many ways how reservation // can be defined, but using MAC address (hw-address) is by far the most popular one. // You can use client-id, duid and even custom defined flex-id that may use whatever // parts of the packet you want to use as identifiers. Also, there are many more things // you can specify in addition to just an IP address: extra options, next-server, hostname, // assign device to client classes etc. See the Kea ARM, Section 8.3 for details. // The reservations are subnet specific. "reservations": [ { "hw-address": "1a:1b:1c:1d:1e:1f", "ip-address": "192.168.1.10" }, { "client-id": "01:11:22:33:44:55:66", "ip-address": "192.168.1.11" } ] } ], // Logging configuration starts here. "loggers": [ { // This section affects kea-dhcp4, which is the base logger for DHCPv4 component. It tells // DHCPv4 server to write all log messages (on severity INFO or higher) to a file. The file // will be rotated once it grows to 2MB and up to 4 files will be kept. The debuglevel // (range 0 to 99) is used only when logging on DEBUG level. "name": "kea-dhcp4", "output_options": [ { "output": "/var/log/kea-dhcp4.log", "maxsize": 2048000, "maxver": 4 } ], "severity": "INFO", "debuglevel": 0 } ] } }