FortiGate HA Methods; FGSP vs FGCP

By Manny Fernandez

March 21, 2026

FortiGate HA Methods; FGSP vs FGCP

Choosing between FGCP (FortiGate Clustering Protocol) and FGSP (FortiGate Session Life Support Protocol) is essentially a choice between a tightly coupled cluster and a loosely coupled synchronization group.

While FGCP is the standard HA most engineers use, FGSP is the power user tool for complex routing environments and massive scale.

FGCP – The “Standard” Cluster

FGCP is designed for high availability within a single data center or rack. It uses a proprietary heartbeat to elect a leader.

Best Use Cases

* Standard enterprise internet edge where a single VIP gateway is needed.
* Environments where you want a set it and forget it configuration (syncing everything from firewall rules to OSPF settings).

The Gotchas

Layer 2 Dependency – If your heartbeats or data interfaces aren’t on the same VLAN/broadcast domain, FGCP will fail.
Split-Brain – If the heartbeat link fails but the data links stay up, both units may try to become “Primary,” causing IP and MAC address conflicts.
Failover Time – While fast (sub-second), it relies on Gratuitous ARPs (GARPs) to update the MAC tables of upstream switches.

FGSP: The “External Load Balancer” Hero

FGSP does not try to be a cluster. It only cares about **sharing the session table**. It is often described as a Load Balancer Sandwich protocol.

Best Use Cases

ECMP (Equal-Cost Multi-Path) – When you have upstream routers using BGP/OSPF to load-balance traffic across two firewalls simultaneously.
Asymmetric Routing – Essential if you cannot guarantee that the return traffic will hit the same firewall that saw the original request.
SDN/Cloud – Often used in virtual environments where Virtual MACs (FGCP) are not supported by the underlying hypervisor or cloud fabric (e.g., certain Azure/AWS designs).

The Gotchas

Configuration Overhead – Because it doesn’t sync local identifiers (IPs/BGP), you must manage the routing and interface IPs manually on each box (or use FortiManager).
UTM Limitations – Proxy-based inspection (Web Filter, Antivirus in proxy mode) generally cannot failover in FGSP. You must use Flow-based inspection for stateful session pickup.
NAT Complexity – Managing NAT pools across two independent units requires careful planning to ensure return traffic can find its way back to the correct public IP.

Technical Nuances to Watch Out For

Session-Pickup-Delay – In FGSP, it is highly recommended to use set session-pickup-delay enable. This prevents the sync of short-lived sessions (like DNS queries), which can drastically reduce the CPU load on your sync interfaces.

The “FGCP over FGSP” Design – In massive Tier-1 environments, you can actually run an FGCP cluster at Site A and another FGCP cluster at Site B, and use FGSP to sync sessions between the two clusters. This provides Site-Level redundancy.

Standalone Config Sync – FGSP does not sync configuration by default. You must explicitly enable it:

config system ha
set standalone-config-sync enable
end

Hardware Offloading – Be aware that sessions offloaded to NP (Network Processor) chips must be handled carefully. If a session is offloaded, the CPU might not “see” it to sync it until the session closes or the sync is forced.

FortiGate HA Methods; FGSP vs FGCP

FGCP – The “Standard” Cluster

Best Use Cases

The Gotchas

FGSP: The “External Load Balancer” Hero

Best Use Cases

The Gotchas

Technical Nuances to Watch Out For

Recent posts