<div dir="ltr">Hi Francis and Jason,<div><br></div><div>Thank you very much for your responses.</div><div>I found them both to be very informative.</div><div><br></div><div><span style="font-size:12.8px">> 3) Assuming the server is physically on the same subnet (no dhcp relay), both servers will act on the DHCP broadcast messages.</span></div><div><span style="font-size:12.8px">> To get around this, you will put the DHCP servers behind an load balancer (like HA-proxy).</span><br></div><div><span style="font-size:12.8px"><br></span></div><div>Thinking this over some more, is there really any need to get around this, though?</div><div>Even if a client receives multiple offers, it can only accept one of them.</div><div>The client will then send a response to the single DHCP server that it accepted the offer from.</div><div>That DHCP server will then acknowledge and commit the state as in use.</div><div>Any other DHCP servers will not receive a response from the client, so they can revert the initial offer.</div><div><br></div><div>Of course traditionally this needs to be combined with splitting the address range between each DHCP server to work well.</div><div>However, Kea seems to offer a better solution, which you seemed to allude to: as the lease state is (can be) stored in a shared database, the served data is consistent regardless of which DHCP server processes the request.</div><div>As a result, the requirement to split the address range suddenly goes away.</div><div><br></div><div>I think I'll start slow with a single DHCP server for now, but once I'm more accustomed to Kea will prototype more with additional servers.</div><div><br></div><div>Thank you,</div><div>Ben Monroe</div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 1:06 AM, Jason Guy <span dir="ltr"><<a href="mailto:jguy@cumulusnetworks.com" target="_blank">jguy@cumulusnetworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ben,<div><br></div><div>Good questions, and like most other technology, the answer always starts with "It depends..." :) </div><div>I will expand on what Francis said with some of my own thoughts and decisions as I was implementing my setup.</div><div><br></div><div>1) The best thing about Kea is that the data can be stored in a separate server running a database. This allows you to have a single server, or multiple servers. </div><div><br></div><div>2) There are HA features coming in Kea, and that will hopefully make multiple instances a lot easier to work with. Currently the thing to understand is the server that offers the leas, is the server that has to manage that lease. While the data is stored in the database, the state is local to the server. As I understand it, the HA features will allow that state to be shared between servers, meaning in the event of a failure, the redundant server can pickup the management of the lease.</div><div><br></div><div>3) Assuming the server is physically on the same subnet (no dhcp relay), both servers will act on the DHCP broadcast messages. To get around this, you will put the DHCP servers behind an load balancer (like HA-proxy).</div><div><br></div><div>4) In the spirit of deploying microservices, it is best to separate each service, and use the DHCP-DDNS to populate the DNS server with the DHCP information. </div><div><br></div><div>In my deployment, I created everything as virtual machines to leverage the HA redundancy of the compute servers as well. The Raspberry Pi's are a fine choice, but I found VMs to be a lot easier to work with if I need to scale things up (which I am working on now). The other decision I made was to use PowerDNS because it also stores the data in a database, thus separating the service from the data. </div><div><br></div><div>Hope this helps.</div><div>Jason</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Jan 15, 2018 at 3:50 AM, Francis Dupont <span dir="ltr"><<a href="mailto:fdupont@isc.org" target="_blank">fdupont@isc.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><span>Ben Monroe writes:<br>
> 1)      Is it normal for a subnet to have a single DHCP instance or<br>
> multiples instances?<br>
<br>
</span>=> single<br>
<span><br>
> 2)      In the case that multiple DHCP servers exist on a the same subnet,<br>
> are the instances all active and load balanced? Or is only one active while<br>
> the others are inactive until some kind of failover occurs?<br>
<br>
</span>=> you can do both.<br>
<span><br>
> 3)      If multiple DHCP servers exist on the same subnet and are all<br>
> active, what is to prevent a client from receiving multiple DHCP responses?<br>
<br>
</span>=> nothing!<br>
<span><br>
> 4)      Is it normal to run both DNS and DHCP services on a single server?<br>
> Are there advantages to running DNS and DHCP on separate servers?<br>
<br>
</span>=> it is common but of course you get a single point of failure.<br>
<span><br>
> The answers to these questions will help in deciding whether I should<br>
> install Kea on the same server instances (Raspberry Pi 3) that are running<br>
> DNS (Bind), how many servers, or whether I should split them to dedicated<br>
> servers (likely also Raspberry Pi 3).<br>
<br>
</span>=> you have another choice: use a file or a database for leases and<br>
in the second case where to put the database server (same box than Kea<br>
or another box).<br>
<br>
Thanks<br>
<br>
Francis Dupont <<a href="mailto:fdupont@isc.org" target="_blank">fdupont@isc.org</a>><br></div></div>
______________________________<wbr>_________________<br>
Kea-users mailing list<br>
<a href="mailto:Kea-users@lists.isc.org" target="_blank">Kea-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/kea-users</a><br>
</blockquote></div><br></div>
</blockquote></div><br></div>