Peter,
thanks for the insight. it will take me a bit to get the env setup for
verbose logging, but will share the logs once they are generated.
regarding the reservations, are there best practices around global vs
subnet based reservations. i have read
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#global-reservations-in-dhcpv4,
and understand why the capability for both exist, but are there general
"rules of the road" around this subject? in cases where i classify, but
do not specify a reserved IP, i could see the global reservation being
appropriate. in cases where a reserved IP is assigned, what pros and
cons are there around where the reservation is defined? in my case, i
have <?include "/path/to/file.json?> call outs for many of the config
stanzas, to help organize the different capabilities of Kea, and thats
why i have all the reservations set globally. its based out of
convenience and clarity, but doesnt mean i'm right/wrong or following
best practices.
thanks for the help and effort,
brendan
On 4/17/24 5:49 AM, Peter Davies wrote:
Hi Brendan,
It is not possible to see any details from this logging.
You should check your haproxy configuration, Kea cannot continue
processing
requests if it is unable to connect to the lease database.
I suggest that you temporarily enable Severity DEBUG and debuglevel 99
so you
can see requests and how Kea is processing them.
As all your reservations are global, you should define
"reservations-global": true,"
the default is false.
All pools are guarded by client classes. The client may not be
associated with
any of these classes.
/Peter
--
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
