[Kea-users] Kea DHCPv4 with redundant routing - design review

[Kevin P. Fleming]

(Note: This message is a bit long, apologies for that but it's important to include all of the details. Also none of this applies to DHCPv6, since it uses only link-local and multicast addresses.)

I've had Kea deployed for some time, in HA load-balancing mode, and it's been working well. The Kea servers were behind a core router, so they used UDP sockets and received all client traffic via relays on the router.

I recently reconfigured the network, and Kea is now running *on* the boxes providing routing for the network, so it is using 'raw' sockets because the client subnets are directly attached.

There are two boxes (A and B), and they provide IPv4 routing to the clients using floating IPs (VIPs) handled by Pacemaker. At any given moment only one of the two boxes has addresses with /24 subnet masks on the client subnets; if both boxes have such addresses I experience strange asymmetric routing issues.

Since Kea requires an IPv4 address on each directly-attached subnet it serves, I've also added addresses with /32 subnet masks on both boxes. I didn't really expect this to work since there is no route for outbound traffic to the subnet on the box currently acting as the 'secondary' router, but it does work. In the Kea configuration the 'interface' items are tied to those /32 'identity' addresses explicitly.

In the normal mode (where box A is handling routing), the configuration looks like this:

Box A - interface 'untrusted'
192.168.80.3/24 (VIP)
192.168.80.20/32 (identity)

Box B - interface 'untrusted'
192.168.80.21/32 (identity)

If Pacemaker decides that box B should handle routing, then the configuration changes to:

Box A - interface 'untrusted'
192.168.80.20/32 (identity)

Box B - interface 'untrusted'
192.168.80.3/24 (VIP)
192.168.80.21/32 (identity)

Kea stays running the entire time, it is unaffected by any decisions made by Pacemaker.

I think this is working because Kea is using a raw socket, and:

1) Inbound broadcast traffic is unaffected by the presence or absence of a wider subnet mask.

2) Kea is able to send traffic directly on the subnet interface because its outbound packets bypass the routing table.

3) Inbound unicast traffic (for renewals) will still be received because the destination address is present on the subnet interface, regardless of the subnet mask in use.

Is this a valid/correct configuration? If not, is there a better way to configure a system like this?

If I switched to hot-standby mode, I think I'd still need to have these /32 addresses on the interfaces, because the standby server is going to open its sockets when it starts up, not when it goes into 'active' mode.

Thanks in advance for your time and thoughts about this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230321/acaab75b/attachment.htm>