mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-09-01 22:45:18 +00:00
Code Issues Releases Wiki Activity

[#2050] Removed class assignments, updated kea-dhcp4-2

Browse Source
This commit is contained in:
Tomek Mrugalski
2021-09-23 14:02:36 +02:00
parent 2969aa23a9
commit a77985eaa9
2 changed files with 101 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
doc/examples/template-power-user-home/kea-dhcp4-1.conf
View File

@@ -152,8 +152,7 @@
// Specify a dynamic address pool. // Specify a dynamic address pool.
"pools": [ "pools": [
{ {
"pool": "192.168.1.100-192.168.1.199", "pool": "192.168.1.100-192.168.1.199"
"client-class": "HA_server1"
} }
], ],

117
doc/examples/template-power-user-home/kea-dhcp4-2.conf
View File

@@ -1,16 +1,22 @@
// This is an example configuration of the Kea DHCPv4 server. It uses High // This is an example configuration of the Kea DHCPv4 server 1:
// Availability hooks library and Lease Commands hooks library to enable
// High Availability function for the DHCP server. Note that almost exactly
// the same configuration must be used on the second server (partner).
// The only difference is that "this-server-name" must be set to "server2"
// on this other server. Also, the interface configuration depends on the
// network settings of the particular machine.
// //
// The servers using this configuration work in load balancing mode. // - 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 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.
{ {
// DHCPv4 configuration starts here.
"Dhcp4": { "Dhcp4": {
// Add names of your network interfaces to listen on. // Add names of your network interfaces to listen on.
"interfaces-config": { "interfaces-config": {
// The DHCPv4 server listens on this interface. When changing this to // The DHCPv4 server listens on this interface. When changing this to
@@ -36,9 +42,28 @@
// Storage" for details. // Storage" for details.
"lease-database": { "lease-database": {
// Memfile is the simplest and easiest backend to use. It's an in-memory // 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" "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 aggresively.
"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 // 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. // libdhcp_ha.so. The former handles incoming lease updates from the HA peers.
// The latter implements high availability feature for Kea. // The latter implements high availability feature for Kea.
@@ -54,14 +79,13 @@
// The HA hooks library should be loaded. // The HA hooks library should be loaded.
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so", "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": { "parameters": {
// High Availability configuration is specified for the HA hook library.
// Each server should have the same HA configuration, except for the // Each server should have the same HA configuration, except for the
// "this-server-name" parameter. // "this-server-name" parameter.
"high-availability": [ { "high-availability": [ {
// This parameter points to this server instance. The respective // This parameter points to this server instance. The respective
// HA peers must have this parameter set to their own names. // HA peers must have this parameter set to their own names.
"this-server-name": "server2", "this-server-name": "server2",
// The HA mode is set to load-balancing. In this mode, the active // The HA mode is set to host-standby. In this mode, the active
// servers share the traffic (50/50). // servers share the traffic (50/50).
"mode": "hot-standby", "mode": "hot-standby",
// Heartbeat is to be sent every 10 seconds if no other control // Heartbeat is to be sent every 10 seconds if no other control
@@ -69,6 +93,8 @@
"heartbeat-delay": 10000, "heartbeat-delay": 10000,
// Maximum time for partner's response to a heartbeat, after which // Maximum time for partner's response to a heartbeat, after which
// failure detection is started. This is specified in milliseconds. // 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, "max-response-delay": 60000,
// The following parameters control how the server detects the // The following parameters control how the server detects the
// partner's failure. The ACK delay sets the threshold for the // partner's failure. The ACK delay sets the threshold for the
@@ -80,7 +106,7 @@
"max-unacked-clients": 5, "max-unacked-clients": 5,
// This specifies the maximum timeout (in milliseconds) for the server // This specifies the maximum timeout (in milliseconds) for the server
// to complete sync. If you have a large deployment (high tens or // to complete sync. If you have a large deployment (high tens or
// hundreds of thausands of clients), you may need to increase it // hundreds of thousands of clients), you may need to increase it
// further. The default value is 60000ms (60 seconds). // further. The default value is 60000ms (60 seconds).
"sync-timeout": 60000, "sync-timeout": 60000,
"peers": [ "peers": [
@@ -123,26 +149,22 @@
// is reachable directly via the ethX interface. // is reachable directly via the ethX interface.
"interface": "enp0s8", "interface": "enp0s8",
// Specify four address pools. // Specify a dynamic address pool.
"pools": [ "pools": [
{ {
"pool": "192.168.1.100-192.168.1.149", "pool": "192.168.1.100-192.168.1.199"
"client-class": "HA_server1"
},
{
"pool": "192.168.1.150-192.168.1.200",
"client-class": "HA_server2"
} }
], ],
// These are options that are subnet specific. In most cases, // These are options that are subnet specific. In most cases, you need to define at
// you need to define at least routers option, as without this // least routers option, as without this option your clients will not be able to reach
// option your clients will not be able to reach their default // their default gateway and will not have Internet connectivity. If you have many
// gateway and will not have Internet connectivity. // subnets and they share the same options (e.g. DNS servers typically is the same
// everywhere), you may define options in the global scope, so you don't repeat them
// for every network.
"option-data": [ "option-data": [
{ {
// For each IPv4 subnet you most likely need to specify at // For each IPv4 subnet you typically need to specify at least one router.
// least one router.
"name": "routers", "name": "routers",
"data": "192.168.1.1" "data": "192.168.1.1"
}, },
@@ -154,6 +176,25 @@
"name": "domain-name-servers", "name": "domain-name-servers",
"data": "1.1.1.1,9.9.9.9" "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"
}
] ]
} }
], ],
@@ -161,28 +202,20 @@
// Logging configuration starts here. // Logging configuration starts here.
"loggers": [ "loggers": [
{ {
// This section affects kea-dhcp4, which is the base logger for DHCPv4 // This section affects kea-dhcp4, which is the base logger for DHCPv4 component. It tells
// component. It tells DHCPv4 server to write all log messages (on // DHCPv4 server to write all log messages (on severity INFO or higher) to a file. The file
// severity INFO or more) to a 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", "name": "kea-dhcp4",
"output_options": [ "output_options": [
{ {
"output": "/var/log/kea-dhcp4.log" "output": "/var/log/kea-dhcp4.log",
"maxsize": 2048000,
"maxver": 4
} }
], ],
"severity": "INFO" "severity": "INFO",
}, "debuglevel": 0
{
// This section specifies configuration of the HA hooks library specific
// logger.
"name": "kea-dhcp4.ha-hooks",
"output_options": [
{
"output": "stdout"
}
],
"severity": "INFO"
} }
] ]
} }