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

[Marcin Siodelski]

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