summaryrefslogtreecommitdiffstats
path: root/doc/examples/template-ha-mt-tls/kea-dhcp4-2.conf
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-21 14:53:22 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-21 14:53:22 +0000
commit52c021ee0b0c6ad2128ed550c694aad0d11d4c3f (patch)
tree83cf8627b94336cf4bee7479b9749263bbfd3a06 /doc/examples/template-ha-mt-tls/kea-dhcp4-2.conf
parentInitial commit. (diff)
downloadisc-kea-52c021ee0b0c6ad2128ed550c694aad0d11d4c3f.tar.xz
isc-kea-52c021ee0b0c6ad2128ed550c694aad0d11d4c3f.zip
Adding upstream version 2.5.7.upstream/2.5.7upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/examples/template-ha-mt-tls/kea-dhcp4-2.conf')
-rw-r--r--doc/examples/template-ha-mt-tls/kea-dhcp4-2.conf238
1 files changed, 238 insertions, 0 deletions
diff --git a/doc/examples/template-ha-mt-tls/kea-dhcp4-2.conf b/doc/examples/template-ha-mt-tls/kea-dhcp4-2.conf
new file mode 100644
index 0000000..070569b
--- /dev/null
+++ b/doc/examples/template-ha-mt-tls/kea-dhcp4-2.conf
@@ -0,0 +1,238 @@
+// This is an example configuration of the Kea DHCPv4 server 2:
+//
+// - uses High Availability hook library and Lease Commands hook library
+// to enable High Availability function for the DHCP server. This config
+// file is for the secondary (the standby) 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 and location of TLS specific files
+// depend on the network settings and configuration 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"
+ },
+
+ // Multi-threading parameters.
+ "multi-threading": {
+ // By default, Kea processes packets on multiple threads if the hardware permits.
+ "enable-multi-threading": true,
+
+ // When multi-threading is enabled, Kea will process packets on a
+ // number of multiple threads configurable through this option. The
+ // value must be a positive integer (0 means auto-detect).
+ "thread-pool-size": 4,
+
+ // When multi-threading is enabled, Kea will read packets from the
+ // interface and append a working item to the thread pool. This
+ // option configures the maximum number of items that can be queued.
+ // The value must be a positive integer (0 means unlimited).
+ "packet-queue-size": 64
+ },
+
+ // 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.
+ // If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are
+ // not 0, when the client sends a release message the lease is expired
+ // instead of being deleted from lease storage.
+ "expired-leases-processing": {
+ "reclaim-timer-wait-time": 3600,
+ "hold-reclaimed-time": 172800,
+ "max-reclaim-leases": 0,
+ "max-reclaim-time": 0
+ },
+
+ // HA requires two hook 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 hook 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,
+ // Multi-threading parameters.
+ // To not experience performance degradation when the Kea server is
+ // processing packets on multiple threads, the High Availability module
+ // must have multi-threading enabled.
+ "multi-threading": {
+ // Enable High Availability to benefit from multi-threading. Default: true.
+ "enable-multi-threading": true,
+ // When running in MT mode, the dedicated listener is used to handle
+ // lease updates.
+ "http-dedicated-listener": true,
+ // The number of threads used to handle incoming requests.
+ // A value of 0 instructs the server to use the same number of
+ // threads that the Kea core is using for DHCP multi-threading.
+ "http-listener-threads": 0,
+ // The number of threads used to handle outgoing requests.
+ // A value of 0 instructs the server to use the same number of
+ // threads that the Kea core is using for DHCP multi-threading.
+ "http-client-threads": 0
+ },
+ "peers": [
+ // This is the configuration of the primary server.
+ {
+ "name": "server1",
+ // This specifies the URL of the other server's dedicated HTTP listener.
+ // The Control Agent is not needed for the High Availability
+ // with multi-threading, but if it is used, it must use
+ // different values for "http-host" and "http-port".
+ "url": "http://192.168.1.2:8000/",
+ // Trust anchor aka certificate authority file or directory.
+ "trust-anchor": "/usr/lib/kea/CA.pem",
+ // Client certificate file name.
+ "cert-file": "/usr/lib/kea/server1_cert.pem",
+ // Private key file name.
+ "key-file": "/usr/lib/kea/server1_key.pem",
+ // Client certificates are required and verified.
+ "require-client-certs": true,
+ // 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 dedicated HTTP listener.
+ // The Control Agent is not needed for the High Availability
+ // with multi-threading, but if it is used, it must use
+ // different values for "http-host" and "http-port".
+ "url": "http://192.168.1.3:8000/",
+ // Trust anchor aka certificate authority file or directory.
+ "trust-anchor": "/usr/lib/kea/CA.pem",
+ // Client certificate file name.
+ "cert-file": "/usr/lib/kea/server2_cert.pem",
+ // Private key file name.
+ "key-file": "/usr/lib/kea/server2_key.pem",
+ // Client certificates are required and verified.
+ "require-client-certs": true,
+ // 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"
+ }
+ ]
+ }
+ ],
+
+ // 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
+ }
+ ]
+}
+}