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.
sjoshi
Staff
Staff
Article Id 412671
Description

 

This article describes the behavior of FortiGate HA uptime reset and how it can trigger unexpected failover events.

 

Scope

 

FortiGate.

 

Solution

 

FortiGate is set up in HA A-A mode.

 

Environment details:

  • FGT3KD3Z16800033: Master (less priority).
  • FGT3KDT418800474: Slave (higher priority).
  • Override is disabled under HA config.
  • FGT3KD3Z16800033 is selected as the Master based on uptime

 

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

Contributors