# Copyright (C) 2017-2025 Internet Systems Consortium, Inc. ("ISC")
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.

$NAMESPACE isc::ha

% HA_BUFFER4_RECEIVE_FAILED buffer4_receive callout failed: %1
This error message is issued when the callout for the buffer4_receive hook
point failed.  This may occur as a result of an internal server error.
The argument contains a reason for the error.

% HA_BUFFER4_RECEIVE_NOT_FOR_US %1: dropping query to be processed by another server
Logged at debug log level 40.
This debug message is issued when the received DHCPv4 query is dropped
by this server because it should be served by another server. This
is the case when the remote server was designated to process the packet
as a result of load balancing or because it is a primary server in the
hot standby configuration. The argument provides client identification
information retrieved from the query.

% HA_BUFFER4_RECEIVE_PACKET_OPTIONS_SKIPPED an error unpacking an option, caused subsequent options to be skipped: %1
Logged at debug log level 40.
A debug message issued when an option failed to unpack correctly, making it
impossible to unpack the remaining options in the DHCPv4 query. The server
will still attempt to service the packet. The sole argument provides a
reason for unpacking error.

% HA_BUFFER4_RECEIVE_UNPACK_FAILED failed to parse query from %1 to %2, received over interface %3, reason: %4
Logged at debug log level 40.
This debug message is issued when received DHCPv4 query is malformed and
can't be parsed by the buffer4_receive callout. The query will be
dropped by the server. The first three arguments specify source IP address,
destination IP address and the interface. The last argument provides a
reason for failure.

% HA_BUFFER6_RECEIVE_FAILED buffer6_receive callout failed: %1
This error message is issued when the callout for the buffer6_receive hook
point failed. This may occur as a result of an internal server error.
The argument contains a reason for the error.

% HA_BUFFER6_RECEIVE_NOT_FOR_US %1: dropping query to be processed by another server
Logged at debug log level 40.
This debug message is issued when the received DHCPv6 query is dropped
by this server because it should be served by another server. This
is the case when the remote server was designated to process the packet
as a result of load balancing or because it is a primary server in the
hot standby configuration. The argument provides client identification
information retrieved from the query.

% HA_BUFFER6_RECEIVE_PACKET_OPTIONS_SKIPPED an error unpacking an option, caused subsequent options to be skipped: %1
Logged at debug log level 40.
A debug message issued when an option failed to unpack correctly, making it
impossible to unpack the remaining options in the DHCPv6 query. The server
will still attempt to service the packet. The sole argument provides a
reason for unpacking error.

% HA_BUFFER6_RECEIVE_UNPACK_FAILED failed to parse query from %1 to %2, received over interface %3, reason: %4
Logged at debug log level 40.
This debug message is issued when received DHCPv6 query is malformed and
can't be parsed by the buffer6_receive callout. The query will be
dropped by the server. The first three arguments specify source IP address,
destination IP address and the interface. The last argument provides a
reason for failure.

% HA_COMMAND_PROCESSED_FAILED command_processed callout failed: %1
This error message is issued when the callout for the command_processed hook
point failed. The argument contains a reason for the error.

% HA_COMMUNICATION_INTERRUPTED %1: communication with %2 is interrupted
This warning message is issued by the server which discovered that the
communication to the active partner has been interrupted for a time
period longer than the configured heartbeat-delay time. At this stage
the server starts the failover procedure by monitoring the DHCP traffic
sent to the partner and checking whether the partner server responds to
this traffic. If the max-unacked-clients value is set to 0 such
verification is disabled in which case the server will transition to
the partner-down state.

% HA_COMMUNICATION_INTERRUPTED_CLIENT4 %1: new client %2 attempting to get a lease from the partner
This informational message is issued when the surviving server observes
a DHCP packet sent to the partner with which the communication is interrupted.
The client whose packet is observed is not yet considered "unacked" because
the secs field value does not exceed the configured threshold specified
with max-ack-delay.

% HA_COMMUNICATION_INTERRUPTED_CLIENT4_UNACKED %1: partner server failed to respond to %2, %3 clients unacked so far, %4 clients left before transitioning to the partner-down state
This informational message is issued when the surviving server determines
that its partner failed to respond to the DHCP query and that this client
is considered to not be served by the partner. The surviving server counts
such clients and if the number of such clients exceeds the max-unacked-clients
threshold, the server will transition to the partner-down state. The first
argument specifies the relationship name. The second argument contains client
identification information. The third argument specifies the number of
clients to which the server has failed to respond. The forth argument specifies
the number of additional clients which, if not provisioned, will cause the
server to transition to the partner-down state.

% HA_COMMUNICATION_INTERRUPTED_CLIENT6 %1: new client %2 attempting to get a lease from the partner
This informational message is issued when the surviving server observes
a DHCP packet sent to the partner with which the communication is interrupted.
The client whose packet is observed is not yet considered "unacked" because
the elapsed time option value does not exceed the configured threshold
specified with max-ack-delay. The sole argument specifies client
identification information.

