FortiGate Manual HA Failover (Reset Uptime) Using CLI

Here's a link in troubleshooting FortiGate HA.

In my opinion, it's better to reset the FortiGate device uptime to manually restore or revert the original Primary firewall. Refer to this link to troubleshoot and interpret HA flags.

Check if the Secondary FortiGate firewall has the HA override disable and note the HA failover status flag.

FW01_SEC # show system ha | grep override

    set override disable

 

FW01_SEC # execute ha failover status

failover status: unset

 

 

The Secondary is acting as the Primary device in the High Availability (HA) cluster since its uptime is "larger" or device is up for a longer period of time. Also note the cluster index number for Primary and Secondary.

 

FW01_SEC # get system ha status

HA Health Status: OK

Model: FortiGate-4xxF

Mode: HA A-P

Group Name: FW01_CLUSTER

Group ID: 0

Debug: 0

Cluster Uptime: 6 days 13h:16m:48s

Cluster state change time: 2026-02-11 02:49:32

Primary selected using:

   <2026/02/11 02:49:32> vcluster-1: FG4H1FT922904444 is selected as the primary because its uptime is larger than peer member FG4H1FT922903333.

    <2026/02/11 02:46:27> vcluster-1: FG4H1FT922904444 is selected as the primary because it's the only member in the cluster.

    <2026/02/11 02:46:23> vcluster-1: FG4H1FT922904444 is selected as the primary because the value of link-failure + pingsvr-failure is less than peer member FG4H1FT922903333.

    <2026/02/11 02:42:49> vcluster-1: FG4H1FT922904444 is selected as the primary because it's the only member in the cluster.

ses_pickup: enable, ses_pickup_delay=disable

override: disable

Configuration Status:

    FG4H1FT922904444(updated 5 seconds ago): in-sync

    FG4H1FT922904444 chksum dump: bd 22 46 7c 8c bb f6 c6 73 54 f6 d2 d2 18 5a 1c

    FG4H1FT922903333(updated 1 seconds ago): in-sync

    FG4H1FT922903333 chksum dump: bd 22 46 7c 8c bb f6 c6 73 54 f6 d2 d2 18 5a 1c

System Usage stats:

    FG4H1FT922904444(updated 5 seconds ago):

        sessions=141, average-cpu-user/nice/system/idle=0%/0%/0%/99%, memory=28%

    FG4H1FT922903333(updated 1 seconds ago):

        sessions=14, average-cpu-user/nice/system/idle=0%/0%/0%/99%, memory=28%

HBDEV stats:

    FG4H1FT922904444(updated 5 seconds ago):

        ha: physical/1000auto, up, rx-bytes/packets/dropped/errors=4451813/18881/0/0, tx=27633523/26727/0/0

    FG4H1FT922903333(updated 1 seconds ago):

        ha: physical/1000auto, up, rx-bytes/packets/dropped/errors=26923055/24401/0/0, tx=4104707/17586/0/0

MONDEV stats:

    FG4H1FT922904444(updated 5 seconds ago):

        po1: aggregate/00, up, rx-bytes/packets/dropped/errors=51451719/86317/0/0, tx=11192875/63943/0/0

        po2: aggregate/00, up, rx-bytes/packets/dropped/errors=1856442/13545/0/0, tx=7439384/11524/0/0

    FG4H1FT922903333(updated 1 seconds ago):

        po1: aggregate/00, up, rx-bytes/packets/dropped/errors=422826/4005/0/0, tx=27924/157/0/0

        po2: aggregate/00, up, rx-bytes/packets/dropped/errors=382016/3818/0/0, tx=23840/153/0/0

number of member: 2

FW01_SEC, FG4H1FT922904444, HA cluster index = 1

FW01_PRI, FG4H1FT922903333, HA cluster index = 0

number of vcluster: 1

vcluster 1: work 169.254.0.2

Primary: FG4H1FT922904444, HA operating index = 0

Secondary: FG4H1FT922903333, HA operating index = 1

 

 

To reset the Secondary uptime, use the diagnose sys ha reset-uptime command. This will disconnect your current HTTPS/GUI session.

 

FW01_SEC # diagnose sys ha reset-uptime

 

 

Once you've re-login, notice the device hostname is back to the original Primary firewall.

 

FW01_PRI # get system ha status

