On Wed, Nov 10, 2021 at 9:18 AM Johannes Midgren <[email protected]> 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 < > [email protected]>: > >> 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 <[email protected]> * För * >> [email protected] >> *Skickat:* den 10 november 2021 14:52 >> *Till:* Johannes Midgren <[email protected]>; [email protected] >> *Ämne:* Re: [Kea-users] Lease affinity of released leases >> >> >> >> Maybe a host reservation is a solution? >> >> >> >> *From:* Kea-users <[email protected]> *On Behalf Of *Johannes >> Midgren >> *Sent:* Wednesday, 10 November 2021 15:47 >> *To:* [email protected] >> *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
_______________________________________________ ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