% HA_COMMUNICATION_INTERRUPTED_CLIENT6_UNACKED %1: partner server failed to respond to %2, %3 clients unacked so far, %4 clients left before transitioning to the partner-down state
This informational message is issued when the surviving server determines
that its partner failed to respond to the DHCP query and that this client
is considered to not be served by the partner. The surviving server counts
such clients and if the number of such clients exceeds the max-unacked-clients
threshold, the server will transition to the partner-down state. The first
argument specifies the relationship name. The second argument contains client
identification information. The third argument specifies the number of clients
to which the server has failed to respond. The forth argument specifies the
number of additional clients which, if not provisioned, will cause the server
to transition to the partner-down state.

% HA_CONFIGURATION_FAILED failed to configure High Availability hooks library: %1
This error message is issued when there is an error configuring the HA hooks
library. The argument provides the detailed error message.

% HA_CONFIGURATION_SUCCESSFUL HA hook library has been successfully configured
This informational message is issued when the HA hook library configuration
parser successfully parses and validates the new configuration.

% HA_CONFIG_AUTO_FAILOVER_DISABLED %1: auto-failover disabled
This warning message is issued to indicate that the 'auto-failover' parameter
was administratively disabled for the specified server. The server will not
automatically start serving partner's scope when the partner failure is detected.
The server administrator will need to enable this scope manually by
sending appropriate ha-scopes command.

% HA_CONFIG_DHCP_MT_DISABLED %1: HA multi-threading has been disabled, it cannot be enabled when Kea global multi-threading is disabled
This informational message is issued when HA configuration has enabled
multi-threading while Kea global configuration has multi-threading disabled.

% HA_CONFIG_DHCP_MT_DISABLED_AND_KEA_MT_ENABLED %1: HA multi-threading is disabled while Kea global multi-threading is enabled which most likely cause performance degradation.
This warning message is issued when HA configuration has disabled
multi-threading while Kea global configuration has multi-threading enabled.
This will likely cause performance degradation.

% HA_CONFIG_LEASE_SYNCING_DISABLED %1: lease database synchronization between HA servers is disabled
This warning message is issued when the lease database synchronization is
administratively disabled. This is valid configuration if the leases are
replicated between lease databases via some other mechanism, e.g. SQL
database replication.

% HA_CONFIG_LEASE_SYNCING_DISABLED_REMINDER %1: bypassing SYNCING state because lease database synchronization is administratively disabled
This informational message is issued as a reminder that lease database
synchronization is administratively disabled and therefore the server
transitions directly from the "waiting" to "ready" state.

% HA_CONFIG_LEASE_UPDATES_AND_SYNCING_DIFFER %1: unusual configuration where "send-lease-updates": %2 and "sync-leases": %3
This warning message is issued when the configuration values of the
send-lease-updates and sync-leases parameters differ. This may be a
valid configuration but is unusual. Normally, if the lease database
with replication is in use, both values are set to false. If a lease
database without replication is in use (e.g. memfile), both values
are set to true. Providing different values for those parameters means
that an administrator either wants the server to not synchronize
leases upon startup but later send lease updates to the partner, or
the lease database should be synchronized upon startup, but no lease
updates are later sent as a result of leases allocation.

% HA_CONFIG_LEASE_UPDATES_DISABLED %1: lease updates will not be generated
This warning message is issued when the lease updates are administratively
disabled. This is valid configuration if the leases are replicated to the
partner's database via some other mechanism, e.g. SQL database replication.

% HA_CONFIG_LEASE_UPDATES_DISABLED_REMINDER %1: lease updates are administratively disabled and will not be generated while in %2 state
This informational message is issued as a reminder that the lease updates
are administratively disabled and will not be issued in the HA state to
which the server has transitioned. The sole argument specifies the state
into which the server has transitioned.

% HA_CONFIG_SYSTEM_MT_UNSUPPORTED %1: HA multi-threading has been disabled, auto-detection of thread support reports 0
This informational message is issued when HA multi-threading configuration has
specified auto-detection for the number of threads to use and the system
reports the number of concurrent threads as 0. If you know your system can
support multiple threads, then you may override this condition by specifying
explicit values for http-listener-threads and http-client-threads.

% HA_CONTINUE_HANDLER_FAILED ha-continue command failed: %1
This error message is issued to indicate that the ha-continue command handler
failed while processing the command. The argument provides the reason for
failure.

% HA_DEINIT_OK unloading High Availability hooks library successful
This informational message indicates that the High Availability hooks library
has been unloaded successfully.

% HA_DHCP4_START_SERVICE_FAILED failed to start DHCPv4 HA services in dhcp4_srv_configured callout: %1
This error message is issued when an attempt to start High Availability services
for the DHCPv4 server failed in the dhcp4_srv_configured callout. This
is internal server error and a bug report should be created.

% HA_DHCP6_START_SERVICE_FAILED failed to start DHCPv6 HA services in dhcp6_srv_configured callout: %1
This error message is issued when an attempt to start High Availability services
for the DHCPv6 server failed in the dhcp6_srv_configured callout. This
is internal server error and a bug report should be created.

% HA_DHCP_DISABLE_COMMUNICATIONS_FAILED %1: failed to send request to disable DHCP service of %2: %3
This warning message indicates that there was a problem in communication with a
HA peer while sending the dhcp-disable command. The first argument specifies
the local server's name. The second argument provides the remote server's name.
The third argument provides a reason for failure.

