Course menu

Module 7: Operations and PracticeLesson 7.1 (1 of 4 in this module)30 of 33 in the FortiGate Administrator course

High availability (FGCP)

Active-passive and active-active clusters, heartbeat links, how the primary is elected, session pickup, monitored interfaces and checking cluster health.

Advanced · 13 min read

What you will learn

After this lesson, you can configure an active-passive FGCP cluster, predict which unit becomes primary, explain what session pickup and monitored interfaces change, and check that the cluster is healthy and in sync.

  • FGCP modes
  • Primary election
  • Session pickup
  • Cluster checks

FGCP (FortiGate Clustering Protocol) joins two or more identical FortiGates into one high-availability cluster. They exchange heartbeats over dedicated links, keep their configurations synchronised, and present shared virtual MAC addresses on each interface. One unit is primary; if it fails, or loses a monitored interface, another unit takes over the same addresses.

In simple terms: Two identical firewalls act as one. One works, the other watches and takes over within seconds if the first one fails.

A real-life situation

FGT1 is now the gateway, VPN hub and security inspection point for the whole company. If its power supply fails, everything stops. A second, identical FortiGate in an HA cluster removes that single point of failure, and firmware upgrades no longer need a full outage.

port1port1heartbeat: port7 + port8port2port2ISP203.0.113.1Outside switchFGT1-Aprimary · priority 200FGT1-Bsecondary · priority 100Inside switchLAN
  1. 1. Normally: FGT1-A is primary and owns the virtual MACs; all traffic passes through it.
  2. 2. After a failure: FGT1-B takes over the same addresses and virtual MACs and sends gratuitous ARPs, so switches update quickly.

Configure the cluster

config system ha set group-name "FGT1-HA" set mode a-p set password <ha-password> set hbdev "port7" 50 "port8" 50 set session-pickup enable set override disable set priority 200 set monitor "port1" "port2" end

Configure the same on FGT1-B with priority 100. Group name, mode and password must match. Two heartbeat links (port7, port8) avoid a split brain if one cable fails. Once the units see each other, the secondary receives the primary's configuration automatically.

Who becomes primary?

1. Connected monitored interfaces
The unit with more monitored interfaces up wins.
2. HA uptime
The unit that has been in the cluster longest (differences under 5 minutes are ignored).
3. Priority
Higher priority wins.
4. Serial number
Higher serial number wins: the final tie-breaker.
With override disabled (the default), the unit that has been up longest keeps the role, which avoids needless failovers when a repaired unit comes back. With override enabled, priority is checked before uptime, so the preferred unit always takes back the role.

What survives a failover

  • Configuration: always synchronised.
  • IP and MAC addresses: interfaces use virtual MACs, so neighbours keep their ARP entries; the new primary sends gratuitous ARPs.
  • Sessions: only with session-pickup enable. Without it, existing connections drop and users reconnect. Sessions handled by proxy-based inspection generally aren't picked up.
  • IPsec tunnels: SAs are synchronised, so tunnels normally stay up.

Check the cluster

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # get system ha status
HA Health Status: OK
Model: FortiGate-VM64
Mode: HA A-P
Group Name: FGT1-HA
...
Primary selected using:
    <2026/10/11 09:12:44> vcluster-1: FGVM0000000A is selected as the primary because it has the largest value of uptime.
...
Configuration Status:
    FGVM0000000A(updated 2 seconds ago): in-sync
    FGVM0000000B(updated 3 seconds ago): in-sync
...
Primary     : FGT1-A          , FGVM0000000A, HA cluster index = 0
Secondary   : FGT1-B          , FGVM0000000B, HA cluster index = 1
Health OK, both units in sync, and the reason the primary was chosen. (Example output, trimmed; serial numbers made up.) If the configurations are out of sync, diagnose sys ha checksum cluster compares the checksums on each unit.

Why it works this way

A firewall holds state: sessions, NAT mappings and VPN keys. Simply swapping in a spare box would drop all of it. Synchronising configuration, sessions and SAs over heartbeat links, and sharing virtual MAC addresses, lets the standby continue almost exactly where the primary stopped.

Common mistakes

  • A single heartbeat link: if it fails, both units think they are alone and both become primary (split brain).
  • Forgetting session pickup and being surprised that every connection drops on failover.
  • Enabling override without understanding it, causing a second failover when the preferred unit returns.
  • Different firmware or licences on the two units.

Key takeaways

✅ Key takeaways
  • FGCP clusters identical units with heartbeats, configuration sync and virtual MACs.
  • Active-passive is the common mode; active-active shares inspection work.
  • Election (override off): monitored interfaces, uptime, priority, serial number.
  • Session pickup keeps connections alive; get system ha status shows health and sync.

Check yourself

Predict · scenario 1

Override is disabled. FGT1-A (priority 200) reboots and returns; FGT1-B (priority 100) has been primary meanwhile. Who is primary afterwards?

Predict · scenario 2

The primary's port2 (monitored) cable is unplugged. What happens?

Predict · scenario 3

After a failover, every user has to reconnect their sessions. Which setting was missing?

FAQ

Do both units need the same model and licences?
Yes: the same model (or VM size), the same FortiOS version, and matching licences and FortiGuard subscriptions. Otherwise the cluster won't form, or the secondary can't provide the same services after a failover.
How do I manage the secondary unit?
From the primary's CLI with execute ha manage, or give each unit its own reserved management interface (ha-mgmt-status) so both can be reached directly for monitoring and upgrades.