Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
Hi again, Since a few people have expressed interest in this feature, I opened an issue about it at https://gitlab.isc.org/isc-projects/kea/-/issues/2796 Tobi -- 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
Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
Veronique Lefebure wrote: > The problem is new in the sense that we did not have that "problem" when > using ISC DHCP since it would not check for the existing leases in case of > static IP host-reservation. Indeed, and it is documented that static host declarations didn’t follow the normal lease lifecycle. AIUI, reservations in Kea are more akin to leases marked reserved with dhcpd - where the problem would be found. Simon -- 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
Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
That's basically the same situation we are in. It would be awesome if there was a configuration option in Kea to tell the server that it should immediately expire a lease if there is a request for a static reservation that conflicts with an existing lease. But maybe there are issues with that that I am not thinking about. --Dan On Mon, Jan 30, 2023 at 3:55 AM GIRSTMAIR Tobias via Kea-users < kea-users@lists.isc.org> wrote: > On Fri, 2023-01-27 at 19:58 +, Simon wrote: > > I assume it doesn’t scale in terms of having multiple hell desk > > operators having to do manual steps - in which case, the answer is to > > build a tool into your management toolset allowing them to “click > > here to remove the lease” when they are altering the reservation > > details. > > The problem for us is that we manage reservations through a central > MySQL database (through a fancy UI for our hell desk), but leases are > stored in memfiles on each DHCP server (8 HA setups for 16 total). So > our tooling doesn't directly connect to the dhcp servers (and doesn't > even know which dhcp server a reservation 'belongs' to). > > If there is no other way, we'll have to rework our tooling to find out > where to send this API call to (and punch some holes into the > firewalls). Not the end of the world, but this seems to be a feature > more people could benefit from. > > tobi > -- > 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
Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
+1 From: Kea-users on behalf of GIRSTMAIR Tobias via Kea-users Sent: Monday, January 30, 2023 10:54 AM To: dh...@thehobsons.co.uk ; kea-users@lists.isc.org Subject: Re: [Kea-users] DHCPv4 Conflict resolution on MAC change On Fri, 2023-01-27 at 19:58 +, Simon wrote: > I assume it doesn’t scale in terms of having multiple hell desk > operators having to do manual steps - in which case, the answer is to > build a tool into your management toolset allowing them to “click > here to remove the lease” when they are altering the reservation > details. The problem for us is that we manage reservations through a central MySQL database (through a fancy UI for our hell desk), but leases are stored in memfiles on each DHCP server (8 HA setups for 16 total). So our tooling doesn't directly connect to the dhcp servers (and doesn't even know which dhcp server a reservation 'belongs' to). If there is no other way, we'll have to rework our tooling to find out where to send this API call to (and punch some holes into the firewalls). Not the end of the world, but this seems to be a feature more people could benefit from. tobi -- 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
Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
Hi Simon, The problem is new in the sense that we did not have that "problem" when using ISC DHCP since it would not check for the existing leases in case of static IP host-reservation. Cheers, Veronique From: Kea-users on behalf of Simon Sent: Friday, January 27, 2023 8:58 PM Your problem isn’t new - it’s somewhat fundamental to complying with the RFCs. You will need to remove any existing lease for the IP before the IP can be allocated to another client. I assume it doesn’t scale in terms of having multiple hell desk operators having to do manual steps - in which case, the answer is to build a tool into your management toolset allowing them to “click here to remove the lease” when they are altering the reservation details. Simon -- 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
Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
On Fri, 2023-01-27 at 19:58 +, Simon wrote: > I assume it doesn’t scale in terms of having multiple hell desk > operators having to do manual steps - in which case, the answer is to > build a tool into your management toolset allowing them to “click > here to remove the lease” when they are altering the reservation > details. The problem for us is that we manage reservations through a central MySQL database (through a fancy UI for our hell desk), but leases are stored in memfiles on each DHCP server (8 HA setups for 16 total). So our tooling doesn't directly connect to the dhcp servers (and doesn't even know which dhcp server a reservation 'belongs' to). If there is no other way, we'll have to rework our tooling to find out where to send this API call to (and punch some holes into the firewalls). Not the end of the world, but this seems to be a feature more people could benefit from. tobi -- 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
Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
On Fri, Jan 27, 2023, at 14:58, Simon wrote: > GIRSTMAIR Tobias via Kea-users wrote: > >> As a workaround, an operator could manually delete the lease with kea- >> shell (or its underlying api), but that does not scale to our size. > > In what way doesn’t size ? > > Your problem isn’t new - it’s somewhat fundamental to complying with > the RFCs. You will need to remove any existing lease for the IP before > the IP can be allocated to another client. > I assume it doesn’t scale in terms of having multiple hell desk > operators having to do manual steps - in which case, the answer is to > build a tool into your management toolset allowing them to “click here > to remove the lease” when they are altering the reservation details. If the OP *really* wanted to, they could probably write a Kea plugin which: * Notices the configuration has been reloaded. * Compares all of the host reservations in the configuration against the currently-known leases. * Removes any leases for reserved addresses where the MAC address in the lease is not the MAC address in the reservation. -- 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
Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
GIRSTMAIR Tobias via Kea-users wrote: > As a workaround, an operator could manually delete the lease with kea- > shell (or its underlying api), but that does not scale to our size. In what way doesn’t size ? Your problem isn’t new - it’s somewhat fundamental to complying with the RFCs. You will need to remove any existing lease for the IP before the IP can be allocated to another client. I assume it doesn’t scale in terms of having multiple hell desk operators having to do manual steps - in which case, the answer is to build a tool into your management toolset allowing them to “click here to remove the lease” when they are altering the reservation details. Simon -- 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
Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
We have run into the same issue when replacing hardware. Luckily for us our lease times are in the range of a few hours instead of days, but it would still be nice to have a better solution for this. -- Dan Oachs On Fri, Jan 27, 2023 at 7:27 AM Veronique Lefebure < veronique.lefeb...@cern.ch> wrote: > We would have the same use-case as you, Tobi, and I guess we would not be > the only ones ? > The problem is also mentioned on > https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=replace-client-id#the-replace-client-id-flag > by > the way. > > On > https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?#conflicts-in-dhcpv4-reservations > doc > says > "The best way to avoid such a recovery is not to define new reservations > that conflict with existing leases. Another recommendation is to use > out-of-pool reservations; if the reserved address does not belong to a > pool, there is no way that other clients can get it." > > But indeed, even with out-of-pool reservations, the hardware replacement > use-case is not going to work :-/ > > -- > *From:* Kea-users on behalf of > GIRSTMAIR Tobias via Kea-users > *Sent:* Friday, January 27, 2023 1:07 PM > *To:* kea-users@lists.isc.org > *Subject:* [Kea-users] DHCPv4 Conflict resolution on MAC change > > Hi all, > > We recently migrated to Kea 2.2.0 and now ran into the following > situation: > > Initially: > - Leases are valid for a long time (11 days, per customer requirement) > - There is a host reservation for and > - The device with got a lease for > > Now, the hardware is replaced and the reservation is updated, so the > new device gets the same IP: > - remove reservation for and > - add reservation for and > - the old device is unplugged, and therefore cannot release its lease > - the new device is plugged in and requests a lease > > Now, Kea looks for the host reservation for and notices that > is still leased to , so it refuses to reassign this IP. > This looks like this in the log: > > 2023-01-26 08:43:18.065 WARN [kea-dhcp4.alloc- > engine/1409.139836331153152] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT > [hwtype=1 00:15:bc:28:2b:0c], cid=[01:00:15:bc:28:2b:0c], > tid=0xaf01221b: conflicting reservation for address 10.58.166.192 with > existing lease Address: 10.58.166.192 > Valid life:950400 > Cltt: 1674552388 > Hardware addr: 00:15:bc:28:09:e7 > Client id: 01:00:15:bc:28:09:e7 > Subnet ID: 5164 > State: default > > I read through section 8.3.2 of the documentation, and the conflict > resolution protocol used seems to not handle our case here (where the > old device doesn't release its lease). It expects the old device with > to renew its lease, before responding with DHCPNAK and > reallocating to . > > As a workaround, an operator could manually delete the lease with kea- > shell (or its underlying api), but that does not scale to our size. > > The documentation describes that "A naive approach would to be > immediately remove the existing lease for Host A and create a new one > for Host B" -- this would be exactly what we want, and what our > previous setup did. Our reservations are out-of-pool, and we can be > certain that when the MAC of a reservation changes, the old device will > not be online any longer. Is there a way to achieve this? > > Thanks, > > Tobi > -- > 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 > -- 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
Re: [Kea-users] DHCPv4 Conflict resolution on MAC change
We would have the same use-case as you, Tobi, and I guess we would not be the only ones ? The problem is also mentioned on https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=replace-client-id#the-replace-client-id-flag by the way. On https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?#conflicts-in-dhcpv4-reservations doc says "The best way to avoid such a recovery is not to define new reservations that conflict with existing leases. Another recommendation is to use out-of-pool reservations; if the reserved address does not belong to a pool, there is no way that other clients can get it." But indeed, even with out-of-pool reservations, the hardware replacement use-case is not going to work :-/ From: Kea-users on behalf of GIRSTMAIR Tobias via Kea-users Sent: Friday, January 27, 2023 1:07 PM To: kea-users@lists.isc.org Subject: [Kea-users] DHCPv4 Conflict resolution on MAC change Hi all, We recently migrated to Kea 2.2.0 and now ran into the following situation: Initially: - Leases are valid for a long time (11 days, per customer requirement) - There is a host reservation for and - The device with got a lease for Now, the hardware is replaced and the reservation is updated, so the new device gets the same IP: - remove reservation for and - add reservation for and - the old device is unplugged, and therefore cannot release its lease - the new device is plugged in and requests a lease Now, Kea looks for the host reservation for and notices that is still leased to , so it refuses to reassign this IP. This looks like this in the log: 2023-01-26 08:43:18.065 WARN [kea-dhcp4.alloc- engine/1409.139836331153152] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 00:15:bc:28:2b:0c], cid=[01:00:15:bc:28:2b:0c], tid=0xaf01221b: conflicting reservation for address 10.58.166.192 with existing lease Address: 10.58.166.192 Valid life:950400 Cltt: 1674552388 Hardware addr: 00:15:bc:28:09:e7 Client id: 01:00:15:bc:28:09:e7 Subnet ID: 5164 State: default I read through section 8.3.2 of the documentation, and the conflict resolution protocol used seems to not handle our case here (where the old device doesn't release its lease). It expects the old device with to renew its lease, before responding with DHCPNAK and reallocating to . As a workaround, an operator could manually delete the lease with kea- shell (or its underlying api), but that does not scale to our size. The documentation describes that "A naive approach would to be immediately remove the existing lease for Host A and create a new one for Host B" -- this would be exactly what we want, and what our previous setup did. Our reservations are out-of-pool, and we can be certain that when the MAC of a reservation changes, the old device will not be online any longer. Is there a way to achieve this? Thanks, Tobi -- 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
