Kea: support hub and spoke HA configurations

[mvglasow]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

Kea allows hub and spoke HA setups, as described in chapter 6.12.19 of the Administrator’s Reference Manual: The server has multiple HA relationships, each with a different this-server-name attribute, a different group of HA peers, potentially a different HA mode, and managing a distinct part of the subnets configured. This is intended for setups where there is a central server acting as a fallback for multiple DHCP servers on “satellite” networks, with each of the satellite servers serving just their local network.

This setup requires two things on the central server:

• Multiple HA relationships, each with its own this-server-name, list of peers and HA mode
• An ha-server-name for each subnet, tying it to one HA relationship

The GUI currently does not seem to allow that, as it only provides a single this-server-name option, a single list of HA peers without any grouping or other distinction, and no ha-server-name for subnets.

Describe the solution you like

The solution is just a matter of exposing existing Kea functionality through the GUI:

• Instead of a single this-server-name option, expose a list. (The Enable HA check box could be eliminated, HA being enabled iff the list has at least one entry.) Instead of empty values being replaced with the local host name, use a placeholder for that purpose (say, ${hostname}-lan becomes alice-lan on server alice and bob-lan on server bob) – this gives additional flexibility, which may be needed when the local host may be known by different names in different HA relationships.
• Each HA peer configured references one of the values from the this-server-name lists, identifying it as part of that relationship. The hostname placeholder can be used in the same manner as above. This field is mandatory.
• Each subnet can be configured with a ha-server-name attribute (for simplicity, this can again be limited to values from the this-server-name list).
• When migrating from a previous version:
  • If HA is not configured, there is nothing to do.
  • If HA is configured:
    • Convert this-server-name to a single list entry. If the name is empty, replace it with the hostname placeholder.
    • Use that same value to populate the new this-server-name attribute of the HA peers configured.
    • Add a ha-server-name value to each subnet, again populating it with the same value as above. (Not sure if that field is mandatory or how a hub and spoke setup treats subnets without that attribute – if that causes the subnet to be synchronized with all peers, we can leave it unset.)

Describe alternatives you considered

How to expose Kea functionality through the GUI is mainly a UX question. Another approach would be:

• Remove HA settings from the Settings tab, and rename HA Peers to HA Relationships.
• HA Relationships is divided into sections, one per relationship. Each section has a mandatory this-server-name and a list of peers, which must contain at least one server in addition to the local one.

Without exposing this part of Kea functionality through the GUI, we’d be limited to workarounds:

Since multiple DHCP servers (even from different vendors) can coexist on the same network (as long as their ranges don’t overlap, each hands out a valid IP config for that network and static leases are honored in the same way), one could simply set up satellite servers as independent DHCP servers. Drawback: one needs to keep configurations in sync manually (error-prone), and there is some resource wastage since each DHCP broadcast will be answered by both servers.

One could also have all satellite servers sync the whole database with the central server. Drawback: if the satellite networks cannot communicate between each other (such as in a multi-tenant setup, where each satellite belongs to a different tenant), the setup needs to be cold-standby with the central server being the primary, else some (or even all) DHCP broadcasts from all but one satellite will go unanswered because the central server assumes a satellite server is taking care of it – the satellite server is up and running as far as the central server is concerned, but unreachable from the client’s network. Also, in such a setup, failover with multiple satellite servers may not work properly: either the new active node is reachable only from parts of the network, or multiple nodes will claim to be the active one and issues may occur when the primary returns. Not sure how Kea handles this kind of situation; the official answer is probably to use a hub and spoke configuration instead.

Additional context

Add any other context or screenshots about the feature request here or links to relevant forum thread or similar