[Kea-users] Lease affinity of released leases

Bob Harold rharolde at umich.edu
Wed Nov 10 14:38:52 UTC 2021


On Wed, Nov 10, 2021 at 9:18 AM Johannes Midgren <johannes at midgren.net>
wrote:

> Thanks a lot, Mattias!
>
> That does answer my question. I guess for now I will have to mitigate the
> issue in any of the ways I listed in the original post, and when I get the
> time I might very well write a hook. It's about time I take up my C++
> skills :-)
>
> Den ons 10 nov. 2021 kl 15:05 skrev Mattias Johansson <
> Mattias.Johansson at varnamoenergi.se>:
>
>> Hi,
>>
>>
>>
>> I found this
>>
>>
>>
>> [Kea-users] Enable lease affinity with MySQL backend (isc.org)
>> <https://lists.isc.org/pipermail/kea-users/2018-September/001997.html>
>>
>>
>>
>> ”Kea has a built in support for keeping an expired lease around for a
>>
>> configurable amount of time, which is driven by
>>
>> "expired-leases-processing" parameters described in the Kea User's
>>
>> Guide. In other words, if the lease expires (client does not renew the
>>
>> lease), the server won't remove this lease from the database
>>
>> immediately, but will rather wait a configured amount of time before it
>>
>> removes it. This doesn't preclude other clients from getting the lease
>>
>> if they request it, but in most cases the expired lease will simply be
>>
>> re-assigned to the client who had been using it before.
>>
>>
>>
>> Having said that, this doesn't work for cases when the client sends a
>>
>> Release to indicate that it stops using the lease. In such cases, the
>>
>> lease is removed from the database upon receiving the Release. There are
>>
>> no configuration knobs to keep the lease in the database for the client
>>
>> after the client releases the lease.
>>
>>
>>
>> The only possibility I see to address your use case at the moment is to
>>
>> write a simple hooks library which drops the received Release packets.
>>
>> The server won't process them and the leases will be left to expire in
>>
>> the database. When the client reboots it should get the same lease. That
>>
>> involves C++ coding though.”
>>
>>
>>
>>
>>
>> sounds like what you’re experiencing.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Från:* Kea-users <kea-users-bounces at lists.isc.org> * För *
>> egor.grijuc at orange.com
>> *Skickat:* den 10 november 2021 14:52
>> *Till:* Johannes Midgren <johannes at midgren.net>; kea-users at lists.isc.org
>> *Ämne:* Re: [Kea-users] Lease affinity of released leases
>>
>>
>>
>> Maybe a host reservation is a solution?
>>
>>
>>
>> *From:* Kea-users <kea-users-bounces at lists.isc.org> *On Behalf Of *Johannes
>> Midgren
>> *Sent:* Wednesday, 10 November 2021 15:47
>> *To:* kea-users at lists.isc.org
>> *Subject:* [Kea-users] Lease affinity of released leases
>>
>>
>>
>> TLDR: How do I make KEA offer the same IP to a host that is rebooted and
>> that releases its IP address while shutting down?
>>
>>
>>
>> I have recently started to use KEA on my home network. I love the fact
>> that I can control its configuration through Ansible and all the
>> possibilities the REST API gives, so I'm very glad that I found the project!
>>
>>
>>
>> One thing that I still have not been able to get the way I prefer it
>> though, is to have lease affinity in all cases. That is, I would like for a
>> client to always get the same IP address when it reconnects (as long as
>> it's still available of course). I have read the chapter about Lease
>> Expiration (and Affinity) in the manual and I'm not sure the case I'm
>> looking for is covered. The manual talks about expired leases, but I would
>> like to have affinity also in the case that the lease has been released
>> rather than expired. Using a packet sniffer I can see that clients tend to
>> properly release the DHCP lease when being rebooted and when it gets online
>> again it does a DHCP Discover and is offered a new IP address by the KEA
>> DHCP4 server.
>>
>>
>>
>> Does anyone know if KEA is supposed to (or rather can be made to) work
>> the way I intend it to or if lease affinity by design is only supposed to
>> work for expired, thus not released, leases? (Or maybe something is wrong
>> with my setup and this should actually work?)
>>
>>
>>
>> The problem I have is that cached DNS entries make hosts unavailable for
>> some time after they are restarted - they are "sought for" by their old IP.
>> I guess I can mitigate the issue by setting a very low TTL in my DNS
>> configuration, but I would prefer to let KEA hold leases for a long time
>> and reuse them instead. Another way would of course be to make reservations
>> for all hosts where this matters, but that prevents the automation that I
>> try to use KEA for.
>>
>>
>>
>> I have been playing with the expired-leases-processing configuration for
>> the DHCP4 server, and I currently have this:
>>
>>
>>
>>        "expired-leases-processing": {
>>            "flush-reclaimed-timer-wait-time": 300,
>>            "hold-reclaimed-time": 604800,
>>            "max-reclaim-leases": 100,
>>            "max-reclaim-time": 250,
>>            "reclaim-timer-wait-time": 180,
>>            "unwarned-reclaim-cycles": 5
>>        },
>>
>> I'm running KEA 1.8 (installed from CloudSmith repos) on CentOS Stream 8.
>> I use the memfile lease-database, have DHCP-DDNS setup and I use the HA
>> hook (with one primary, one standby and one backup host).
>>
>> _________________________________________________________________________________________________________________________
>>
>>
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>>
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>
>> they should not be distributed, used or copied without authorisation.
>>
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>
>> Thank you.
>>
>>
>
You might want to see if there is any option on the client to tell it not
to "release" when shutting down.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20211110/211deda2/attachment.htm>


More information about the Kea-users mailing list