This is the time when the server last reported its state; it is not necessarily the time when the state information was refreshed in the UI. The presented state information is typically delayed by 10 to 30 seconds because it is cached by both the Kea servers and the Stork backend. Caching minimizes the performance impact on the DHCP servers reporting their states over the control channel.
This is the duration between the "Status Time" and now, i.e. it indicates how long ago the server reported its state. A long duration indicates that there is a communication problem with the server. The typical duration is between 10 and 30 seconds.
An online control status indicates that the server is responding to commands over the control channel.
An offline control status indicates that the server is not responding and may be down.
The unknown control status may appear during the server's startup, when the information about its actual status is not yet available.
The heartbeat status reports whether the server is responding to the heartbeat commands from its partner. Heartbeat commands are exchanged between the partners regularly to check whether the servers remain operational, and to gather and respond to their current states.
An OK status is desired at all times. It indicates a healthy heartbeat communication with the server.
A failed status occurs when the most recent attempt to send a heartbeat to the server fails. In this case, the partners enter the communication-interrupted state. They may recover from this state if the communication problem is transient. If communication is interrupted for a longer period, the failover procedure is triggered, resulting in the partner's transition to the partner-down state.
An unknown status may occur when the servers have not yet tried to exchange heartbeats.
The following are the possible server states:
This is a list of HA scopes currently being served by this server. If the server is responding to the DHCP queries as a primary or secondary in the load-balancing mode or as a primary in the hot-standby mode, there is typically a single scope shown. Two scopes may be shown if a load-balancing server is currently serving all DHCP clients while its partner is down. There may be no scopes shown when a standby server is in hot-standby mode, because such a server is not responding to any DHCP queries; instead, it is passively receiving lease updates from the primary. The standby server will start serving the primary server scope in the event of the primary failure.
This is the last time when the server transitioned to the partner-down state because its partner was considered offline as a result of an unexpected termination or shutdown.
This is the number of clients considered unacked by the partner. This value is only set when the partner has lost heartbeat communication with this server and has started the failover procedure, by monitoring whether the server is responding to DHCP traffic. The unacked number indicates clients that have been trying to get leases from this server longer than the time specified by the max-ack-delay configuration parameter.
This is the total number of clients trying to get new leases from the partner server, while the current server is unable to communicate with its partner via ha-heartbeat. This figure includes both unacked clients and clients for which the secs field or elapsed time option is below the max-ack-delay.
This is the total number of packets directed to the partner server, while the current server is unable to communicate using ha-heartbeat. It may include several packets from the same client who tried to resend a DHCPDISCOVER or Solicit after the server failed to respond to previous queries.
This shows a progress bar for the failover procedure. When it hits 100%, the server considers its partner offline, and transitions to the partner-down state. The progress is calculated from the number of unacked clients relative to the maximum number of unacked clients.
This is summary text describing the status of the HA setup.