[Kea-users] Will v1.2 Support Massive Amounts of Subnets?

[Tomek Mrugalski]

W dniu 13.09.2016 o 21:25, Joe Nelson pisze:
> Hello, everyone.  I'm looking for some advice/help/suggestions.
> 
> I work for a fixed wireless ISP.  We deliver a last mile connection to
> our customers via a modified 802.11N or 802.11AC device (Ubiquiti).
> We're working on an entirely new network topology that relies on
> having a single VLAN per customer. Each VLAN will have a /29 of
> private IPv4 or /30 public IPv4 and a /64 of IPv6 space. Without this
> VLAN setup, all customers on a wireless access point would be in one
> broadcast domain which is not acceptable to us.  In addition, the
> individual VLAN's provide other benefits that are specific to a
> wireless network.
> 
> The problem I'm having is finding a DHCP server to hand out addresses
> to so many VLAN's - and to configure it on the fly.  My idea is to
> have DHCP relay enabled on the router at each site and a pair of DHCP
> servers at the head end listening on anycast IP's.  The relay would
> set option 82 with the appropriate router and VLAN information that
> the DHCP server can use to classify the customer with.  Each time a
> customer is provisioned, a new network/pool would need to be created
> for their VLAN.  I would need to be able to load a new network/pool
> into the server without manually editing config files or reloading the
> server.  I'm not at all interested in tracking individual hosts since
> these are end customer devices and can change without our knowledge, I
> just need to configure the subnet per VLAN.
> 
> I've been watching Kea for some time now and I believe that this will
> be able to be done in the 1.2 version that's scheduled for (hopefully)
> later this year.  Specifically, ticket 4285
> (http://kea.isc.org/ticket/4285) seems to reference an API for
> subnets.  Am I correct in understanding what this new API will do?
Hi Joe,
Thank you for looking at Kea.

I think there are couple things here I should address.

First of all, the envisaged API will eventually allow subnet
manipulations, i.e. add new subnets (and pools within them) to the
configuration on the fly, without restarting the whole server.

I specifically used the word "eventually". Let me explain why. The
document we currently have
(http://kea.isc.org/wiki/ControlAPIRequirements) specifies the
requirements for the whole API. This step is more or less done. We may
tweak the requirements a bit, but the major part has been discussed and
is now agreed on. The next step will be a design for the calls we decide
to implement. There's around 90 calls in the requirements and there's
absolutely no way we could implement all of them. At least not in the
near future.

We're planning an internal discussion later this week about which calls
we're going to implement in 1.2. We haven't made the decision yet, but
the calls related to subnets are rather unlikely to go beyond the design
stage.

There's a good reason for that. We have leases and host reservations
that can be stored in databases. If we provide API for manipulating
those, Kea will have something meaningful to do with the changes, i.e.
will put them into the database. For subnets, our current subnet storage
is rather simple and it features in-memory representation of what was
specified in the config file. With subnets, we could in principle change
our in-memory representation, but that would be lost if you restart or
shutdown the server. Of course there's a way to solve that, but it would
require more work. The sad reality is that there's a very small team of
ISC engineers that can work on Kea and we're always resources limited.
So we need to pick.

Regardless if/when the subnet manipulation calls will be implemented,
you will need some way to trigger them. This could either be a script
called by your relay or a hook library in Kea. Such a hook could modify
Kea's configuration on the fly when new client appears. Since this logic
seems to be specific to your setup, this would likely to custom
developed code specific to your deployment.

> Also, how well will this scale?  We currently have approximately 9000
> customers and provision about 20-25 new customers per day.  I don't
> doubt that the server could handle the number of leases, but I don't
> know if having everything split into so many subnets would affect
> performance.
The honest answer is we don't know at this time. We have not tested our
performance for large number of subnets. The subnet selection code as
currently written is not optimal and could be improved. During subnet
selection the subnets are inspected in linear manner, so the number of
subnets defined has some degrading impact on performance. Sadly, I don't
know how big it is.

This can be measured, though. A config file with 9000 subnets could be
generated and then the performance could be measured using perfdhcp.

I suppose this is not exactly what you hoped to hear. Once our internal
discussions are done, I'll post something out and will describe the plan
for 1.2 in more detail.

This is probably a good opportunity to mention that ISC is small
non-profit company that had funded Kea development since 2011. There are
options available other than "let's see and wait". We offer custom
development contracts. Several customers chose that approach in the past
and we developed certain features for them. Also, we prioritise feature
requests coming from existing and prospective customers over general
requests.

Hope that helps,
Tomek