Adding upstream version 2.5.7.upstream/2.5.7upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

5 files changed, 743 insertions, 0 deletions

diff --git a/doc/examples/template-ha-mt-tls/info.md b/doc/examples/template-ha-mt-tls/info.md
new file mode 100644
index 0000000..f551220
--- /dev/null
+++ b/doc/examples/template-ha-mt-tls/info.md
@@ -0,0 +1,87 @@
+Template: Secure High Availability Kea DHCP with Multi-Threading
+----------------------------------------------------------------
+
+Below are some templates to assist in configuring a secure Kea DHCP server with
+multi-threading. These templates make the following assumptions:
+
+- The administrator wants to set up High Availability (HA) with multi-threading.
+- The machines running Kea with multi-threading have at least four CPU cores.
+- The connection to the peer is secured using TLS.
+
+The logical setup consists of two hosts, each running a Kea DHCPv4 server and a Control Agent (CA).
+In the multi-threading setup, the CA is not required, as the server is using its
+own dedicated HTTP listener to communicate with the peer. However, the CA can still
+be used to handle user commands.
+
+.. code-block:: none
+
+   +-host-1-+       +-host-2-+
+   |        |       |        |
+   |   CA   |       |   CA   |    ===== - HTTPS connection
+   |   #    |       |   #    |
+   |   #    |       |   #    |    ##### - UNIX socket
+   |   #    |       |   #    |
+   | DHCPv4 ========= DHCPv4 |
+   |        |       |        |
+   +--------+       +--------+
+
+The CAs on host-1 and host-2 both listen on port 8001, and the server's dedicated HTTP
+listener uses port 8000. The DHCP servers communicate with each other via the dedicated HTTP
+listener, which forwards only the lease-update commands to the peer server.
+
+Deployment Considerations
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The setup is not expected to scale automatically. This example uses four threads for
+processing DHCP traffic, four threads for listening and handling HA peer HTTP requests,
+and four threads for sending lease updates to the HA peer. The thread queue used to
+store incoming DHCP requests is set to 64, but proper testing and benchmarks are required
+to determine the appropriate values for best performance on the deployment setup.
+
+In this example, there are two hosts running Kea:
+
+- 192.168.1.2 - primary HA server (active, handles all the traffic)
+
+- 192.168.1.3 - secondary HA server (passive, ready to take over if the primary fails)
+
+The network is 192.168.1.0/24. It is assumed that 192.168.1.1 is the default router.
+
+The whole subnet is split into dynamic pools:
+
+- 192.168.1.100 - 192.168.1.199 - this is the dynamic pool. When new devices appear in the network,
+  they are assigned dynamic addresses from this pool.
+
+To deploy this setup, follow the steps provided in the power user home setup with the following distinctions:
+
+1. Install the CA only if the administrator is planning to manage Kea using the RESTful API.
+   Otherwise, the CA is not required for the High Availability Kea server with multi-threading.
+
+2. Alter the following to match the local setup:
+
+   - The paths to ``trust-anchor``, ``cert-file``, and ``key-file`` must be set to the
+     respective values corresponding to the deployment machine.
+
+   - The addressing must be updated, if using something other than 192.168.1.0/24. Make sure the CA port
+     configuration (``http-host`` and ``http-port`` in ``kea-ca.conf``) is different from the DHCPv4 server
+     configuration (``url`` in ``hook-libraries/parameters/high-availability/peers`` in ``kea-dhcp4.conf``).
+     The CA is used to handle only management commands, as the HA module sends lease updates using
+     the dedicated HTTP listener to the peer.
+
+3. Verify the communication between the HA peers by checking the Kea logs.
+
+4. Verify that communication between the hosts works in the opposite direction as well
+   (host-2 can connect to host-1), by repeating step 3 from host-2 using host-1's IP address and port.
+
+5. Install the CA and DHCPv4 on host-2, as in steps 1 and 2. The config file for the
+   standby server is very similar to the one on the primary server, other than the definition of
+   the ``this-server-name`` field (and possibly the interface names).
+
+Possible Extensions
+~~~~~~~~~~~~~~~~~~~
+
+This sample configuration is basic but functional. Once it is set up and running, administrators
+may wish to consider the following changes:
+
+- If using a database, it is also possible to configure TLS for the database backend (for
+  lease, host, configuration backend, or forensic logging). See :ref:`database-connectivity`
+  for more information.
diff --git a/doc/examples/template-ha-mt-tls/kea-ca-1.conf b/doc/examples/template-ha-mt-tls/kea-ca-1.conf
new file mode 100644
index 0000000..765dd9c
--- /dev/null
+++ b/doc/examples/template-ha-mt-tls/kea-ca-1.conf
@@ -0,0 +1,90 @@
+// This is an example of a configuration for Control-Agent (CA) listening
+// for incoming HTTPS traffic. This is necessary for handling API commands.
+// For a High Availability setup with multi-threading enabled the CA is not
+// needed as the peers communicate using a dedicated HTTP listener.
+
+// It is expected to run with a standby (the passive) server, which has a very similar
+// configuration. The only difference is that the location of TLS specific files
+// depend on the configuration of the particular machine.
+{
+    "Control-agent":
+    {
+        // We need to specify where the agent should listen to incoming HTTP
+        // queries.
+        "http-host": "192.168.1.2",
+
+        // TLS trust anchor (Certificate Authority). This is a file name or
+        // (for OpenSSL only) a directory path.
+        "trust-anchor": "/usr/lib/kea/CA.pem",
+
+        // TLS server certificate file name.
+        "cert-file": "/usr/lib/kea/ca1_cert.pem",
+
+        // TLS server private key file name.
+        "key-file": "/usr/lib/kea/ca1_key.pem",
+
+        // TLS require client certificates flag.
+        "cert-required": true,
+
+        // This specifies the port CA will listen on.
+        // If enabling HA and multi-threading, the 8000 port is used by the HA
+        // hook library http listener. When using HA hook library with
+        // multi-threading to function, make sure the port used by dedicated
+        // listener is different (e.g. 8001) than the one used by CA. Note
+        // the commands should still be sent via CA. The dedicated listener
+        // is specifically for HA updates only.
+        "http-port": 8001,
+
+        "control-sockets":
+        {
+            // This is how the Agent can communicate with the DHCPv4 server.
+            "dhcp4":
+            {
+                "comment": "socket to DHCPv4 server",
+                "socket-type": "unix",
+                "socket-name": "/tmp/kea4-ctrl-socket"
+            },
+
+            // Location of the DHCPv6 command channel socket.
+            "dhcp6":
+            {
+                "socket-type": "unix",
+                "socket-name": "/tmp/kea6-ctrl-socket"
+            },
+
+            // Location of the D2 command channel socket.
+            "d2":
+            {
+                "socket-type": "unix",
+                "socket-name": "/tmp/kea-ddns-ctrl-socket",
+                "user-context": { "in-use": false }
+            }
+        },
+
+        // Similar to other Kea components, CA also uses logging.
+        "loggers": [
+            {
+                "name": "kea-ctrl-agent",
+                "output-options": [
+                    {
+                        "output": "/var/log/kea-ctrl-agent.log",
+
+                        // Several additional parameters are possible in addition
+                        // to the typical output. Flush determines whether logger
+                        // flushes output to a file. Maxsize determines maximum
+                        // filesize before the file is rotated. maxver
+                        // specifies the maximum number of rotated files being
+                        // kept.
+                        "flush": true,
+                        "maxsize": 204800,
+                        "maxver": 4,
+                        // We use pattern to specify custom log message layout
+                        "pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
+                    }
+                ],
+                "severity": "INFO",
+                "debuglevel": 0 // debug level only applies when severity is set to DEBUG.
+            }
+        ]
+    }
+}
diff --git a/doc/examples/template-ha-mt-tls/kea-ca-2.conf b/doc/examples/template-ha-mt-tls/kea-ca-2.conf
new file mode 100644
index 0000000..72eb73b
--- /dev/null
+++ b/doc/examples/template-ha-mt-tls/kea-ca-2.conf
@@ -0,0 +1,90 @@
+// This is an example of a configuration for Control-Agent (CA) listening
+// for incoming HTTPS traffic. This is necessary for handling API commands.
+// For a High Availability setup with multi-threading enabled the CA is not
+// needed as the peers communicate using a dedicated HTTP listener.
+
+// It is expected to run with a primary (the active) server, which has a very similar
+// configuration. The only difference is that the location of TLS specific files
+// depend on the configuration of the particular machine.
+{
+    "Control-agent":
+    {
+        // We need to specify where the agent should listen to incoming HTTP
+        // queries.
+        "http-host": "192.168.1.3",
+
+        // TLS trust anchor (Certificate Authority). This is a file name or
+        // (for OpenSSL only) a directory path.
+        "trust-anchor": "/usr/lib/kea/CA.pem",
+
+        // TLS server certificate file name.
+        "cert-file": "/usr/lib/kea/ca2_cert.pem",
+
+        // TLS server private key file name.
+        "key-file": "/usr/lib/kea/ca2_key.pem",
+
+        // TLS require client certificates flag.
+        "cert-required": true,
+
+        // This specifies the port CA will listen on.
+        // If enabling HA and multi-threading, the 8000 port is used by the HA
+        // hook library http listener. When using HA hook library with
+        // multi-threading to function, make sure the port used by dedicated
+        // listener is different (e.g. 8001) than the one used by CA. Note
+        // the commands should still be sent via CA. The dedicated listener
+        // is specifically for HA updates only.
+        "http-port": 8001,
+
+        "control-sockets":
+        {
+            // This is how the Agent can communicate with the DHCPv4 server.
+            "dhcp4":
+            {
+                "comment": "socket to DHCPv4 server",
+                "socket-type": "unix",
+                "socket-name": "/tmp/kea4-ctrl-socket"
+            },
+
+            // Location of the DHCPv6 command channel socket.
+            "dhcp6":
+            {
+                "socket-type": "unix",
+                "socket-name": "/tmp/kea6-ctrl-socket"
+            },
+
+            // Location of the D2 command channel socket.
+            "d2":
+            {
+                "socket-type": "unix",
+                "socket-name": "/tmp/kea-ddns-ctrl-socket",
+                "user-context": { "in-use": false }
+            }
+        },
+
+        // Similar to other Kea components, CA also uses logging.
+        "loggers": [
+            {
+                "name": "kea-ctrl-agent",
+                "output-options": [
+                    {
+                        "output": "/var/log/kea-ctrl-agent.log",
+
+                        // Several additional parameters are possible in addition
+                        // to the typical output. Flush determines whether logger
+                        // flushes output to a file. Maxsize determines maximum
+                        // filesize before the file is rotated. maxver
+                        // specifies the maximum number of rotated files being
+                        // kept.
+                        "flush": true,
+                        "maxsize": 204800,
+                        "maxver": 4,
+                        // We use pattern to specify custom log message layout
+                        "pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
+                    }
+                ],
+                "severity": "INFO",
+                "debuglevel": 0 // debug level only applies when severity is set to DEBUG.
+            }
+        ]
+    }
+}
diff --git a/doc/examples/template-ha-mt-tls/kea-dhcp4-1.conf b/doc/examples/template-ha-mt-tls/kea-dhcp4-1.conf
new file mode 100644
index 0000000..0dc1198
--- /dev/null
+++ b/doc/examples/template-ha-mt-tls/kea-dhcp4-1.conf
@@ -0,0 +1,238 @@
+// This is an example configuration of the Kea DHCPv4 server 1:
+//
+// - 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 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 standby (the passive) 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": "server1",
+                    // 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 this server instance.
+                        {
+                            "name": "server1",
+                            // 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.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,
+                            // This server is primary. The other one must be
+                            // secondary.
+                            "role": "primary"
+                        },
+                        // This is the configuration of the secondary server.
+                        {
+                            "name": "server2",
+                            // 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.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,
+                            // The other server is secondary. This 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
+    }
+  ]
+}
+}
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
+    }
+  ]
+}
+}