(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

Reply via email to