Guide · free to read

FGCP high availability: how FortiGate decides which unit is primary.

Exam NSE4_FGT_AD-7.6 Written and maintained by Grindstone Prep Last updated 16 September 2026

A FortiGate HA cluster looks simple from the outside — two boxes, one active, one standing by — but the two questions that actually matter during an incident are less simple: which unit will become primary, and why did the last failover happen at all? Both questions have precise, documented answers. Guessing at either one during a live outage costs time you don’t have.

What FGCP is, and what it requires

FGCP (FortiGate Clustering Protocol) is Fortinet’s proprietary HA clustering protocol. A cluster is two or more FortiGates that negotiate among themselves to form a single logical unit, with one member acting as primary and the rest as subordinates. Every member of the cluster must be the same FortiGate model and run the same firmware — HA negotiation depends on it, and a mismatched member will not properly join.

The heartbeat: how cluster members know each other is still there

Cluster members confirm each other’s status over dedicated HA heartbeat interfaces, using hello packets sent constantly at a configurable interval. Heartbeat traffic runs as Layer 2 Ethernet frames — not ordinary IP packets — carried under Fortinet-specific EtherTypes rather than a standard IP protocol number, which is why heartbeat links are normally wired back-to-back or through a dedicated switch rather than routed through the rest of the network.

The defaults that decide how fast a dead unit gets noticed:

• Heartbeat interval: 200 ms by default (hb-interval defaults to 2, in units of 100 ms).
• Lost threshold: 20 consecutive missed heartbeats by default (hb-lost-threshold).
• Multiply those together and the default time to detect a failed unit is about 4 seconds. Some platforms support a 10 ms heartbeat interval instead of the 100 ms default, which — combined with a lower lost threshold — can bring detected failover time under 50 ms; that’s a deliberate trade against heartbeat traffic volume, not a free upgrade, so it’s worth understanding before turning it up.

Fortinet recommends at least two dedicated heartbeat interfaces (wired directly between the two units, or through dedicated switches for clusters larger than two members) rather than one — a single heartbeat link is a single point of failure for the mechanism that’s supposed to prevent single points of failure. A cluster supports up to eight heartbeat interfaces, each with a configurable priority (0–512, default 50); when priorities tie, the interface with the lowest index handles the traffic.

Which unit becomes primary, and why

This is the part worth knowing cold, because it’s the difference between “the cluster did what I expected” and “the cluster did something and I don’t know why.” FGCP compares candidate primary units against an ordered list of criteria, and the order changes depending on one setting: HA override.

With override disabled (the default):

1. Monitored interfaces — a unit with more failed monitored interfaces than another cannot become primary, full stop. This is checked first and it’s absolute, not a tiebreaker.
2. HA uptime (“Age”) — if two units’ HA uptime differs by more than five minutes (300 seconds), the one that’s been up longer wins. Inside that five-minute window, uptime is treated as a tie and the comparison falls through to the next criterion.
3. Device priority — configurable per unit, 0–255, default 128 on every unit out of the box (which is exactly why, with a factory-default cluster, priority rarely decides anything: both units start tied).
4. Serial number — the final tiebreaker, and the one that actually decides primary selection on a freshly built, all-defaults cluster, since monitored interfaces, uptime, and priority are all equal in that scenario.

With override enabled, priority moves up: the order becomes monitored interfaces, then device priority, then uptime, then serial number. Override exists specifically so a preferred unit (a newer or more capable box, say) can reliably reclaim primary status after it rejoins the cluster, instead of losing out to whichever unit happened to boot first. That convenience has a cost worth knowing about: override enabled makes a cluster more prone to failing back and forth (a rejoining preferred unit can immediately take over primary again), so it’s a deliberate choice, not a default-safe one.

What actually triggers a failover

“Failover” isn’t one event — FGCP watches for several distinct conditions:

• Device failover — the active unit loses power or otherwise disappears entirely. There’s nothing to configure here; a healthy subordinate takes over automatically because the primary simply stops sending heartbeats.
• Link failover — a monitored interface goes down. Only interfaces you’ve explicitly added to interface monitoring count; an unmonitored interface failing does not trigger a failover by itself, which is a common source of “why didn’t it fail over?” confusion.
• Remote link failover — for a failure on a link that isn’t directly attached to a cluster member (for example, a switch between a cluster interface and the rest of the network), remote link monitoring extends the same idea one hop further out.
• SSD failure — on models with the option, set ssd-failover enable triggers a failover if a monitored SSD fails.
• Memory-based failover — if memory utilization stays above a configured threshold for long enough (checked at a configurable sample rate), FGCP treats sustained memory exhaustion as a failure condition and fails over rather than waiting for the box to become unresponsive.

Session continuity during a failover

Whether an in-progress connection survives a failover is a separate setting from the failover mechanism itself: session-pickup. With session-pickup enabled, existing TCP sessions are synchronized to the subordinate ahead of time, so a failover doesn’t drop them. Without it, active sessions are lost and have to be re-established after the new primary takes over — the cluster still fails over correctly either way, but what the end user experiences during that failover is very different.

The diagnostic habit worth building

When a cluster does something unexpected — an unplanned failover, a unit you didn’t expect becoming primary, a failback you didn’t want — get system ha status and diagnose sys ha dump-by group are the first two commands worth reaching for. The HA status output specifically keeps a record of why the current primary was selected, which turns “the cluster did something weird” into a specific, checkable answer instead of a guess.

Sources

Every mechanism and every default above was checked against one of these pages of the FortiOS 7.6.0 Administration Guide. They are free to open, with no account, and checking them is the point of listing them:

• FGCP — the overview: cluster membership requirements, what the heartbeat is for, and the failover scenarios named at a high level.
• HA heartbeat interface — heartbeat mechanics: the Layer 2 EtherTypes, the default interval and lost threshold, and the interface count and priority defaults.
• HA primary unit selection criteria — the ordered criteria, with and without override, and what resets a unit’s HA uptime to zero.
• Failover protection — device, link, SSD-triggered and memory-based failover, and failover timing.

Every practice question we publish carries the Fortinet page it was written from, the same way this guide does. You can see fifteen of them, scored by blueprint domain, in the free readiness assessment — it is drawn from the same NSE 4 bank this guide’s subject belongs to, no account, nothing recorded. How they are written is set out on the methodology page, and the catalog says which exams are on sale today.

← All guides