% HA_DHCP_DISABLE_FAILED %1: failed to disable DHCP service of %2: %3
This warning message indicates that a peer returned an error status code
in response to a dhcp-disable command. The first argument provides the
local server's name. The second argument provides the remote server's name.
The third argument provides a reason for failure.

% HA_DHCP_ENABLE_COMMUNICATIONS_FAILED %1: failed to send request to enable DHCP service of %2: %3
This warning message indicates that there was a problem in communication with a
HA peer while sending the dhcp-enable command. The first argument provides the
local server's name. The second argument provides the remote server's name. The
third argument provides a reason for failure.

% HA_DHCP_ENABLE_FAILED %1: failed to enable DHCP service of %2: %3
This warning message indicates that a peer returned an error status code
in response to a dhcp-enable command. The first argument provides the
local server's name. The second argument provides the remote server's name.
The third argument provides a reason for failure.

% HA_HEARTBEAT_COMMUNICATIONS_FAILED %1: failed to send heartbeat to %2: %3
This warning message indicates that there was a problem in communication with a
HA peer while sending a heartbeat. This is a first sign that the peer may be
down. The server will keep trying to send heartbeats until it considers that
communication is interrupted.

% HA_HEARTBEAT_FAILED %1: heartbeat to %2 failed: %3
This warning message indicates that a peer returned an error status code
in response to a heartbeat. This is the sign that the peer may not function
properly. The server will keep trying to send heartbeats until it considers
that communication is interrupted.

% HA_HEARTBEAT_HANDLER_FAILED heartbeat command failed: %1
This error message is issued to indicate that the heartbeat command handler
failed while processing the command. The argument provides the reason for
failure.

% HA_HIGH_CLOCK_SKEW %1: %2, please synchronize clocks!
This warning message is issued when the clock skew between the active servers
exceeds 30 seconds. The HA service continues to operate but may not function
properly, especially for low lease lifetimes. The administrator should
should synchronize the clocks, e.g. using NTP. If the clock skew exceeds
60 seconds, the HA service will terminate.

% HA_HIGH_CLOCK_SKEW_CAUSED_TERMINATION %1: %2, causing HA service to terminate
This warning message is issued when the clock skew between the active servers
exceeds 60 seconds. The HA service stops. The servers will continue to respond
to the DHCP queries but won't exchange lease updates or send heartbeats.
The administrator is required to synchronize the clocks and then restart the
servers to resume the HA service.

% HA_INIT_OK loading High Availability hooks library successful
This informational message indicates that the High Availability hooks library
has been loaded successfully. Enjoy!

% HA_INVALID_PARTNER_STATE_COMMUNICATION_RECOVERY %1: partner is in the communication-recovery state unexpectedly
This warning message is issued when a partner is in the communication-recovery
state, and this server is not running in the load balancing mode. The server
may only transition to the communication-recovery state when it runs in the
load balancing mode. The HA mode of both servers must be the same.

% HA_INVALID_PARTNER_STATE_HOT_STANDBY %1: partner is in the hot-standby state unexpectedly
This warning message is issued when a partner is in the hot-standby state,
and this server is not running in the hot standby mode. The server may only
transition to the hot-standby state when it runs in the hot standby mode.
The HA mode of both servers must be the same.

% HA_INVALID_PARTNER_STATE_LOAD_BALANCING %1: partner is in the load-balancing state unexpectedly
This warning message is issued when a partner is in the load-balancing state,
and this server is not running in the load balancing mode. The server may only
transition to the load-balancing state when it runs in the load balancing mode.
The HA mode of both servers must be the same.

% HA_LEASE4_EXPIRE_FAILED lease4_expire callout failed: %1
This error message is issued when the callout for the lease4_expire hook
point failed. This includes unexpected errors like wrong arguments provided to
the callout by the DHCP server (unlikely internal server error).
The argument contains a reason for the error.

% HA_LEASE4_EXPIRE_INVALID_HA_SERVER_NAME %1: invalid ha-server-name value for subnet %2
This error message is issued when the reclaimed DHCPv4 lease belongs to
a subnet which includes ha-server-name value in the user-context but this
value is not a string or is empty. It is a server's misconifguration.
The first argument holds the lease information. The second argument is a
subnet prefix.

% HA_LEASE4_EXPIRE_RECLAMATION_SKIP %1: skipping reclamation of the lease that belongs to a partner
Logged at debug log level 40.
This debug message is issued when the server is in the terminated state and
skips reclamation of the lease that was probably allocated by another server,
or is maintained by the other server while the servers are in the HA terminated
state. The argument is the lease address.

% HA_LEASE4_SERVER_DECLINE_FAILED lease4_server_decline callout failed: %1
This error message is issued when the callout for the lease4_server_decline hook
point failed. This includes unexpected errors like wrong arguments provided to
the callout by the DHCP server (unlikely internal server error).
The argument contains a reason for the error.

% HA_LEASE6_EXPIRE_FAILED lease4_expire callout failed: %1
This error message is issued when the callout for the lease4_expire hook
point failed. This includes unexpected errors like wrong arguments provided to
the callout by the DHCP server (unlikely internal server error).
The argument contains a reason for the error.

