This article describes the behavior of FortiGate HA uptime reset and how it can trigger unexpected failover events.
FortiGate.
FortiGate is set up in HA A-A mode.
Environment details:
FGT3KD3Z16800033 is Master and uptime is 1409(>300):
FGT3KD-3 # diagnose sys ha dump-by group
HA information.
group-id=0, group-name='salon-ha'
has_no_aes128_gcm_sha256_member=0
gmember_nr=2
'FGT3KD3Z16800033': ha_ip_idx=1, hb_packet_version=29, last_hb_jiffies=0, linkfails=0, weight/o=0/0, support_aes128_gcm_sha256=1
'FGT3KDT418800474': ha_ip_idx=0, hb_packet_version=40, last_hb_jiffies=2474967, linkfails=18, weight/o=0/0, support_aes128_gcm_sha256=1
hbdev_nr=1: mgmt2(mac=704c..91, last_hb_jiffies=2474967, hb_lost=0),
vcluster_nr=1
vcluster-1: start_time=1758554796(2025-09-22 08:26:36), state/o/chg_time=2(work)/2(work)/1758556206(2025-09-22 08:50:06)
pingsvr_flip_timeout/expire=3600s/3508s
mondev: port2(prio=50,is_aggr=0,status=1) mgmt2(prio=50,is_aggr=0,status=1)
'FGT3KD3Z16800033': ha_prio/o=0/0, link_failure=0, pingsvr_failure=0, flag=0x00000001, mem_failover=0, uptime/reset_cnt=1409/5
'FGT3KDT418800474': ha_prio/o=1/1, link_failure=0, pingsvr_failure=0, flag=0x00000000, mem_failover=0, uptime/reset_cnt=0/7
In certain scenarios, the secondary device in an HA A-A setup may require a reboot, for example, to resolve unresponsive daemons.
Since the secondary unit also handles traffic, it is essential that rebooting it does not disrupt the primary device, particularly when the primary’s HA uptime is higher and should maintain the Master role.
Rebooted the secondary device FGT3KDT418800474. Upon startup, FGT3KDT418800474 became Master due to its higher priority, despite override being disabled and FGT3KD3Z16800033 having a higher HA uptime before the reboot.
FGT3KD-6 # get sys ha status
HA Health Status: OK
Model: FortiGate-3000D
Mode: HA A-A
Group Name: salon-ha
Group ID: 0
Debug: 0
Cluster Uptime: 3 days 6h:24m:27s
Cluster state change time: 2025-09-22 21:24:53
Primary selected using:
<2025/09/22 21:24:53> vcluster-1: FGT3KDT418800474 is selected as the primary because its override priority is larger than peer member FGT3KD3Z16800033.
With an HA uptime difference below 300 seconds, priority determined the Master role, and FGT3KDT418800474, having a higher priority, became Master.
FGT3KD-6 # diagnose sys ha dump-by group
HA information.
group-id=0, group-name='salon-ha'
has_no_aes128_gcm_sha256_member=0
gmember_nr=2
'FGT3KD3Z16800033': ha_ip_idx=1, hb_packet_version=37, last_hb_jiffies=340592, linkfails=18, weight/o=0/0, support_aes128_gcm_sha256=1
hbdev_nr=1: mgmt2(mac=906c..71, last_hb_jiffies=340592, hb_lost=0),
'FGT3KDT418800474': ha_ip_idx=0, hb_packet_version=4, last_hb_jiffies=0, linkfails=0, weight/o=0/0, support_aes128_gcm_sha256=1
vcluster_nr=1
vcluster-1: start_time=1758556492(2025-09-22 21:24:52), state/o/chg_time=2(work)/2(work)/1758556493(2025-09-22 21:24:53)
pingsvr_flip_timeout/expire=3600s/193s
mondev: mgmt2(prio=50,is_aggr=0,status=1) port2(prio=50,is_aggr=0,status=1)
'FGT3KD3Z16800033': ha_prio/o=1/1, link_failure=0, pingsvr_failure=0, flag=0x00000000, mem_failover=0, uptime/reset_cnt=40/6
'FGT3KDT418800474': ha_prio/o=0/0, link_failure=0, pingsvr_failure=0, flag=0x00000001, mem_failover=0, uptime/reset_cnt=0/1
During the reboot of FGT3KDT418800474, the heartbeat port mgmt2 went down because it is directly connected to FGT3KD3Z16800033.
<2025-09-22 21:24:54> vcluster-1: FGT3KDT418800474 is selected as the primary because its override priority is larger than peer member FGT3KD3Z16800033.
<2025-09-22 21:24:54> new member 'FGT3KDT418800474' joins the cluster
<2025-09-22 21:24:41> hbdev mgmt2 link status changed: 0->1
<2025-09-22 21:24:41> port mgmt2 link status changed: 0->1
<2025-09-22 21:24:14> hbdev mgmt2 link status changed: 1->0
<2025-09-22 21:24:14> port mgmt2 link status changed: 1->0
The monitor interface configuration shows that mgmt2 was included as part of the monitored interfaces:
set monitor "mgmt2" "port2"
Since the heartbeat port was included as a monitor interface, the HA uptime of a member resets to zero whenever the unit reboots or if a monitored interface fails.
The HA uptime was reset because the monitor interface mgmt2 (heartbeat port) went down on the Previous Master FGT3KD3Z16800033.
It is recommended to remove the heartbeat interface from the monitor interface list, as this configuration is incorrect. To ensure a specific device consistently remains Master, enable override and assign a higher priority to that device
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.