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.johans...@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-boun...@lists.isc.org> * För * > egor.gri...@orange.com > *Skickat:* den 10 november 2021 14:52 > *Till:* Johannes Midgren <johan...@midgren.net>; kea-users@lists.isc.org > *Ämne:* Re: [Kea-users] Lease affinity of released leases > > > > Maybe a host reservation is a solution? > > > > *From:* Kea-users <kea-users-boun...@lists.isc.org> *On Behalf Of *Johannes > Midgren > *Sent:* Wednesday, 10 November 2021 15:47 > *To:* kea-users@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. > > _______________________________________________ > 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 > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users >
_______________________________________________ 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 Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users