diff options
Diffstat (limited to '')
| -rw-r--r-- | doc/examples/template-power-user-home/info.md | 124 | ||||
| -rw-r--r-- | doc/examples/template-power-user-home/kea-ca-1.conf | 66 | ||||
| -rw-r--r-- | doc/examples/template-power-user-home/kea-ca-2.conf | 66 | ||||
| -rw-r--r-- | doc/examples/template-power-user-home/kea-dhcp4-1.conf | 227 | ||||
| -rw-r--r-- | doc/examples/template-power-user-home/kea-dhcp4-2.conf | 227 |
5 files changed, 710 insertions, 0 deletions
diff --git a/doc/examples/template-power-user-home/info.md b/doc/examples/template-power-user-home/info.md new file mode 100644 index 0000000..9335ff8 --- /dev/null +++ b/doc/examples/template-power-user-home/info.md @@ -0,0 +1,124 @@ +Template: Home Network of a Power User +-------------------------------------- + +Below are some templates to assist in configuring the home network of a power user; they may also be +appropriate for a small office. These templates make the following assumptions: + +- The administrator wants to use a single /24 class of IPv4 addresses. +- High Availability (HA) is desired, so there are two DHCP servers. +- There are a handful of devices, and some of them (e.g. a printer or NAS) require + static addresses or extra options. +- The administrator does not want to be bothered with database management. +- The setup is optimized for minimal to zero maintenance. +- Performance is not an issue; hundreds of queries per second are not expected. +- IPv6 is not used. +- DNS updates will not be performed by Kea. + +The logical setup consists of two hosts, each running a Kea DHCPv4 server and a Control Agent (CA). +The server connects with the CA using UNIX sockets. Each DHCPv4+CA acts as one partner of the HA +pair. + +.. code-block:: none + + +-host-1-+ +-host-2-+ + | | | | + | CA <===\ /===> CA | ===== - HTTP connection + | # | \ / | # | + | # | X | # | ##### - UNIX socket + | # | / \ # | + | DHCPv4 ==/ \== DHCPv4 | + | | | | + +--------+ +--------+ + +The CAs on host-1 and host-2 both listen on port 8000. The DHCP servers communicate +with each other via the CAs, which forward control commands to the DHCP servers over the UNIX domain +sockets. + +Deployment Considerations +~~~~~~~~~~~~~~~~~~~~~~~~~ + +This setup is not expected to be very performant. Most modest hardware will do; Kea has been successfully +deployed on Raspberry Pi platforms, for example. If it is running on a VM, 2GB of RAM with one CPU core should +be sufficient. Ubuntu LTS is a choice that is easy to set up and is +low maintenance; however, any Linux or FreeBSD operating system is fine. Less popular systems, such as OpenBSD or +NetBSD, should also work in principle, but they are not regularly tested. + +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 and static 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. +- The reservations are done outside of this dynamic range (depending on the addressing preference, + either 192.168.1.1-192.168.1.99 or 192.168.1.200-192.168.1.254). + +To deploy this setup, perform the following steps: + +1. Install the CA and the DHCPv4 server on host-1, and copy the configuration files to their typical locations. + They are usually in ``/etc/kea`` on Linux and ``/usr/local/etc/kea`` on FreeBSD, and the files are typically called + ``kea-ctrl-agent.conf`` and ``kea-dhcp4.conf``. Please consult the startup scripts for any specific system. + +2. Alter the following to match the local setup: + + - The interface name that Kea should listen on (``interfaces`` in ``interfaces-config``). + + - The interface name that is used to access the subnet (``interface`` in ``subnet4``). + + - The addressing, 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``) matches the DHCPv4 server + configuration (``url`` in ``hook-libraries/parameters/high-availability/peers`` in ``kea-dhcp4.conf``). + + - The router option, to match the actual network. + + - The DNS option, to match the actual network. + + - The path to the hook libraries. This is a very OS-specific parameter; the library names are + generally the same everywhere, but the path varies. See :ref:`hooks-libraries-introduction` for details. + +3. If using a firewall, make sure host-1 can reach host-2. An easy way to ensure that is to + try to retrieve host-2's config from host-1: + + ``curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://192.168.1.3:8000/`` + + The DHCPv4 running configuration should be returned, in JSON format. + +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 the DHCPv4 server 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 there is a local DNS server, DNS updates can be configured via Kea. This requires running a DHCP-DDNS update server + (``kea-dhcp-ddns``). See :ref:`dhcp-ddns-overview` for details. + +- To run Stateful DHCP for IPv6, a ``kea-dhcp6`` server is necessary. Its configuration + is very similar to ``kea-dhcp4``, but there are some notable differences: the default gateway is not + configured via the DHCPv6 protocol, but via router advertisements sent by the local router. Also, the + DHCPv6 concept of prefix delegation does not exist in DHCPv4. See :ref:`dhcp6` + for details. + +- To expand the local network, adding a MySQL or PostgreSQL database is a popular solution. + Users can choose to store leases, host reservations, and even most of the configuration + in a database. See :ref:`admin` and the ``lease-database``, ``hosts-database``, and + ``config-control`` parameters in :ref:`dhcp4`. + +- To provide more insight into how the DHCP server operates, Kea's RESTful API can query + for many runtime statistics or even change the configuration during runtime. Users may also + consider deploying Stork, which is a rapidly developing dashboard for Kea. See :ref:`stork` + for more information. + +- All Kea users should read :ref:`security`: to learn about various trade-offs between + convenience and security in Kea. diff --git a/doc/examples/template-power-user-home/kea-ca-1.conf b/doc/examples/template-power-user-home/kea-ca-1.conf new file mode 100644 index 0000000..9139008 --- /dev/null +++ b/doc/examples/template-power-user-home/kea-ca-1.conf @@ -0,0 +1,66 @@ +// This is an example of a configuration for Control-Agent (CA) listening +// for incoming HTTP traffic. This is necessary for handling API commands, +// in particular lease update commands needed for HA setup. +{ + "Control-agent": + { + // We need to specify where the agent should listen to incoming HTTP + // queries. + "http-host": "192.168.1.2", + + // This specifies the port CA will listen on. + "http-port": 8000, + + "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-power-user-home/kea-ca-2.conf b/doc/examples/template-power-user-home/kea-ca-2.conf new file mode 100644 index 0000000..f36c850 --- /dev/null +++ b/doc/examples/template-power-user-home/kea-ca-2.conf @@ -0,0 +1,66 @@ +// This is an example of a configuration for Control-Agent (CA) listening +// for incoming HTTP traffic. This is necessary for handling API commands, +// in particular lease update commands needed for HA setup. +{ + "Control-agent": + { + // We need to specify where the agent should listen to incoming HTTP + // queries. + "http-host": "192.168.1.3", + + // This specifies the port CA will listen on. + "http-port": 8000, + + "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-power-user-home/kea-dhcp4-1.conf b/doc/examples/template-power-user-home/kea-dhcp4-1.conf new file mode 100644 index 0000000..d4a9d70 --- /dev/null +++ b/doc/examples/template-power-user-home/kea-dhcp4-1.conf @@ -0,0 +1,227 @@ +// 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 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. + // 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, + "peers": [ + // This is the configuration of this server instance. + { + "name": "server1", + // 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.2:8000/", + // This server is primary. The other one must be + // secondary. + "role": "primary" + }, + // This is the configuration of the secondary server. + { + "name": "server2", + // 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.3:8000/", + // 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" + } + ], + + // 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 + } + ] +} +} diff --git a/doc/examples/template-power-user-home/kea-dhcp4-2.conf b/doc/examples/template-power-user-home/kea-dhcp4-2.conf new file mode 100644 index 0000000..f75a997 --- /dev/null +++ b/doc/examples/template-power-user-home/kea-dhcp4-2.conf @@ -0,0 +1,227 @@ +// 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 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. + // 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, + "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 + } + ] +} +} |