% HA_LEASE6_EXPIRE_INVALID_HA_SERVER_NAME %1: invalid ha-server-name value for subnet %2
This error message is issued when the reclaimed DHCPv6 lease belongs to
a subnet which includes ha-server-name value in the user-context but this
value is not a string or is empty. It is a server's misconifguration.
The first argument holds the lease information. The second argument is a
subnet prefix.

% HA_LEASE6_EXPIRE_RECLAMATION_SKIP %1: skipping reclamation of the lease that belongs to a partner
Logged at debug log level 40.
This debug message is issued when the server is in the terminated state and
skips reclamation of the lease that was probably allocated by another server,
or is maintained by the other server while the servers are in the HA terminated
state. The argument is the lease address.

% HA_LEASES4_COMMITTED_FAILED leases4_committed callout failed: %1
This error message is issued when the callout for the leases4_committed hook
point failed. This includes unexpected errors like wrong arguments provided to
the callout by the DHCP server (unlikely internal server error).
The argument contains a reason for the error.

% HA_LEASES4_COMMITTED_NOTHING_TO_UPDATE %1: leases4_committed callout was invoked without any leases
Logged at debug log level 40.
This debug message is issued when the "leases4_committed" callout returns
because there are neither new leases nor deleted leases for which updates
should be sent. The sole argument specifies the details of the client
which sent the packet.

% HA_LEASES4_COMMITTED_NO_RELATIONSHIP %1: HA relationship not found: %2
This error message is issued when the relationship for the server name provided
by the earlier callouts was not found in the HA configuration. This error is
highly unlikely and rather indicates some programming error. The first argument
is the client identification information. The second argument holds a more
detailed error message.

% HA_LEASES6_COMMITTED_FAILED leases6_committed callout failed: %1
This error message is issued when the callout for the leases6_committed hook
point failed. This includes unexpected errors like wrong arguments provided to
the callout by the DHCP server (unlikely internal server error).
The argument contains a reason for the error.

% HA_LEASES6_COMMITTED_NOTHING_TO_UPDATE %1: leases6_committed callout was invoked without any leases
Logged at debug log level 40.
This debug message is issued when the "leases6_committed" callout returns
because there are neither new leases nor deleted leases for which updates
should be sent. The sole argument specifies the details of the client
which sent the packet.

% HA_LEASES6_COMMITTED_NO_RELATIONSHIP %1: HA relationship not found: %2
This error message is issued when the relationship for the server name provided
by the earlier callouts was not found in the HA configuration. This error is
highly unlikely and rather indicates some programming error. The first argument
is the client identification information. The second argument holds a more
detailed error message.

% HA_LEASES_BACKLOG_COMMUNICATIONS_FAILED %1: failed to communicate with %2 while sending lease updates backlog: %3
This error message is issued to indicate that there was a communication error
with a partner server while sending outstanding lease updates after resuming
connection. The third argument contains a reason for the error.

% HA_LEASES_BACKLOG_FAILED %1: failed to send lease updates backlog to %2: %3
This error message is issued to indicate that sending lease updates backlog
to a partner server failed. The lease updates backlog is sent to the partner
after resuming temporarily broken communication with the partner. If this
operation fails the server will transition to the waiting state to initiate
full lease database synchronization.

% HA_LEASES_BACKLOG_NOTHING_TO_SEND %1: no leases in backlog after communication recovery
This informational message is issued when there are no outstanding leases to
be sent after communication recovery with a partner. This means that the
communication interruption was short enough that no DHCP clients obtained
any leases from the server while it was in the communication-recovery state.
The server may now transition to the load-balancing state.

% HA_LEASES_BACKLOG_START %1: starting to send %2 outstanding lease updates to %3
This informational message is issued when the server starts to send outstanding
lease updates to the partner after resuming communications. The first argument
specifies the local server's name. The second argument specifies the number of
lease updates to be sent. The name of the partner is specified with the third
argument.

% HA_LEASES_BACKLOG_SUCCESS %1: sending lease updates backlog to %2 successful in %3
This informational message is issued when server successfully completes
sending lease updates backlog to the partner. The first argument specifies the
local server's name. The second argument specifies the name of the remote server.
The third argument specifies the duration of
this operation.

% HA_LEASES_SYNC_APPLIED_LEASES %1: applied %2 leases received from the partner in the local lease database
This informational message outputs the number of leases received from the
partner during the database synchronization and applied in the local database.
A typical case when only some leases are applied is when the server has
multiple relationships and some of the received leases belong to another
relationship. The first argument specifies this server name. The second
argument specifies the number of applied leases.

% HA_LEASES_SYNC_COMMUNICATIONS_FAILED %1: failed to communicate with %2 while syncing leases: %3
This error message is issued to indicate that there was a communication error
with a partner server while trying to fetch leases from its lease database.
The argument contains a reason for the error.

% HA_LEASES_SYNC_FAILED %1: failed to synchronize leases with %2: %3
This error message is issued to indicate that there was a problem while
parsing a response from the server from which leases have been fetched for
local database synchronization. The third argument contains a reason for
the error.

