Re: [Kea-users] Kea 2.4.0 and duplicate host reservations not working as documented

2023-10-23 Thread Kevin P. Fleming 
On Mon, Oct 23, 2023, at 08:28, Veronique Lefebure wrote:
> Maybe https://gitlab.isc.org/isc-projects/kea/-/issues/2796 ?
 
> "naive" (dhcpd, microsoft style) conflict resolution (immediately reassign 
> lease to reserved host) (#2796) · Issues · ISC Open Source Projects / Kea · 
> GitLab 
> When resolving conflicts between active leases and host reservations, Kea 
> relies on the client with the active lease to cooperate. When lease times are 
> long, and the client...
> gitlab.isc.org

While that's not directly about 'duplicate reservations', the same logic would 
work for them I'll add a note to it. Thanks for the link!
-- 
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 2.4.0 and duplicate host reservations not working as documented

2023-10-23 Thread Veronique Lefebure 
Maybe https://gitlab.isc.org/isc-projects/kea/-/issues/2796 ?
[https://gitlab.isc.org/uploads/-/system/project/avatar/26/kea-logo-100x70.png]
"naive" (dhcpd, microsoft style) conflict resolution (immediately reassign 
lease to reserved host) (#2796) · Issues · ISC Open Source Projects / Kea · 
GitLab
When resolving conflicts between active leases and host reservations, Kea 
relies on the client with the active lease to cooperate. When lease times are 
long, and the client...
gitlab.isc.org


From: Kea-users  on behalf of Darren Ankney 

Sent: Sunday, October 22, 2023 8:38 PM
To: kea-users@lists.isc.org 
Subject: Re: [Kea-users] Kea 2.4.0 and duplicate host reservations not working 
as documented

Hi Kevin,

I thought there was already an open or closed issue about this, but I
didn't find one...

Thank you,

Darren Ankney

On Sun, Oct 22, 2023 at 10:32 AM Kevin P. Fleming
 wrote:
>
> On Sun, Oct 22, 2023, at 10:17, Darren Ankney wrote:
> > It then goes on to print details about the existing lease.  You could
> > possibly use the flex-id hook to overcome this (in certain situations
> > where there is something else to use as the identifier such as
> > circuit-id).  Alternatively, you could use the API to delete the lease
> > for 192.168.88.192 soon after granting so that it is free for your
> > other interface.  However, this could lead to strangeness should the
> > original interface try to renew (because the lease will no longer be
> > found and renewal will fail).  If it's possible, it would be best to
> > assign a separate address for each interface on the system.
>
> Thanks, at least I understand why this is happening now.
>
> I've tried other ways to address this on the client side (trying to use a 
> stable DUID or CID to have Kea think it's the same client regardless of 
> interface), but that doesn't seem to work out well either.
>
> The primary problem I'm solving here is that this client makes a lot of 
> outbound SSH connections to other machines on the network, and in order to 
> speed these up SSH persistent control channels are used. If the client 
> attempts to re-establish one of these connections after its IP address has 
> changed, SSH will just hang for quite a long time. Clearly the SSH client 
> could handle this better, but having a stable IP address is a more 
> straightforward fix.
>
> If there's no ticket open as a feature request for Kea to provide a method 
> for the existing leases to be ignored when a new REQUEST comes in, I'll 
> happily create one.
> --
> 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 2.4.0 and duplicate host reservations not working as documented

2023-10-22 Thread Darren Ankney 
Hi Kevin,

I thought there was already an open or closed issue about this, but I
didn't find one...

Thank you,

Darren Ankney

On Sun, Oct 22, 2023 at 10:32 AM Kevin P. Fleming
 wrote:
>
> On Sun, Oct 22, 2023, at 10:17, Darren Ankney wrote:
> > It then goes on to print details about the existing lease.  You could
> > possibly use the flex-id hook to overcome this (in certain situations
> > where there is something else to use as the identifier such as
> > circuit-id).  Alternatively, you could use the API to delete the lease
> > for 192.168.88.192 soon after granting so that it is free for your
> > other interface.  However, this could lead to strangeness should the
> > original interface try to renew (because the lease will no longer be
> > found and renewal will fail).  If it's possible, it would be best to
> > assign a separate address for each interface on the system.
>
> Thanks, at least I understand why this is happening now.
>
> I've tried other ways to address this on the client side (trying to use a 
> stable DUID or CID to have Kea think it's the same client regardless of 
> interface), but that doesn't seem to work out well either.
>
> The primary problem I'm solving here is that this client makes a lot of 
> outbound SSH connections to other machines on the network, and in order to 
> speed these up SSH persistent control channels are used. If the client 
> attempts to re-establish one of these connections after its IP address has 
> changed, SSH will just hang for quite a long time. Clearly the SSH client 
> could handle this better, but having a stable IP address is a more 
> straightforward fix.
>
> If there's no ticket open as a feature request for Kea to provide a method 
> for the existing leases to be ignored when a new REQUEST comes in, I'll 
> happily create one.
> --
> 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 2.4.0 and duplicate host reservations not working as documented

2023-10-22 Thread Kevin P. Fleming 
On Sun, Oct 22, 2023, at 10:17, Darren Ankney wrote:
> It then goes on to print details about the existing lease.  You could
> possibly use the flex-id hook to overcome this (in certain situations
> where there is something else to use as the identifier such as
> circuit-id).  Alternatively, you could use the API to delete the lease
> for 192.168.88.192 soon after granting so that it is free for your
> other interface.  However, this could lead to strangeness should the
> original interface try to renew (because the lease will no longer be
> found and renewal will fail).  If it's possible, it would be best to
> assign a separate address for each interface on the system.

Thanks, at least I understand why this is happening now.

I've tried other ways to address this on the client side (trying to use a 
stable DUID or CID to have Kea think it's the same client regardless of 
interface), but that doesn't seem to work out well either.

