[Kea-users] Question about reservations, subnet limits and lease control.

Thu Oct 26 09:56:33 UTC 2017

Joelson,

I recall you were asking about some alternative identifiers by which
client leases could be indexed in the lease database.

In a couple of days we're going to release Kea 1.3.0. Along with that,
we're going to release new package of hooks libraries which include
"flex-id" library. This library allows for defining an expression to be
used to create client identifier out of any piece of information within
the received packet. This identifier can be used to retrieve host
reservations. With the latest version of this library we have added an
ability to also use a value derived from this identifier as a client
identifier in the lease database.

You can read more about this feature in our User's Guide:

https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#flex-id

The library is available for support customers and for purchase. Please
consult https://www.isc.org/product/kea-hook-1-2/ for details, but note
that the latest version supporting indexing leases by flex-id will be
available in a couple of days.

Marcin Siodelski
ISC

On 04.10.2017 16:44, Joelson Vendramin wrote:
> Hello Marcin,
> 
> 
> Thank you for your reply!
> 
>> I suggest that you keep an eye on the CPU utilization by the Kea server
>> as you increase the number of resources such as subnets, pools and
>> reservations. If you observe overly increasing CPU utilization while
> 
>> running Kea, please let us know. We can always try to do better if possible.
> +++ OK! I'll do that!
> 
>> What you seem to be looking for is a way to identify a client by some
>> other value (or a collection of values) regardless of the client
>> identifier and MAC address. Such identifier would need to be stored in
>> the lease database apart from client id and MAC address and take
>> precedence over the other two.
> +++ Yes! You got the point!
> Historically the DHCP protocol is MAC-dependent. Nothing wrong with that: it's the RFC and it was its main objective. 
> 
> However, nowadays, ISPs use DHCP as an alternative to PPPoE "plus" Radius address deployment, commonly called IPoE approach. In this scenario, MAC addresses are not important, but the "Options" inserted by relays are!
> 
> So it seems that an ISP-friendly DHCP Server implementation is welcome!
> 
> By the way, congratulations about KEA.
> ISC team are doing a great job!
> 
> Regards,
> --
> Joelson Vendramin
> 
> 
> ________________________________
> 
> 
> 
> De: Marcin Siodelski <marcin at isc.org>
> Para: Joelson Vendramin <jtvendramin at yahoo.com.br>; Kea Users List <kea-users at lists.isc.org> 
> Enviadas: Terça-feira, 26 de Setembro de 2017 9:49
> Assunto: Re: [Kea-users] Question about reservations, subnet limits and lease control.
> 
> 
> 
> Hello Joelson,
> 
> See my answers below.
> 
> 
> On 15.09.2017 18:22, Joelson Vendramin wrote:
>> Hello Kea Users!
>>
>> I'm using Kea 1.2.0 in an environment that uses only Option82 (for IPv4) and Option18 (for IPv6) in order to always provide the same addresses to the same client (in fact, the same VLAN ID that asks for IPs).
>>
>> Since I don't have the flex-id hook library, I'm implementing IPv4 with the usual "reservations" based on "circuit-id". But for IPv6 I've defined several "subnets" based on "interface-id" provided by DHCPv6 relay agent. Inside each subnet I've declared "pools" (with only one address) and "pd-pools" (with only one prefix).
>>
>> Considering this implementation, I've two questions:
>>
>>
>> (1) Is there any hard limit on the number of "reservations" (for IPv4) or "subnets & pools & pd-pools" (for IPv6)? Today I'm running about 260 of each, but they tend to increase in the future.
>> Note: I'm not using any DB backend, just the default TXT-based memfiles.
>>
> 
> There are no arbitrary limits. Kea uses indexing for reservations so the
> number of reservations should not have a significant impact on the
> server performance. Subnet selection process is slightly more complex
> and you may observe some performance degradation with a growing number
> of subnets. BTW, there is probably some room for improvement on our end
> here.
> 
> I suggest that you keep an eye on the CPU utilization by the Kea server
> as you increase the number of resources such as subnets, pools and
> reservations. If you observe overly increasing CPU utilization while
> running Kea, please let us know. We can always try to do better if possible.
> 
> 
>> (2) I know that my question will be a bit strange, but... Is there a way to disable any kind of lease control in Kea? What I mean is that, in my environment, the DHCP and DHCPv6 servers just have to answer *always* the same IPv4 address and IPv6 address/prefix, based on Options 82 and 18, no matter of *who* (or what MAC/client-ID) is asking for it.
>>
> 
> Kea currently relies on client identifier and/or MAC address to identify
> the client. Some form of client identification is always required
> because the server has to determine whether the client sending a request
> to the server is a returning client or a new client. In the first case,
> the server returns existing (possibly extended) lease. In the second
> case, the server allocates a new lease. So, "disabling" lease checking
> is really not an option for the DHCP server.
> 
> What you seem to be looking for is a way to identify a client by some
> other value (or a collection of values) regardless of the client
> identifier and MAC address. Such identifier would need to be stored in
> the lease database apart from client id and MAC address and take
> precedence over the other two.
> 
> Unfortunately, we don't have such capability at the moment and adding
> generic support for this would require many code changes, i.e. changes
> in the address allocation engine and extending 3 database backends to
> facilitate this extra identifier. That's possible but we'd need some
> internal discussion about this first.
> 
> One possible shortcut for this is to create a hook library which would
> dynamically calculate such identifier (using data in the received
> packet) and replace client identifier value with it. The server would
> treat this computed value to identify leases in the database etc. When
> the response is ready, the hook library would need to replace this
> client identifier with an original client identifier (known to the client).
> 
> That may require some PoC but it should work just fine.
> 
> 
>> I ask this because If the client changes it's CPE device (changing MAC address), the DHCP won't provide any addresses until the lease expires. To workaround this I've configured low values to timers (about 10 min.), but this increases "the conversation" between clients and the servers.
> 
> Yes, lowering the lease lifetimes and timers is a good workaround for
> this. But, I agree there are tradeoffs.
> 
> 
> Marcin Siodelski
> ISC
> 