Re: [Kea-users] Kea-users Digest, Vol 112, Issue 24
I apologize in advance as I know this is probably not the ideal way to
respond to answers to questions someone receives in the Digest.
Message: 2
Date: Sat, 21 Oct 2023 14:09:40 -0400
From: Darren Ankney
To: kea-users@lists.isc.org
Subject: Re: [Kea-users] Migration Questions
Message-ID:
Content-Type: text/plain; charset="UTF-8
Hi,
> Does the Kea Lease Migration support ISC DHCP Failover Lease Files?
The only difference between a non-failover lease file and failover
lease file in ISC DHCP, AFAIK, was that there were some extra entries
about peers and status. I don't think there was anything in the
actual leases themselves, so I imagine the answer would be yes.
— Going to test this out soon and see what the migration tool does.
>
> I might have overlooked this in the document for the Lease Migration.
Would it be possible to upload the output of the Kea Lease Migration to
MySQL Database Backend when Kea is configured to store Leases in a database
rather than memfile? Or is the output intended to be used in the memfile?
I don't think the migration assistant itself is capable of that, but
the kea-admin tool can transport leases between memfile csv format and
database (postgres or mysql):
https://kea.readthedocs.io/en/kea-2.4.0/arm/admin.html#the-kea-admin-tool
— Thanks for pointing me in the right direction on this. There is a lot of
things to learn about Kea and how it works. ISC DHCP was simple but we
learned it and lives with it for many many years, so it is nice to see the
amount of work put into Kea and how things have evolved.
>
> Also, I used the Kea Lease Migration and the converted lease file shows
all the leases just fine. I followed the example to load the output csv
file into Kea DHCP4 and when I test the configuration file everything shows
to be fine. However, when I go to start the Kea DHCP4 Service, I get the
error "unable to open database: unable to open "filename" regardless if the
csv file is in the /etc/kea directory or the /var/lib/kea/ directory.
>
> Here is the lease database configuration snippet with the lease file in
the /etc/kea directory -
>
> "sanity-checks": {
> "lease-checks": "fix-del"
> },
> "lease-database": {
> // Memfile is the simplest and easiest backend to use. It's an
in-memory
> // C++ database that stores its state in CSV file.
> "type": "memfile",
> "persist": true,
> "name": "/etc/kea/dhcpd-leases-kea.csv",
> "lfc-interval": 3600
> },
Perhaps there is a permission issue? Depending how you installed, Kea
may be running as an unprivileged user (such as _kea) who may not have
access to the .csv file to read on startup.
Thank you,
Darren Ankney
— Darren, you were correct on this. However, you won’t figure the
permissions issue out on CentOS 7. I spent at least a day trying to figure
this out as well as several other issues and/or possibly bugs on CentOS 7
and then finally created an Ubuntu 20.04 VM and started trying to use Kea
on Ubuntu like I was attempting to do on CentOS. Now we are working and I
have a lot more questions to ask the mailing list
Thanks,
JTISC
On Sat, Oct 21, 2023 at 1:29 PM wrote:
> Send Kea-users mailing list submissions to
> kea-users@lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/kea-users
> or, via email, send a message with subject or body 'help' to
> kea-users-requ...@lists.isc.org
>
> You can reach the person managing the list at
> kea-users-ow...@lists.isc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kea-users digest..."
>
>
> Today's Topics:
>
>1. Re: DDNS limitations - ddns-qualifying-suffix vs domain-name
> (Darren Ankney)
>2. Re: Migration Questions (Darren Ankney)
>3. Re: Issue installing Kea DHCP4 on Ubuntu 22 with Postgresql
> 16 (Darren Ankney)
>4. Re: dhcp | KEA DHCPv6 server not assigning ip addresses to
> clients (Darren Ankney)
>
>
> --
>
> Message: 1
> Date: Sat, 21 Oct 2023 13:54:27 -0400
> From: Darren Ankney
> To: Vladimir Nikoli?
> Cc: Kea-users@lists.isc.org
> Subject: Re: [Kea-users] DDNS limitations - ddns-qualifying-suffix vs
> domain-name
> Message-ID:
> rspsgdx2jsmruagmzttzmitr8wfcjzanr...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Vladimir,
>
> You can set it "ddns-qualifying-suffix": "", which resets it to empty
> in the block in which you do that. You could also only specify inside
> subnets where you need it specified and not specify at global level.
> There would have to be some way to flag hostnames that you wanted to
> ignore a ddns-qualifying-suffix setting somehow to have it
> simultaneously set to some value and not apply to all hostnames in
> that block.
>
> Thank you,
>
> Darren Ankney
>
> On Tue, Oct
Re: [Kea-users] DDNS limitations - ddns-qualifying-suffix vs domain-name
Hi Vladimir, I thought about that, but that wouldn't necessarily work. Without looking up the provided hostname, Kea wouldn't understand if it should add the suffix or not (i.e., is it a complete name?) For example: - suffix could be 'example.org' - 'example.org' might have sub domains such as 'office.example.org' and 'warehouse.example.org' - so there may be hostnames like 'laptop1.office' and 'laptop2.warehouse' that would need example.org appended to them. Kea couldn't know this isn't the case without some other flag or some very complex (very slow) lookup logic to try to figure out what the administrator intends to happen. Thank you, Darren Ankney On Sun, Oct 22, 2023 at 10:33 AM Vladimir Nikolic wrote: > > Hi Darren, > > > There would have to be some way to flag hostnames that you wanted to > > ignore a ddns-qualifying-suffix setting somehow to have it > > simultaneously set to some value and not apply to all hostnames in > > that block. > > Yeah, like if you end "hostname" parameter (within a host reservation) > with a ".", then KEA should treat it as a FQDN, and not append > "ddns-qualifying-suffix" from the subnet definition. > > Regards, > Vladimir > > On 2023-10-21 18:54, Darren Ankney wrote: > > Hi Vladimir, > > > > You can set it "ddns-qualifying-suffix": "", which resets it to empty > > in the block in which you do that. You could also only specify inside > > subnets where you need it specified and not specify at global level. > > There would have to be some way to flag hostnames that you wanted to > > ignore a ddns-qualifying-suffix setting somehow to have it > > simultaneously set to some value and not apply to all hostnames in > > that block. > > > > Thank you, > > > > Darren Ankney > > > > On Tue, Oct 17, 2023 at 2:50 AM Vladimir Nikolić > > wrote: > >> > >> Thanks Darren. > >> > >> If ‘ddns-qualifying-subnet’ is being set on any level, it’s then > >> appended to the ‘hostname’ value from the host reservation. ‘hostname’ > >> is the FQDN, only if ‘ddns-qualifying-subnet’ is empty. > >> So it’s either one or another. > >> Which is really inflexible. > >> > >> Regards > >> > >> > >> > On 17 Oct 2023, at 12:26 am, Darren Ankney > >> > wrote: > >> > > >> > Hi Vladimir, > >> > > >> > The DHCPv4 domain-name option (15) isn't meant for use with ddns. It > >> > is a search domain that the client should use when performing name > >> > resolution. See: https://www.rfc-editor.org/rfc/rfc2132#section-3.17 > >> > > >> > You can set ddns-qualifying-suffix at the global, shared-network and > >> > subnet level. In a host reservation, you can use the "hostname" > >> > parameter to specify a FQDN to send to the client and for use in DDNS. > >> > See here: > >> > https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#reserving-a-hostname > >> > > >> >> On Mon, Oct 16, 2023 at 3:23 PM Vladimir Nikolic via Kea-users > >> >> wrote: > >> >> > >> >> Hi, > >> >> > >> >> While trying to migrate DHCP service from ISC DHCP to ISC KEA, we are > >> >> hitting following KEA limitations: > >> >> > >> >> - option domain-name has no part in DDNS names construction, it's only > >> >> ddns-qualifying-suffix that's being honoured > >> >> - ddns-qualifying-suffix can't be specified in the class definition (we > >> >> have dedicated zone for our OOB devices) > >> >> - there can be only one DDNS zone for all the clients in a subnet > >> >> (ddns-qualifying-suffix), with ISC DHCP you can have one default > >> >> domain-name for a subnet and every single host reservation with a > >> >> different domain-name (DDNS zone) > >> >> > >> >> Regards, > >> >> Vladimir > >> >> -- > >> >> 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
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] DDNS limitations - ddns-qualifying-suffix vs domain-name
Hi Darren, There would have to be some way to flag hostnames that you wanted to ignore a ddns-qualifying-suffix setting somehow to have it simultaneously set to some value and not apply to all hostnames in that block. Yeah, like if you end "hostname" parameter (within a host reservation) with a ".", then KEA should treat it as a FQDN, and not append "ddns-qualifying-suffix" from the subnet definition. Regards, Vladimir On 2023-10-21 18:54, Darren Ankney wrote: Hi Vladimir, You can set it "ddns-qualifying-suffix": "", which resets it to empty in the block in which you do that. You could also only specify inside subnets where you need it specified and not specify at global level. There would have to be some way to flag hostnames that you wanted to ignore a ddns-qualifying-suffix setting somehow to have it simultaneously set to some value and not apply to all hostnames in that block. Thank you, Darren Ankney On Tue, Oct 17, 2023 at 2:50 AM Vladimir Nikolić wrote: Thanks Darren. If ‘ddns-qualifying-subnet’ is being set on any level, it’s then appended to the ‘hostname’ value from the host reservation. ‘hostname’ is the FQDN, only if ‘ddns-qualifying-subnet’ is empty. So it’s either one or another. Which is really inflexible. Regards > On 17 Oct 2023, at 12:26 am, Darren Ankney wrote: > > Hi Vladimir, > > The DHCPv4 domain-name option (15) isn't meant for use with ddns. It > is a search domain that the client should use when performing name > resolution. See: https://www.rfc-editor.org/rfc/rfc2132#section-3.17 > > You can set ddns-qualifying-suffix at the global, shared-network and > subnet level. In a host reservation, you can use the "hostname" > parameter to specify a FQDN to send to the client and for use in DDNS. > See here: https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#reserving-a-hostname > >> On Mon, Oct 16, 2023 at 3:23 PM Vladimir Nikolic via Kea-users >> wrote: >> >> Hi, >> >> While trying to migrate DHCP service from ISC DHCP to ISC KEA, we are >> hitting following KEA limitations: >> >> - option domain-name has no part in DDNS names construction, it's only >> ddns-qualifying-suffix that's being honoured >> - ddns-qualifying-suffix can't be specified in the class definition (we >> have dedicated zone for our OOB devices) >> - there can be only one DDNS zone for all the clients in a subnet >> (ddns-qualifying-suffix), with ISC DHCP you can have one default >> domain-name for a subnet and every single host reservation with a >> different domain-name (DDNS zone) >> >> Regards, >> Vladimir >> -- >> 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
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
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
[Kea-users] Kea 2.4.0 and duplicate host reservations not working as documented
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