% HA_LEASES_SYNC_LEASE_PAGE_RECEIVED %1: received %2 leases from %3
This informational message is issued during lease database synchronization
to indicate that a bulk of leases have been received. The first argument
specifies the local server's name. The second argument holds the count of
leases received. The third argument specifies the partner server name.

% HA_LEASE_SYNC_FAILED %1: synchronization failed for lease: %2, reason: %3
This warning message is issued when creating or updating a lease in the
local lease database fails. The lease information in the JSON format is
provided as a first argument. The third argument provides a reason for
the failure.

% HA_LEASE_SYNC_STALE_LEASE4_SKIP %1: skipping stale lease %2 in subnet %3
Logged at debug log level 40.
This debug message is issued during lease database synchronization, when
fetched IPv4 lease instance appears to be older than the instance in the
local database. The newer instance is left in the database and the fetched
lease is dropped. The remote server will still hold the older lease instance
until it synchronizes its database with this server. The first argument
specifies the local server's name. The second argument specifies leased
address. The third argument specifies a subnet to which the lease belongs.

% HA_LEASE_SYNC_STALE_LEASE6_SKIP %1: skipping stale lease %2 in subnet %3
Logged at debug log level 40.
This debug message is issued during lease database synchronization, when
fetched IPv6 lease instance appears to be older than the instance in the
local database. The newer instance is left in the database and the fetched
lease is dropped. The remote server will still hold the older lease instance
until it synchronizes its database with this server. The first argument
specifies the local server's name. The second argument specifies leased
address. The second argument specifies a subnet to which the lease belongs.

% HA_LEASE_UPDATES_DISABLED %1: lease updates will not be sent to the partner while in %2 state
This informational message is issued to indicate that lease updates will
not be sent to the partner while the server is in the current state. The
second argument specifies the server's current state name. The lease updates
are still sent to the backup servers if they are configured but any
possible errors in communication with the backup servers are ignored.

% HA_LEASE_UPDATES_ENABLED %1: lease updates will be sent to the partner while in %2 state
This informational message is issued to indicate that lease updates will
be sent to the partner while the server is in the current state. The
second specifies the server's current state name.

% HA_LEASE_UPDATE_COMMUNICATIONS_FAILED %1: failed to send lease update %2 to %3: %4
This warning message indicates that there was a problem in communication with a
HA peer while processing a DHCP client query and sending lease update. The
client's DHCP message will be dropped.

% HA_LEASE_UPDATE_CONFLICT %1: lease update %2 sent to %3 returned conflict status code: %4
This warning message indicates that the partner returned a conflict status code
in response to a lease update. The client's DHCP message will be dropped.
If the server is configured to track conflicting lease updates, it may
eventually transition to the terminated state when the configured threshold
is exceeded.

% HA_LEASE_UPDATE_CREATE_UPDATE_FAILED_ON_PEER %1: failed to create or update the lease having type %2 for address %3, reason: %4
This informational message is issued when one of the leases failed to be
created or updated on the HA peer while processing the lease updates sent
from this server. This may indicate an issue with communication between
the peer and its lease database.

% HA_LEASE_UPDATE_DELETE_FAILED_ON_PEER %1: failed to delete the lease having type %2 for address %3, reason: %4
This informational message is issued when one of the leases failed to delete
on the HA peer while processing lease updates sent from this server. Typically,
the lease fails to delete when it doesn't exist in the peer's database.

% HA_LEASE_UPDATE_FAILED %1: lease update %2 sent to %3 failed: %4
This warning message indicates that a peer returned an error status code
in response to a lease update. The client's DHCP message will be dropped.

% HA_LEASE_UPDATE_REJECTS_CAUSED_TERMINATION %1: too many rejected lease updates cause the HA service to terminate
This error message is issued when the HA service terminates because the
number of lease updates for which a conflict status code was returned
by the partner exceeds the limit set with max-rejected-lease-updates
configuration parameter.

% HA_LOAD_BALANCING_DUID_MISSING %1: load balancing failed for the DHCPv6 message (transaction id: %2) because DUID is missing
Logged at debug log level 40.
This debug message is issued when the HA hook library was unable to load
balance an incoming DHCPv6 query because neither client identifier nor
HW address was included in the query. The query will be dropped. The
sole argument contains transaction id.

% HA_LOAD_BALANCING_IDENTIFIER_MISSING %1: load balancing failed for the DHCPv4 message (transaction id: %2) because HW address and client identifier are missing
Logged at debug log level 40.
This debug message is issued when the HA hook library was unable to load
balance an incoming DHCPv4 query because neither client identifier nor
HW address was included in the query. The query will be dropped. The
sole argument contains transaction id.

% HA_LOAD_BALANCING_LEASE_DUID_MISSING %1: load balancing failed for the DHCPv6 lease %2 because DUID is missing
Logged at debug log level 40.
This debug message is issued when the HA hook library was unable to load
balance a reclaimed DHCPv6 lease because client identifier was not included
found in the lease.

% HA_LOAD_BALANCING_LEASE_IDENTIFIER_MISSING %1: load balancing failed for the DHCPv4 lease %2 because HW address and client identifier are missing
Logged at debug log level 40.
This debug message is issued when the HA hook library was unable to load
balance a reclaimed DHCPv4 lease because neither client identifier nor
HW address was included in the query.

% HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the %1 is in the %2 state
This informational message is issued to indicate that the local DHCP service
is disabled because the server remains in a state in which the server
should not respond to DHCP clients, e.g. the server hasn't synchronized
its lease database. The first argument specifies server name. The second
argument specifies server's state.

% HA_LOCAL_DHCP_ENABLE local DHCP service is enabled while the %1 is in the %2 state
This informational message is issued to indicate that the local DHCP service
is enabled because the server remains in a state in which it should
respond to the DHCP clients. The first argument specifies server name.
The second argument specifies server's state.

% HA_MAINTENANCE_CANCEL_HANDLER_FAILED ha-maintenance-cancel command failed: %1
This error message is issued to indicate that the ha-maintenance-cancel command
handler failed while processing the command. The argument provides the reason for
failure.

% HA_MAINTENANCE_NOTIFY_CANCEL_COMMUNICATIONS_FAILED %1: failed to send ha-maintenance-notify to %2 in attempt to cancel its maintenance: %3
This warning message indicates that there was a problem in communication with a
HA peer while sending the ha-maintenance-notify command with the cancel flag
set to true. The first argument provides the local server's name. The second
argument provides the remote server's name. The third argument provides a reason
for failure.

% HA_MAINTENANCE_NOTIFY_CANCEL_FAILED %1: error returned while processing ha-maintenance-notify by %2 in attempt to cancel its maintenance: %3
This warning message indicates that a peer returned an error status code
in response to a ha-maintenance-notify command with the cancel flag set to
true. The first argument provides the local server's name. The second argument
provides the remote server's name. The third argument provides a reason for
failure.

% HA_MAINTENANCE_NOTIFY_COMMUNICATIONS_FAILED %1: failed to send ha-maintenance-notify to %2: %3
This warning message indicates that there was a problem in communication with a
HA peer while sending the ha-maintenance-notify command. The first argument provides
the local server's name. The second argument provides the remote server's name.
The third argument provides a reason for failure.

% HA_MAINTENANCE_NOTIFY_FAILED %1: error returned while processing ha-maintenance-notify by %2: %3
This warning message indicates that a peer returned an error status code
in response to a ha-maintenance-notify command.  The first argument provides the
remote server's name. The second argument provides a reason for failure.

% HA_MAINTENANCE_NOTIFY_HANDLER_FAILED ha-maintenance-notify command failed: %1
This error message is issued to indicate that the ha-maintenance-notify command
handler failed while processing the command. The argument provides the reason for
failure.

% HA_MAINTENANCE_SHUTDOWN_SAFE %1: the server can now be shutdown for maintenance as the partner has taken over the DHCP traffic
This informational message is displayed after the server transitions to the
in-maintenance state. This server no longer responds to any DHCP queries and its
partner - in partner-in-maintenance state - has taken over the DHCP traffic.
When the server in-maintenance state is shut down, the partner moves to
the partner-down state immediately.

% HA_MAINTENANCE_STARTED %1: the server is now in the partner-in-maintenance state and the partner is in-maintenance state
This informational message is displayed when the server receiving the
ha-maintenance-start command transitions to the partner-in-maintenance
state. The server does it after sending the ha-maintenance-notify to
its partner to put the partner in the in-maintenance state. From now on,
the server in the partner-in-maintenance state will be responding to all
queries and the partner will respond to no queries. The partner may be
safely shut down for maintenance in which case this server will
automatically transition from the partner-in-maintenance state to the
partner-down state.

% HA_MAINTENANCE_STARTED_IN_PARTNER_DOWN %1: the server is now in the partner-down mode as a result of requested maintenance
This informational message is displayed when the server receiving the
ha-maintenance-start command transitions to the partner-down state
because it was unable to communicate with the partner while receiving
the command. It is assumed that in such situation the partner is
already offline for the maintenance. Note that in this case the
normal failover procedure does not take place. The server does not wait
for a heartbeat to fail several times, nor it monitors the DHCP traffic
for not responded queries. In the maintenance case the server transitions
to the partner-down state when it first encounters a communication
problem with the partner.

% HA_MAINTENANCE_START_HANDLER_FAILED ha-maintenance-start command failed: %1
This error message is issued to indicate that the ha-maintenance-start command
handler failed while processing the command. The argument provides the reason for
failure.

% HA_MISSING_CONFIGURATION high-availability parameter not specified for High Availability hooks library
This error message is issued to indicate that the configuration for the
High Availability hooks library hasn't been specified. The 'high-availability'
parameter must be specified for the hooks library to load properly.

% HA_PAUSE_CLIENT_LISTENER_FAILED %1: pausing multi-threaded HTTP processing failed: %2
This error message is emitted when attempting to pause HA's HTTP client and
listener threads. This error is highly unlikely and indicates a programmatic
issue that should be reported as a defect.

% HA_PAUSE_CLIENT_LISTENER_ILLEGAL %1: pausing multi-threaded HTTP processing failed: %2
This error message is emitted when attempting to pause HA's HTTP client or
listener thread pools from a worker thread. This error indicates that a command
run on the listener threads is trying to use a critical section which would
result in a dead-lock.

