[Kea-users] Kea implementation planning

[Ben Monroe]

Hi Francis and Jason,

Thank you very much for your responses.
I found them both to be very informative.

> 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).

Thinking this over some more, is there really any need to get around this,
though?
Even if a client receives multiple offers, it can only accept one of them.
The client will then send a response to the single DHCP server that it
accepted the offer from.
That DHCP server will then acknowledge and commit the state as in use.
Any other DHCP servers will not receive a response from the client, so they
can revert the initial offer.

Of course traditionally this needs to be combined with splitting the
address range between each DHCP server to work well.
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.
As a result, the requirement to split the address range suddenly goes away.

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.

Thank you,
Ben Monroe


On Tue, Jan 16, 2018 at 1:06 AM, Jason Guy <jguy at cumulusnetworks.com> wrote:

> Hi Ben,
>
> Good questions, and like most other technology, the answer always starts
> with "It depends..." :)
> I will expand on what Francis said with some of my own thoughts and
> decisions as I was implementing my setup.
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> Hope this helps.
> Jason
>
>
>
>
> On Mon, Jan 15, 2018 at 3:50 AM, Francis Dupont <fdupont at isc.org> wrote:
>
>> Ben Monroe writes:
>> > 1)      Is it normal for a subnet to have a single DHCP instance or
>> > multiples instances?
>>
>> => single
>>
>> > 2)      In the case that multiple DHCP servers exist on a the same
>> subnet,
>> > are the instances all active and load balanced? Or is only one active
>> while
>> > the others are inactive until some kind of failover occurs?
>>
>> => you can do both.
>>
>> > 3)      If multiple DHCP servers exist on the same subnet and are all
>> > active, what is to prevent a client from receiving multiple DHCP
>> responses?
>>
>> => nothing!
>>
>> > 4)      Is it normal to run both DNS and DHCP services on a single
>> server?
>> > Are there advantages to running DNS and DHCP on separate servers?
>>
>> => it is common but of course you get a single point of failure.
>>
>> > The answers to these questions will help in deciding whether I should
>> > install Kea on the same server instances (Raspberry Pi 3) that are
>> running
>> > DNS (Bind), how many servers, or whether I should split them to
>> dedicated
>> > servers (likely also Raspberry Pi 3).
>>
>> => you have another choice: use a file or a database for leases and
>> in the second case where to put the database server (same box than Kea
>> or another box).
>>
>> Thanks
>>
>> Francis Dupont <fdupont at isc.org>
>> _______________________________________________
>> Kea-users mailing list
>> Kea-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20180118/4a0826fd/attachment.htm>