HA Health Status: OK

Model: FortiGate-4xxF

Mode: HA A-P

Group Name: FW01_CLUSTER

Group ID: 0

Debug: 0

Cluster Uptime: 6 days 13h:28m:37s

Cluster state change time: 2026-02-11 03:16:05    //

Primary selected using:

   <2026/02/11 03:16:05> vcluster-1: FG4H1FT922903333 is selected as the primary because its uptime is larger than peer member FG4H1FT922902544.

    <2026/02/11 02:49:32> vcluster-1: FG4H1FT922904444 is selected as the primary because its uptime is larger than peer member FG4H1FT922903333.

ses_pickup: enable, ses_pickup_delay=disable

override: disable

Configuration Status:

    FG4H1FT922903333(updated 4 seconds ago): in-sync

    FG4H1FT922903333 chksum dump: bd 22 46 7c 8c bb f6 c6 73 54 f6 d2 d2 18 5a 1c

    FG4H1FT922904444(updated 4 seconds ago): in-sync

    FG4H1FT922904444 chksum dump: bd 22 46 7c 8c bb f6 c6 73 54 f6 d2 d2 18 5a 1c

System Usage stats:

    FG4H1FT922903003(updated 4 seconds ago):

        sessions=112, average-cpu-user/nice/system/idle=0%/0%/0%/99%, memory=28%

    FG4H1FT922904444(updated 4 seconds ago):

        sessions=28, average-cpu-user/nice/system/idle=0%/0%/0%/99%, memory=28%

HBDEV stats:

    FG4H1FT922903333(updated 4 seconds ago):

        ha: physical/1000auto, up, rx-bytes/packets/dropped/errors=29469319/30468/0/0, tx=6424709/23514/0/0

    FG4H1FT922904444(updated 4 seconds ago):

        ha: physical/1000auto, up, rx-bytes/packets/dropped/errors=6786743/24841/0/0, tx=30193967/32825/0/0

MONDEV stats:

    FG4H1FT922903333(updated 4 seconds ago):

        po1: aggregate/00, up, rx-bytes/packets/dropped/errors=1689444/9284/0/0, tx=523774/2771/0/0

        po2: aggregate/00, up, rx-bytes/packets/dropped/errors=791925/7447/0/0, tx=1255468/1865/0/0

    FG4H1FT922904444(updated 4 seconds ago):

        po1: aggregate/00, up, rx-bytes/packets/dropped/errors=54864434/101059/0/0, tx=14252015/75175/0/0

        po2: aggregate/00, up, rx-bytes/packets/dropped/errors=2300163/18051/0/0, tx=8158689/15016/0/0

number of member: 2

FW01_PRI, FG4H1FT922903333, HA cluster index = 0

FW01_SEC, FG4H1FT922904444, HA cluster index = 1

number of vcluster: 1

vcluster 1: work 169.254.0.1

Primary: FG4H1FT922903333, HA operating index = 0

Secondary: FG4H1FT922904444, HA operating index = 1

Cisco Firepower SNMP OID Bug (CSCvd33367)

We've been trying to poll our Cisco Firepower 2100 (ASA) and Cisco Secure 3100 (ASA) to monitor the device power supply, fan and temperature sensor in our NMS via SNMP. Currently, we can only monitor device CPU and memory. Cisco TAC has confirmed that there's a bug (CSCvd33367) and it seem an engineering bug (Severity 6/Enhancement). Cisco TAC haven't resolved this issue in a long time (since February 2017) and there's no workaround.

We've raised this to our Cisco Account Manager to raise this to their engineering hoping this would resolved anytime soon. Below is a snippet from the said bug:

 

SNMP OID's for Disk, Fan and power supply

 

Description:

SNMP monitoring on the firepower is based on OID's. Actually firepower manages basic linux OIDs, customer would like to use also those OID's for monitoring Firepower status. Moreover, there is a more stringent need to have storage OIDs for pure ASAs which are not FMC managed to have disk monitoring in FMC.

 

Symptom:

The customer would like to use SNMP to monitor Fan, power supply and Raid disk status with the OID's for those features on the FP. He would like to know if those OID's can be included in future releases and that way he can monitor tose features using OIDs.

 

Conditions:

Firepower does not have OID's available for monitoring fan, power supply and Raid disk status.

 

Workaround: N/A

 

