
<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Thanks Vicky.<br></div><div><br data-mce-bogus="1"></div><div>Facebook's dhcplb is an option, but it also solves problems that we don't have (imbalance of DHCP messaging and need for staged deployments). It also requires more infra (either physical or virtual) and a slightly greater network complexity which differs from what we already support in other services. I'm trying to stick with the "just because you have a hammer, you should still try to use a screwdriver on screws" philosophy :)<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I suppose the WAY in which the traffic is balanced is ultimately a wash, though. Either way, we'd need Kea instances in a horizontal N-number farm with mostly-identical behaviors (regardless of if they listen for the virtual IP or if it's housed one hop upstream). Ideally, having as little state as possible (or as little state that DIFFERS between hosts) is an important aspect.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Performance tuning, strategy for maintaining the database backend (monolithic vs multiple replicating instances) and so forth will be important, but is there anything inherent about Kea itself that will break this conceptually (unique metadata payload in messaging that will break on DHCP refresh to a different node or something along those lines)?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks<br data-mce-bogus="1"></div><div>Dan<br data-mce-bogus="1"></div><div><br></div><div><span id="zwchr" data-marker="__DIVIDER__">----- On Apr 30, 2024, at 8:39 AM, Victoria Risk <vicky@isc.org> wrote:<br></span></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote><div>On Apr 29, 2024, at 6:16 PM, Dan Geist <dan@polter.net> wrote:</div><br class="Apple-interchange-newline"><div><div><div style="font-family:'arial' , 'helvetica' , sans-serif;font-size:12pt"><div>Hi. I have an environment where many of the network services (DNS, NTP, ToD, etc.) provide scaling, fault tolerance, and load sharing via ECMP (in front of the service) and BGP. Each (of the 2 or more) service node(s) monitors the status of that service and announces/pulls BGP announcements from the upstream router pair. This works really well for protocols with simple request/response transactions.<br></div><br><div>I'd like to try doing this same thing with Kea dhcpv(4|6). In that setup, the same "virtual service IP" would be configured on each of several Kea nodes (in addition to the real link IPs) and they would announce these to the next hop (as above). My thinking is that if there is a common configuration and lease backend to these multiple nodes, then this can be a way to provide HA services (and scaling) to a very large number of devices. My only concern is how the multi-step transaction will be handled.<br></div><br><div>Before I spend the time to mock this up, has anyone else tried ECMP load distribution with DHCP, specifically on Kea, and are there any "gotchas" to be aware of?<br></div></div></div></div></blockquote><br>You might want to check out the DHCP Load Balancer from Facebook: <a href="https://github.com/facebookincubator/dhcplb" target="_blank" rel="nofollow noopener noreferrer">https://github.com/facebookincubator/dhcplb</a><br data-mce-bogus="1"></div><div><br><blockquote><div><div><div style="font-family:'arial' , 'helvetica' , sans-serif;font-size:12pt"><br><div>Thanks.<br></div><div>Dan<br></div><br><div>-- <br></div><div>Dan Geist dan(@)polter.net<br><br></div></div></div>-- <br>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.<br><br>To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.<br><br>Kea-users mailing list<br>Kea-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/kea-users<br></div></blockquote></div><br><br>-- <br>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.<br><br>To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.<br><br>Kea-users mailing list<br>Kea-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/kea-users<br></blockquote></div><div><br></div><div data-marker="__SIG_POST__">-- <br></div><div>Dan Geist dan(@)polter.net<br><br></div></div></body></html>