kea-ctrl-agent.conf and kea-dhcp4.conf. Please consult your start-up scripts.
2. At the very least alter the following to match your setup:
- - the interface name which Kea should listen on
- - the interface name which is used to access the subnet
- - your addressing, if you use something different than 192.168.1.0/24
- - tweak your router option
- - tweak your DNS option
+
+ - the interface name which Kea should listen on (``interfaces`` in ``interfaces-config``)
+
+ - the interface name which is used to access the subnet (``interface`` in ``subnet4``)
+
+ - your addressing, if you use something different than 192.168.1.0/24. Make sure the CA port
+ configuration (``http-host`` and ``http-port`` in kea-ca.conf) matches your DHCPv4 server
+ configuration (``url`` in ``hook-libraries/parameters/high-availability/peers`` in kea-dhcp4.conf).
+
+ - tweak your router option to match your actual network
+
+ - tweak your DNS option to match your actual network
3. If using firewall, make sure the server1 can reach the server2. A nice way to ensure that is to
try to retrieve server2's config from the server1:
- curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://192.168.1.3:8000/
+ ``curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://192.168.1.3:8000/``
+
+ You should get a DHCPv4 running configuration in return in a JSON format.
-4. Install CA and DHCPv4 on host2, similar to steps 1 and 2. Note the config file for the
+4. Make sure the opposite direction (server2 can connect to server1). Simply repeat step 3 from the
+ server2 and user server's 1 IP address and port.
+
+5. Install CA and DHCPv4 on host2, similar to steps 1 and 2. Note the config file for the
standby server is very similar, except the definition of "this-server-name" field
(and possibly inteface names). In many cases you can simply copy over the file
and just tweak it a little bit.
The proposed configuration is somewhat basic, but functional. Once your setup is up and running, you
may want to consider the following changes:
-- if you have your own DNS server, you may configure DNS Updates. This requires running a D2 server,
- which is a nickname for DHCP-DDNS update server. See Section 13 of the Kea ARM for details.
+- if you have your own DNS server, you may configure DNS Updates. This requires running a D2 server
+ (``kea-dhcp-ddns``), which is a nickname for DHCP-DDNS update server. See Section 13 of the Kea ARM
+ for details.
-- if you want to run Stateful DHCP for IPv6, you will need to run `kea-dhcp6` server. Its configuration
- is very similar to `kea-dhcp4`, but there are some notable differences: the default gateway is not
+- if you want to run Stateful DHCP for IPv6, you will need to run ``kea-dhcp6`` server. Its configuration
+ is very similar to ``kea-dhcp4``, but there are some notable differences: the default gateway is not
configured via DHCPv6 protocol, but via Router Advertisements sent by your router. Also, there is
a concept of Prefix Delegation, which was non-existent in the DHCPv4. See Section 9 of the Kea ARM
for details.
- if you want to expand your network, adding MySQL or PostgreSQL database is a popular direction for
growing networks. You can choose to store leases, host reservations and even most of the configuration
- in a database. See Section 4 of the Kea ARM and `lease-database`, `hosts-database`, and `config-control`
- parameters in Section 8 of the Kea ARM.
+ in a database. See Section 4 of the Kea ARM and ``lease-database``, ``hosts-database``, and
+ ``config-control`` parameters in Section 8 of the Kea ARM.
- if you want to get more insight into how your DHCP server operates, you may use REST API to query
for a lot of run-time statistics or even change your configuration during run-time. You may also