% HA_RESET_COMMUNICATIONS_FAILED %1: failed to send ha-reset command to %2: %3
This warning message indicates a problem with communication with a HA peer
while sending the ha-reset command. The first argument specifies the local
server name. The second argument specifies a remote server name. The third
argument specifies a reason for failure.

% HA_RESET_FAILED %1: failed to reset HA state machine of %2: %3
This warning message indicates that a peer returned an error status code
in response to the ha-reset command. The first argument specifies a local
server name. The second argument specifies a remote server name. The third
argument specifies a reason for failure.

% HA_RESET_HANDLER_FAILED ha-reset command failed: %1
This error message is issued to indicate that the ha-reset command handler
failed while processing the command. The argument provides the reason for
failure.

% HA_RESUME_CLIENT_LISTENER_FAILED %1: resuming multi-threaded HTTP processing failed: %2
This error message is emitted when attempting to resume HA's HTTP client and
listener threads. This error is highly unlikely and indicates a programmatic
issue that should be reported as a defect.

% HA_SCOPES_HANDLER_FAILED ha-scopes command failed: %1
This error message is issued to indicate that the ha-scopes command handler
failed while processing the command. The argument provides reason for
the failure.

% HA_SERVICE_STARTED %1: started high availability service in %2 mode as %3 server
This informational message is issued when the HA service is started as a result
of server startup or reconfiguration. The first argument specifies a local server
name. The second argument provides the HA mode. The third argument specifies the
role of this server instance in this configuration.

% HA_STATE_MACHINE_CONTINUED %1: state machine is un-paused
This informational message is issued when the HA state machine is un-paused.
This unlocks the server from the current state. It may transition to any
other state if it needs to do so, e.g. 'partner-down' if its partner appears
to be offline. The server may also remain in the current state if the HA
setup state warrants such behavior.

% HA_STATE_MACHINE_PAUSED %1: state machine paused in state %2
This informational message is issued when the HA state machine is paused.
HA state machine may be paused in certain states specified in the HA hooks library
configuration. When the state machine is paused, the server remains in the given
state until it is explicitly unpaused (via the ha-continue command). If the state
machine is paused, the server operates normally but cannot transition to any
other state.

% HA_STATE_TRANSITION %1: server transitions from %2 to %3 state, partner state is %4
This informational message is issued when the server transitions to a new
state as a result of some interaction (or lack of thereof) with its partner.
The arguments specify local server name, initial server state, new server state
and the partner's state.

% HA_STATE_TRANSITION_PASSIVE_BACKUP %1: server transitions from %2 to %3 state
This informational message is issued when the server in passive-backup
mode transitions to a new state. The arguments specify local server name, initial
server state and a new server state.

% HA_SUBNET4_SELECT_FAILED subnet4_select callout failed: %1
This error message is issued when the callout for the subnet4_select hook
point failed. This may occur as a result of an internal server error.
The argument contains a reason for the error.

% HA_SUBNET4_SELECT_INVALID_HA_SERVER_NAME %1: invalid ha-server-name value for subnet %2
This error message is issued when the received DHCPv4 query is dropped
by this server because the specified ha-server-name value in the subnet's
user-context has non-string type or is empty. It is a server's misconifguration.
The first argument is the client identification information. The second argument
is a subnet prefix.

% HA_SUBNET4_SELECT_NOT_FOR_US %1: dropping query in relationship %2 to be processed by another server
Logged at debug log level 40.
This debug message is issued when the received DHCPv4 query is dropped
by this server because it should be served by another server. This
is the case when a remote primary server is operational. The first argument
is the client identification information. The second argument is the
relationship name.

% HA_SUBNET4_SELECT_NO_RELATIONSHIP_FOR_SUBNET %1: HA relationship not found for %2
This error message is issued when the received DHCPv4 query is dropped
by this server because the server could not find a relationship matching
the specified ha-server-name for a subnet. The server name matches no
relationship specified in the HA configuration. A typical reason for it
is a typo. The first argument is the client identification information.
The second argument is the relationship name.

% HA_SUBNET4_SELECT_NO_RELATIONSHIP_SELECTOR_FOR_SUBNET %1: unable to determine HA relationship because selected subnet %2 lacks the ha-server-name
This error message is issued when the received DHCPv4 query is dropped
by this server because it was unable to determine the HA relationship to
which the received query belongs. If there are multiple relationships,
it is required to specify ha-server-name value in the user-context at the subnet
or shared network level for each subnet and/or shared network. The server
uses them as a relationship selector. If these selectors are unspecified
for any of the subnets it is a configuration error. The first argument is
the client identification information. The second argument is a subnet
prefix.

% HA_SUBNET4_SELECT_NO_SUBNET_SELECTED %1: unable to determine HA relationship because no subnet has been selected for the client
Logged at debug log level 40.
This debug message is issued when the received DHCPv4 query is dropped
by this server because it could not select a subnet for this client.
Selecting the subnet is required to find a suitable HA relationship.
This message is not emitted when the server has only one relationship.
The argument is the client identification information.

% HA_SUBNET6_SELECT_FAILED subnet6_select callout failed: %1
This error message is issued when the callout for the subnet6_select hook
point failed. This may occur as a result of an internal server error.
The argument contains a reason for the error.

