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 _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
