FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
nithincs
Staff
Staff
Article Id 264123
Description This article describes to read the cause of an HA failover from the output of the 'get sys ha status' command.
Scope Any supported version of FortiGate.
Solution
Executing "get sys ha status" in any ha cluster member will provide the failover reason and time of event to aid in understanding the failover reason.
 
The following are the reasons for failover and details available under 'Primary selected using' in 'get sys ha status' output.
 
For reference,  FGVMxxxxxxxJZPF5 and FGVMxxxxxxxLRLBE are in an HA cluster with FGVMxxxxxxxJZPF5 elected as the Primary.
 
1. When the monitored interface of the primary device (FGVMxxxxxxxJZPF5) goes down:
 
Primary selected using:
    <2023/07/14 04:59:34> FGVMxxxxxxxLRLBE is selected as the primary because the value 0 of link-failure + pingsvr-failure is less than peer member FGVMxxxxxxxJZPF5. <<< @ 04:59:34 Monitored interface of FGVMxxxxxxxJZPF5 went down and trigger the ha failover.
    <2023/07/14 03:51:04> FGVMxxxxxxxJZPF5 is selected as the primary because its serialno is larger than peer member FGVMxxxxxxxLRLBE. << @ 03:51:04 FGVMxxxxxxxJZPF5 was Primary device 
 
2. When one of the cluster members went down: 
 
Primary selected using:
    <2023/07/14 05:17:55> FGVMxxxxxxxJZPF5 is selected as the primary because it's the only member in the cluster.
 
3. When cluster member (FGVMxxxxxxxJZPF5) joins the cluster back and is elected as master due to high priority (when HA override is enabled):
 
Primary selected using:
    <2023/07/14 05:24:48> FGVMxxxxxxxJZPF5 is selected as the primary because its override priority is larger than peer member FGVMxxxxxxxLRLBE.
    <2023/07/14 05:22:15> FGVMxxxxxxxLRLBE is selected as the primary because it's the only member in the cluster.
 
4. When cluster member (FGVMxxxxxxxJZPF5) rejoins the cluster, but the existing primary (FGVMxxxxxxxLRLBE) device continues to be the primary unit due to high uptime (when HA override is disabled):
 
Primary selected using:
    <2023/07/14 05:37:30> FGVMxxxxxxxLRLBE is selected as the primary because its uptime is larger than peer member FGVMxxxxxxxJZPF5.
    <2023/07/14 05:36:56> FGVMxxxxxxxLRLBE is selected as the primary because it's the only member in the cluster.
 
5. When the HA uptime of the primary device reset is performed:
 
Primary selected using:
    <2023/07/14 05:48:55> FGVMxxxxxxxJZPF5 is selected as the primary because its uptime is larger than peer member FGVMxxxxxxxLRLBE. << Due to reset of FGVMxxxxxxxLRLBE HA uptime, FGVMxxxxxxxJZPF5 ha uptime become larger and elected as Primary.
    <2023/07/14 05:44:17> FGVMxxxxxxxLRLBE is selected as the primary because its uptime is larger than peer member FGVMxxxxxxxJZPF5. @05:44:17 FGVMxxxxxxxLRLBE was the Primary device 
 
6. When HA failover is triggered due to configuration of memory-based-failover:
 
Primary selected using:
    <2023/07/14 05:44:16> FGVMxxxxxxxJZPF5 is selected as the primary because there is high memory usage on peer member FGVMxxxxxxxLRLBE. << High memory usage in FGVMxxxxxxxLRLBE triggered HA failover.
 
7. When HA failover is triggered due to 'execute ha failover set'
 
Primary selected using:
    <2023/07/14 05:58:22> FGVMxxxxxxxLRLBE is selected as the primary because EXE_FAIL_OVER flag is set on peer member FGVMxxxxxxxJZPF5. << Execution of 'execute ha failover set' in FGVMxxxxxxxJZPF5 triggered the HA failover. 
Contributors