1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
// This is an example configuration of the Kea DHCPv6 server. It uses High
// Availability hook library and Lease Commands hook 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 "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.
{
// DHCPv6 configuration starts here.
"Dhcp6": {
// Add names of your network interfaces to listen on.
"interfaces-config": {
// The DHCPv6 server listens on this interface.
"interfaces": [ "eth0" ]
},
// 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/kea6-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
"type": "memfile"
},
// 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.
"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": "/opt/lib/kea/hooks/libdhcp_lease_cmds.so",
"parameters": { }
},
{
// The HA hook library should be loaded.
"library": "/opt/lib/kea/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": 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,
"peers": [
// This is the configuration of the 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:8000/",
// The partner is primary. This server is standby.
"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 DHCPv6 server
// instance and the "http-host" and "http-port" must be
// set to the corresponding values.
"url": "http://192.168.56.66:8000/",
// This server is standby. The other one must be
// primary.
"role": "standby"
}
]
} ]
}
}
],
// The following list defines subnets. Each subnet consists of at
// least subnet and pool entries.
"subnet6": [
{
"id": 1,
"subnet": "2001:db8:1::/64",
"pools": [
{
"pool": "2001:db8:1::100 - 2001:db8:1::250"
}
],
"interface": "eth0"
}
],
// 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.
"loggers": [
{
// This section affects kea-dhcp6, which is the base logger for DHCPv6
// component. It tells DHCPv6 server to write all log messages (on
// severity INFO or more) to a file.
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 0
},
{
// This section specifies configuration of the HA hook library-specific
// logger.
"name": "kea-dhcp6.ha-hooks",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 99
}
]
}
}
|