The primary problem I'm solving here is that this client makes a lot of 
outbound SSH connections to other machines on the network, and in order to 
speed these up SSH persistent control channels are used. If the client attempts 
to re-establish one of these connections after its IP address has changed, SSH 
will just hang for quite a long time. Clearly the SSH client could handle this 
better, but having a stable IP address is a more straightforward fix.

If there's no ticket open as a feature request for Kea to provide a method for 
the existing leases to be ignored when a new REQUEST comes in, I'll happily 
create one.
-- 
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 2.4.0 and duplicate host reservations not working as documented

2023-10-22 Thread Darren Ankney 
Hi Kevin,

The setting  "ip-reservations-unique": false, only ensures your config
will pass muster with multiple reservations for the same IP, it
guarantees nothing about the future allocation of the addresses.

This frequently comes up, as it does not behave in the same way that
it did in ISC DHCP.  In ISC DHCP, there was no lease recorded for
reservations made with the "fixed-address" keyword.  Therefore,
whatever client that was assigned the same address and came along and
asked for it, got it.  In Kea, this behavior has changed.  A lease is
always recorded for a leased IP address.  Therefore, what is happening
here is noted in the log is that the address can't be allocated as it
is already in use by your other interface:

"[hwtype=1 90:2e:16:d6:a4:1e],
cid=[00:81:74:fa:e6:94:98:99:8d:79:c0:a3:9c:87:27:72], tid=0x262eb546:
conflicting reservation for address 192.168.88.192 with existing lease
Address:   192.168.88.192"

It then goes on to print details about the existing lease.  You could
possibly use the flex-id hook to overcome this (in certain situations
where there is something else to use as the identifier such as
circuit-id).  Alternatively, you could use the API to delete the lease
for 192.168.88.192 soon after granting so that it is free for your
other interface.  However, this could lead to strangeness should the
original interface try to renew (because the lease will no longer be
found and renewal will fail).  If it's possible, it would be best to
assign a separate address for each interface on the system.

Thank you,

Darren Ankney

On Sun, Oct 22, 2023 at 8:43 AM Kevin P. Fleming
 wrote:
>
> I've got this in my config file for the DHCPv4 server (using Kea 2.4.0:
>
>   "Dhcp4": {
> "authoritative": true,
> "valid-lifetime": 86400,
> "reservations-global": false,
> "reservations-in-subnet": true,
> "reservations-out-of-pool": true,
> "ip-reservations-unique": false,
> ...
> "subnet4": [
>   {
> "id": 88,
> "subnet": "192.168.88.0/24",
> "pools": [
>   {
>   "pool": "192.168.88.64/26"
>   },
>   {
>   "pool": "192.168.88.128/26"
>   }
> ],
> "reservations": [
>   {
> "hw-address": "90:2e:16:d6:a4:1e",
> "ip-address": "192.168.88.192",
> "hostname":  "balrog22",
> "user-context": {
>   "name": "balrog22"
> }
>   },
>   {
> "hw-address": "a8:64:f1:30:88:0b",
> "ip-address": "192.168.88.192",
> "hostname":  "balrog22",
> "user-context": {
>   "name": "balrog22"
> }
>   },
> ...
>
> In theory this should result in my laptop getting the same IPv4 address 
> whether it is connected to the wired or wireless networks (which are the same 
> VLAN/subnet).
>
> However, I see this in the log:
>
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: WARN  
> ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 90:2e:16:d6:a4:1e], 
> cid=[00:81:74:fa:e6:94:98:99:8d:79:c0:a3:9c:87:27:72], tid=0x262eb546: 
> conflicting reservation for address 192.168.88.192 with existing lease 
> Address:   192.168.88.192
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: Valid life:86400
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: Cltt:  1697977751
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: Hardware addr: a8:64:f1:30:88:0b
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: Client id: 01:a8:64:f1:30:88:0b
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: Subnet ID: 88
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: Pool ID:   0
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: State: default
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: Relay ID:  (none)
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: Remote ID: (none)
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: INFO  DHCP4_LEASE_ADVERT [hwtype=1 
> 90:2e:16:d6:a4:1e], cid=[00:81:74:fa:e6:94:98:99:8d:79:c0:a3:9c:87:27:72], 
> tid=0x262eb546: lease 192.168.88.64 will be advertised
> Oct 22 08:29:55 core23-a kea-dhcp4[1650]: INFO  DHCP4_LEASE_ALLOC [hwtype=1 
> 90:2e:16:d6:a4:1e], cid=[00:81:74:fa:e6:94:98:99:8d:79:c0:a3:9c:87:27:72], 
> tid=0x262eb546: lease 192.168.88.64 has been allocated for 86400 seconds
>
> I'm running in the default multithreaded mode, so 'reservations-lookup-first' 
> should be enabled (its default).
>
> I must be missing something, as I believe I'm doing exactly what the ARM says 
> I should do to have multiple reservations for the same IP address, but it's 
> not working.
>
> --
> 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