<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 4/30/24 9:18 AM, Dan Geist wrote:<br>
</div>
<blockquote type="cite"
cite="mid:152421590.104039.1714483124002.JavaMail.zimbra@polter.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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 <a class="moz-txt-link-rfc2396E" href="mailto:vicky@isc.org"><vicky@isc.org></a> 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
<a class="moz-txt-link-rfc2396E" href="mailto:dan@polter.net"><dan@polter.net></a> 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"
moz-do-not-send="true" class="moz-txt-link-freetext">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
<a class="moz-txt-link-freetext" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.<br>
<br>
To unsubscribe visit
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a>.<br>
<br>
Kea-users mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a><br>
</div>
</blockquote>
</div>
<br>
<br>
-- <br>
ISC funds the development of this software with paid support
subscriptions. Contact us at <a class="moz-txt-link-freetext" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a>
for more information.<br>
<br>
To unsubscribe visit
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a>.<br>
<br>
Kea-users mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a><br>
</blockquote>
</div>
<div><br>
</div>
<div data-marker="__SIG_POST__">-- <br>
</div>
<div>Dan Geist dan(@)polter.net<br>
<br>
</div>
</div>
<br>
</blockquote>
<p>i do quite a bit of anycast, using BGP, which may differ from
your ECMP desires. that said, there is probably some overlap in
the what, how and why between the setups. i have 3 nodes all
participating in BGP, and they inject routes to the IPs for
several stateless services, like DNS, NTP, Kerberos, etc. in my
BGP configs, i have set maximum-paths to 4, allowing for multiple
routes to the same address. then i put the anycast IP on the
loopback or some other virtual interface, so that the anycast IP
is not on the wire. if i understand things correctly, this
anycast setup is the way the root DNS servers are setup for their
anycast configurations.<br>
</p>
<p>i have started thinking about setting up Kea to have the
"listening" interface be a VIP on the loopback, like the rest of
my anycast services, but haven't gotten to a final design or game
plan. i am still muttering through how Kea will work when i want
to have the "listening" interface receive requests and respond to
them, while using a different interface to talk to the other HA
instances or to the database i'm using for configs, etc. the
question i have not answered yet is, what, if any, stateful
requirements are there in Kea, that would obviate the use of
anycast?</p>
<p>stateless protocols are fully self contained in request and
response, and i dont know if dhcp, when served by Kea, is entirely
stateless. client to server requests, and their responses may be,
but what happens when you have a relay in between, like i do? can
Kea talk to different things from different IPs? like i said, can
dhcp requests and responses be received and responded to from a
VIP that is stacked on the loopback interface? can that happen
while other communications are going on, and using different
interfaces/IPs for those other communications?</p>
<p>i could definitely see a great reason for anycast or ECMP, and
the scalability, reliability and fault tolerance those bring, but
its the "how" of it all that i have not fully rationalized yet.</p>
<p>i hope you can accomplish what you are looking for, and would
love to hear of any progress you make.</p>
<p>thank you,</p>
<p>brendan kearney<br>
</p>
</body>
</html>