Further Problem Description: N/A

Note that its Severity is “6 Enhancement”, which means that Cisco Engineering is not looking at this behavior as a “bug” per se.  That is, from Engineering’s viewpoint, the product is working as designed and this CDETS ID represents a request to enhance the original behavior. Feature enhancements are pushed by Sales account teams into Product Marketing, which prioritizes enhancement requests back to Engineering.

Check the FortiGate NAT Session Count Using Filters

Here's a quick way to check the FortiGate NAT session count and filter the NAT IP pool via the get sys session list | grep -c CLI command. This command is found in the Fortinet Tech Tip link.

 

FGT# get sys session list | grep -c 216.1.1.50

2096

 

FGT# get sys session list | grep -c 216.1.1.51

1774

You can also filter using a Policy ID.

FGT# get sys session list | grep -c 106

1085 

FGT# get sys session list | grep -c 137

673

 

FortiGate 1800F and How to Check Transceiver Serial Number

Here's a Fortinet link for the FortiGate 1800F series data sheet. The FG-1800F front chassis has 1x RJ45 / USB CONSOLE port, 2x GigE RJ45 out-of-band management ports (MGMT1 and MGMT2), 2x 10 GigE fiber SFP/SFP+ HA1 and HA2 ports (2x fiber SFP are included in the box), 16x GigE RJ45 ports, 8x GE fiber SFP ports, 12x 25 SFP28 / 10 GigE fiber SFP+ / GE SFP ports, 4x 100 GigE QSFP28 / 40 GigE QSFP+ ports.

The rear chassis has the serial number sticker (on the far left), redundant fans and 2x hot-swappable power supply: PSU1 on the right and PSU2 on the left.

Here's a Fortinet link for the different types of copper and optical transceivers supported in a Fortinet appliance. Third party SFP/GBIC transceivers (such as a Cisco brand) would still work in a FortiGate SFP/SFP+ port. It's always best practice to use Fortinet brand SFP in a FortiGate appliance for optimum performance.

Here's a Fortinet link on how to check the SFP serial number and transmit/receive optic power level in a FortiGate firewall. You'll need to issue the get system interface transceiver to view all ports or get system interface transceiver <interface> to display the info for a specific interface including its fiber optic levels (Rx/Tx power). Notice port 17 uses a Fortinet brand SFP while port 18 uses a Cisco brand SFP.

FGT# get system interface transceiver

<intface>    Interface name.

 

FGT # get system interface transceiver

Interface port17 - SFP/SFP+/SFP28, 10GBASE-SR

  Vendor Name  :            FORTINET       

  Part No.     :            FTLX8574D3BCLABC

  Serial No.   :            N88B123        

Interface port18 - SFP/SFP+/SFP28, 10GBASE-SR

  Vendor Name  :            CISCO-FINISAR  

  Part No.     :            FTLX8574D3DEF-CS

  Serial No.   :            FNS21510456    

Interface port19 -Transceiver is not detected.

Interface port20 - Transceiver is not detected.

<OUTPUT TRUNCATED>

FGT # get system interface transceiver port17

Interface port17 - SFP/SFP+/SFP28, 10GBASE-SR

  Diagnostics  :            Implemented

  Vendor Name  :            FORTINET        

  Part No.     :            FTLX8574D3BCLABC

  Serial No.   :            N88B123        

  Measurement  Unit         Value        High Alarm   High Warning Low Warning  Low Alarm

  ------------ ------------ ------------ ------------ ------------ ------------ ------------              

  Temperature  (Celsius)     31.8         78.0         73.0         -8.0        -13.0       

  Voltage      (Volts)       3.29         3.70         3.60         3.00         2.90       

  Tx Bias      (mA)          5.98        13.00        12.50         5.00         4.00       

  Rx Power     (dBm)        -26.8 --       0.0         -1.0        -18.0        -20.0       
  Tx Power     (dBm)         -2.3          0.0         -1.0         -5.0         -6.0       

  ++ : high alarm, + : high warning, - : low warning, -- : low alarm, ? : suspect.

You can also view the same info via web GUI, just go to Network > Interfaces > Transceiver(s) column > hover over a specific interface SFP serial number to view more details. Note the Cisco brand SFP was detected by the FortiGate but there's a warning: This transceiver is not certified by Fortinet.