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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
// This is an example configuration of the Kea DHCPv4 server. It uses High
// 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.
{
// DHCPv4 configuration starts here.
"Dhcp4": {
// Add names of your network interfaces to listen on.
"interfaces-config": {
// The DHCPv4 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/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
"type": "memfile"
},
// Client classes will associate address pools with certain servers taking
// part in providing High Availability.
"client-classes": [
// phones class
{
"name": "phones",
"test": "substring(option[60].hex,0,6) == 'Aastra'"
},
// laptops are everything but phones.
{
"name": "laptops",
"test": "not member('phones')"
},
// Some phones will be handled by server1. Whether the HA_server1
// or HA_server2 is assigned for the client is a matter of load
// balancing performed by the HA hooks library.
{
"name": "phones_server1",
"test": "member('phones') and member('HA_server1')"
},
// Some phones will be handled by server2.
{
"name": "phones_server2",
"test": "member('phones') and member('HA_server2')"
},
// Some laptops will be handled by server1.
{
"name": "laptops_server1",
"test": "member('laptops') and member('HA_server1')"
},
// Some laptops will be handled by server2.
{
"name": "laptops_server2",
"test": "member('laptops') and member('HA_server2')"
}
],
// 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": [
// 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 hooks 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": "server1",
// The HA mode is set to load-balancing. In this mode, the active
// servers share the traffic (50/50).
"mode": "load-balancing",
// 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,
// This specifies the maximum timeout (in milliseconds) for the server
// to complete sync. If you have a large deployment (high tens or
// hundreds of thausands 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 our server instance. The
// Control Agent must run along with our DHCPv4 server
// instance and the "http-host" and "http-port" must be
// set to the corresponding values.
"url": "http://192.168.56.33:8000/",
// This server is primary. The other one must be
// secondary.
"role": "primary"
},
// This is the configuration of our HA peer.
{
"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.56.66:8000/",
// The partner is a secondary. Our is primary.
"role": "secondary"
}
]
} ]
}
}
],
// This example contains a single subnet declaration.
"subnet4": [
{
// Subnet prefix.
"subnet": "192.0.3.0/24",
// Specify four address pools.
"pools": [
{
"pool": "192.0.3.100 - 192.0.3.125",
"client-class": "phones_server1"
},
{
"pool": "192.0.3.126 - 192.0.3.150",
"client-class": "laptops_server1"
},
{
"pool": "192.0.3.200 - 192.0.3.225",
"client-class": "phones_server2"
},
{
"pool": "192.0.3.226 - 192.0.3.250",
"client-class": "laptops_server2"
}
],
// 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.
"option-data": [
{
// For each IPv4 subnet you most likely need to specify at
// least one router.
"name": "routers",
"data": "192.0.3.1"
}
],
// This subnet will be selected for queries coming from the following
// IP address.
"relay": { "ip-address": "192.168.56.1" }
}
],
// 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 more) to a file.
"name": "kea-dhcp4",
"output_options": [
{
"output": "stdout"
}
],
"severity": "INFO"
},
{
// This section specifies configuration of the HA hooks library specific
// logger.
"name": "kea-dhcp4.ha-hooks",
"output_options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
|
