mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-31 14:05:33 +00:00
Code Issues Releases Wiki Activity

[5478] Added example HA configuration for DHCPv6.

Browse Source
This commit is contained in:
Marcin Siodelski
2018-05-10 16:35:52 +02:00
parent faf9041e59
commit a61fcb5a1f
2 changed files with 154 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
doc/Makefile.am
View File

@@ -43,6 +43,7 @@ nobase_dist_doc_DATA += examples/kea6/classify2.json
nobase_dist_doc_DATA += examples/kea6/comments.json
nobase_dist_doc_DATA += examples/kea6/dhcpv4-over-dhcpv6.json
nobase_dist_doc_DATA += examples/kea6/duid.json
nobase_dist_doc_DATA += examples/kea6/ha-hot-standby.json
nobase_dist_doc_DATA += examples/kea6/hooks.json
nobase_dist_doc_DATA += examples/kea6/iPXE.json
nobase_dist_doc_DATA += examples/kea6/leases-expiration.json

153
doc/examples/kea6/ha-hot-standby.json Normal file
View File

@@ -0,0 +1,153 @@
// This is an example configuration of the Kea DHCPv6 server. It uses High
// Availability hooks library and Lease Commands hooks library to enable
// High Availibility 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 "server1"
// on this other server. Also, the interface configuration depends on the
// network settings of the particular machine.
//
// The servers using this configuration work in hot standby mode..
{ "Dhcp6":
{
// Kea is told to listen on ethX interface only.
"interfaces-config": {
"interfaces": [ "ethX" ]
},
// 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/kea-dhcp6-ctrl.sock"
},
// 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) and even Cassandra. 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 a in-memory
"type": "memfile"
},
// 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.
"hooks-libraries": [
{
"library": "/opt/lib/hooks/libdhcp_lease_cmds.so",
"parameters": { }
},
{
// The HA hooks library should be loaded.
"library": "/opt/lib/hooks/libdhcp_ha.so",
"parameters": {
// High Availability configuration is specified for the HA hook library.
// 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. This server will receive lease
// updates from the primary. The primary will be responding to all
// DHCP queries.
"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.
"max-response-delay": 10000,
// 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,
"peers": [
// This is the configuration of our HA peer.
{
"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.56.33:8080/",
// Th partner is primary. Our is standby.
"role": "primary"
},
// This is the configuration of this server instance.
{
"name": "server2",
// This specifies the URL of our server instance. The
// Control Agent must run along with our DHCPv6 server
// instance and the "http-host" and "http-port" must be
// set to the corresponding values.
"url": "http://192.168.56.66:8080/",
// Out server is standby. The partner is primary.
"role": "standby"
}
]
} ]
}
}
],
// The following list defines subnets. Each subnet consists of at
// least subnet and pool entries.
"subnet6": [
{
"subnet": "2001:db8:1::/64",
"pools": [
{
"pool": "2001:db8:1::100 - 2001:db8:1::250"
}
],
"interface": "ethX"
}
]
},
// The following configures logging. It assumes that messages with at
// least informational level (info, warn, error and fatal) should be
// logged to stdout. Alternatively, you can specify stderr here, a filename
// or 'syslog', which will store output messages via syslog.
"Logging": {
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
},
{
// This section specifies configuration of the HA hooks library specific
// logger.
"name": "kea-dhcp4.ha_hooks",
"output_options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 99
}
]
}
}