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] Kea HA Heartbeat Failure
Hello Dulux-Oz, Not sure if you’re using hot-standby or load-balancing (or passive backup) HA, but the HA hook chapter 16 for config section of each mode does have some sample configs and describes the use of basic-auth-user and basic-auth-password (or alternative basic-auth-password-file should you wish to store password outside of your config file). https://kea.readthedocs.io/en/kea-2.2.0/arm/hooks.html?highlight=basic-auth-password#hot-standby-configuration or https://kea.readthedocs.io/en/kea-2.2.0/arm/hooks.html?highlight=basic-auth-password#load-balancing-configuration From: Kea-users on behalf of duluxoz Date: Friday, January 27, 2023 at 2:32 AM To: Veronique Lefebure , kea-users@lists.isc.org Subject: Re: [Kea-users] Kea HA Heartbeat Failure CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Veronique, Thanks for that - that's what we were missing: the auth info inside the peers block. A note to the Kea Document Maintainers: I do not recall *ever* reading *anywhere* in the doco or sample config files where the basic-auth-user and basic-auth-password need to be included in the ha->peers block. Of course, I may have missed it, but still, it may behove you to make something like this much more predominant in the documentation *and* sample config files. Thanks to everyone who helped us out in this - we really appreciate it Cheers Dulux-Oz On 27/01/2023 18:49, Veronique Lefebure wrote: We have this in the kea-ctrl-agent config and it works fine: "authentication": { "type": "basic", "realm": "kea-control-agent", "clients": [ { "user": "x", "password": "" } ] } and in kea-dhcp4.conf: "parameters": { "high-availability": [ { ... "peers": [ { "auto-failover": true, "basic-auth-password": "", "basic-auth-user": "", "name": "kea1.example.com", "role": "primary", "url": "http://xx.xxx.xx.xx:90xx/; }, ... Sensitivity: Internal -- 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
[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
Re: [Kea-users] Kea HA Heartbeat Failure
Hi Veronique, Thanks for that - that's what we were missing: the auth info inside the peers block. A note to the Kea Document Maintainers: I do not recall *ever* reading *anywhere* in the doco or sample config files where the basic-auth-user and basic-auth-password need to be included in the ha->peers block. Of course, I may have missed it, but still, it may behove you to make something like this much more predominant in the documentation *and* sample config files. Thanks to everyone who helped us out in this - we really appreciate it Cheers Dulux-Oz On 27/01/2023 18:49, Veronique Lefebure wrote: We have this in the kea-ctrl-agent config and it works fine: "authentication": { "type": "basic", "realm": "kea-control-agent", "clients": [ { "user": "x", "password": "" } ] } and in kea-dhcp4.conf: "parameters": { "high-availability": [ { ... "peers": [ { "auto-failover": true, "basic-auth-password": "", "basic-auth-user": "", "name": "kea1.example.com", "role": "primary", "url": "http://xx.xxx.xx.xx:90xx/; }, ... -- 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