(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.
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users