% HA_SUBNET6_SELECT_INVALID_HA_SERVER_NAME %1: invalid ha-server-name value for subnet %2
This error message is issued when the received DHCPv6 query is dropped
by this server because the specified ha-server-name value in the subnet's
user-context has non-string type or is empty. It is a server's misconifguration.
The first argument is the client identification information. The second argument
is a subnet prefix.

% HA_SUBNET6_SELECT_NOT_FOR_US %1: dropping query in relationship %2 to be processed by another server
Logged at debug log level 40.
This debug message is issued when the received DHCPv6 query is dropped
by this server because it should be served by another server. This
is the case when a remote primary server is operational. The first argument
is the client identification information. The second argument is the
relationship name.

% HA_SUBNET6_SELECT_NO_RELATIONSHIP_FOR_SUBNET %1: HA relationship not found for %2
This error message is issued when the received DHCPv6 query is dropped
by this server because the server could not find a relationship matching
the specified ha-server-name for a subnet. The server name matches no
relationship specified in the HA configuration. A typical reason for it
is a typo.  The first argument is the client identification information.
The second argument is the relationship name.

% HA_SUBNET6_SELECT_NO_RELATIONSHIP_SELECTOR_FOR_SUBNET %1: unable to determine HA relationship because selected subnet %2 lacks the ha-server-name
This error message is issued when the received DHCPv6 query is dropped
by this server because it was unable to determine the HA relationship to
which the received query belongs. If there are multiple relationships,
it is required to specify ha-server-name value in the user-context at the subnet
or shared network level for each subnet and/or shared network. The server
uses them as a relationship selector. If these selectors are unspecified
for any of the subnets it is a configuration error. The first argument is
the client identification information. The second argument is a subnet
prefix.

% HA_SUBNET6_SELECT_NO_SUBNET_SELECTED %1: unable to determine HA relationship because no subnet has been selected for the client
Logged at debug log level 40.
This debug message is issued when the received DHCPv6 query is dropped
by this server because it could not select a subnet for this client.
Selecting the subnet is required to find a suitable HA relationship.
This message is not emitted when the server has only one relationship.
The argument is the client identification information.

% HA_SYNC_COMPLETE_NOTIFY_COMMUNICATIONS_FAILED %1: failed to send ha-sync-complete-notify to %2: %3
This warning message indicates that there was a problem in communication with an
HA peer while sending the ha-sync-complete-notify command. The first argument
provides a local server's name. The second argument provides the remote server's
name. The third argument provides a reason for failure.

% HA_SYNC_COMPLETE_NOTIFY_FAILED %1: error processing ha-sync-complete-notify command on %2: %3
This warning message indicates that a peer returned an error status code
in response to the ha-sync-complete-notify command. The first argument provides
a local server's name. The second argument provides the remote server's name. The
third argument provides a reason for failure.

% HA_SYNC_COMPLETE_NOTIFY_HANDLER_FAILED ha-sync-complete-notify command failed: %1
This error message is issued to indicate that the ha-sync-complete-notify command
handler failed while processing the command. The argument provides the reason for
failure.

% HA_SYNC_FAILED %1: lease database synchronization with %2 failed: %3
This error message is issued to indicate that the lease database synchronization
failed. The first argument provides the local server's name.  The second argument
provides the partner server's name. The third argument provides a reason for the
failure.

% HA_SYNC_HANDLER_FAILED ha-sync command failed: %1
This error message is issued to indicate that the ha-sync command handler
failed while processing the command. The argument provides the reason for
failure.

% HA_SYNC_START %1: starting lease database synchronization with %2
This informational message is issued when the server starts lease database
synchronization with a partner. The arguments specify the local and remote
server names.

% HA_SYNC_SUCCESSFUL %1: lease database synchronization with %2 completed successfully in %3
This informational message is issued when the server successfully completed
lease database synchronization with the partner. The first argument specifies
local server name. The second argument specifies the name of the partner server.
The third argument specifies the duration of the synchronization.

% HA_TERMINATED HA %1: service terminated due to an unrecoverable condition. Check previous error message(s), address the problem and restart!
This error message is issued to indicate that the HA service has been stopped
due to an unacceptable condition (e.g. too large of a clock skew). The exact
cause should appear in a previous error message.  Address the condition
reported then restart the servers to resume service.

% HA_TERMINATED_PARTNER_DID_NOT_RESTART %1: service is terminating because the terminated partner was not restarted within %2 minutes
This warning message is issued to indicate that the HA service is terminating
because partner server is in the terminated state and was not restarted within
an expected time frame. The terminated servers should be restarted after correcting
the problem that caused the termination. They can be restarted sequentially but the
duration between the restarts should not be too long. If it is long it may mean that
the restart of one of the servers was unintentional (e.g., power outage). If the
restarted server remains in the waiting state it cannot serve DHCP clients. Moving
to the terminated state at least allows for responding to the DHCP traffic.

% HA_TERMINATED_RESTART_PARTNER %1: waiting for the partner in the TERMINATED state to be restarted
This informational message is issued when the server has been restarted after
correcting the clock skew. The partner server is still in the terminated
state. The partner must be restarted before the server can synchronize the
database and start normal operation.
