NSE7 Part 3: High Availability, FGCP, FGSP, and Where VRRP Still Fits

NSE4 Part 10 covers FGCP fundamentals: active-passive clustering, heartbeat interfaces, virtual MAC addresses, and failover. That’s the baseline this post assumes. NSE 7 asks about the parts of HA that only come up once a cluster stops being two identical boxes in a wiring closet and starts being enterprise infrastructure: active-active load distribution, splitting a cluster’s capacity across VDOMs, and synchronizing session state between boxes that aren’t in a cluster at all.

FGCP Active-Active Load Balancing

Standard FGCP is active-passive: one unit processes traffic, the other sits idle except for heartbeat and sync traffic, ready to take over. Active-active (set mode a-a under config system ha) changes this: the primary unit still owns session setup and load-balancing decisions, but it distributes UTM processing work (content inspection, IPS, AV) across all cluster members using a weighted round-robin scheme, with the results synced back.

The load-balancing algorithm is configurable (set load-balance-all enable extends distribution beyond just UTM to include the initial session as well). What actually gets distributed depends on the cluster’s role: pure firewall/NAT sessions with no security profiles attached see comparatively little benefit from active-active, since the primary unit’s own forwarding and session-table work is not the bottleneck being relieved. The benefit is concentrated on content-inspection-heavy traffic, which is also the traffic profile where active-active most commonly gets recommended and most commonly gets misapplied to workloads that don’t actually have that profile.

The tradeoff worth internalizing for the exam: active-active adds inter-unit synchronization overhead on every packet that gets distributed, and it complicates troubleshooting, since a given session’s inspection work may have happened on a unit that isn’t the one you’re looking at. Fortinet’s own guidance, and the exam’s framing, treats active-passive as the default and active-active as a deliberate choice for UTM-heavy, throughput-constrained deployments, not a free performance upgrade to reach for by default.

Virtual Clustering

Virtual clustering is FGCP extended across VDOMs: instead of one cluster with one active and one passive unit for the whole box, each VDOM gets its own primary/secondary assignment, independently. Unit A can be primary for VDOM-1 and secondary for VDOM-2, while unit B is the mirror image. Both units process live traffic simultaneously, just for different VDOMs.

This is the direct answer to the blueprint’s “VDOM partitioning (high traffic volume)” use case: an enterprise or MSSP running several high-traffic VDOMs on a two-unit cluster can spread the actual forwarding load across both physical units under normal conditions, rather than leaving one unit fully idle until a failover. If unit A fails, unit B becomes primary for every VDOM, same as ordinary FGCP failover, just with the added step that VDOM-to-unit primary assignment needs to be planned deliberately rather than left as an emergent property of a single active/passive pair.

Virtual MAC addressing works the same way here as in standard FGCP: each VDOM’s interfaces get a virtual MAC tied to the cluster, not the physical unit, so a failover doesn’t require every downstream switch and router to relearn a new MAC via ARP. Ethernet type and sync optimization settings (config system ha → sync-config, link-failed-signal) matter more in virtual clustering than standard HA because there’s genuinely more state to keep synchronized across more active paths simultaneously.

FGSP: Session Life Support Without a Cluster

FortiGate Session Life Support Protocol (FGSP) is a fundamentally different mechanism from FGCP. FGCP builds an actual cluster: a shared virtual IP/MAC, a single management identity, synchronized configuration. FGSP does none of that. It’s standalone session synchronization between two or more FortiGates that keep their own independent identities, interfaces, and IP addresses, and simply mirror session table state to each other so that if traffic for an existing session suddenly arrives at a different unit than the one that originated it, that unit already knows about the session and can continue forwarding it without a fresh three-way handshake.

config system standalone-cluster
    set standalone-group-id 1
    set encryption enable
    set psksecret <preshared-key>
    config cluster-peer
        edit 1
            set peerip 10.10.10.2
            set peervd root
            set session-sync-filter
        next
    end
end

Why FGSP Exists When FGCP Doesn’t Cover It

FGSP is the answer to two problems FGCP structurally can’t solve, because both involve traffic legitimately arriving at two different, independently-addressed devices rather than a single clustered pair:

Asymmetric routing at Layer 2. In topologies where upstream and downstream traffic for the same session can genuinely take different physical paths through two different FortiGates (common in some ECMP or dual-uplink designs where the return path isn’t guaranteed to retrace the forward path), FGSP lets both units maintain enough shared session state that neither one drops the traffic as an unrecognized mid-stream packet. FGCP doesn’t apply here because there’s no single cluster identity to route toward in the first place; the design deliberately has two independently-reachable units.

Cloud environments. In AWS, Azure, or GCP, a floating virtual IP and virtual MAC (the mechanism FGCP failover depends on) frequently isn’t something the underlying SDN fabric will honor, since cloud networking is built around a different failover primitive (load balancer health checks, route table updates). FGSP lets two independently-addressed FortiGate-VM instances behind a cloud load balancer or in an active-active multi-AZ design stay session-aware of each other without needing a traditional Layer 2 adjacency or virtual MAC at all.

What Standalone Sync Covers, and Its Real Limits

FGSP synchronizes session table entries, but the standalone-sync coverage has real edges the exam expects you to know, not just the mechanism’s existence:

• IPsec session sync is supported but needs to be handled deliberately: for a session to fail over cleanly mid-tunnel, both peers need matching SA state, which the blueprint calls out specifically as “session synchronization encryption using IPsec tunnels”, the encrypted sync channel between the two FortiGates protecting the session data being mirrored, distinct from whatever IPsec tunnel the actual user traffic is riding.
• Layer 2 asymmetric traffic works when both units see all the relevant traffic on a shared broadcast segment; it does not turn two units on genuinely disjoint network paths into a working pair by itself.
• Cloud asymmetric traffic needs the cloud fabric’s own routing (typically a load balancer or route table) to actually be capable of sending a given flow to either unit, since FGSP synchronizes state, it doesn’t influence upstream routing decisions.
• FGSP does not synchronize configuration. Each unit needs its config applied independently, or centrally via FortiManager, since there’s no cluster-wide config sync the way FGCP provides.

Where VRRP Still Belongs

VRRP predates FGCP as an industry-standard first-hop redundancy protocol, and FortiGate supports it directly on an interface:

config system interface
    edit "port2"
        config vrrp
            edit 1
                set vrgrp 1
                set vrip 10.20.20.1
                set priority 200
            next
        end
    next
end

It’s worth being honest about why you’d choose it over FGCP rather than treating it as a legacy option nobody should touch.

FGCP requires two Fortinet devices, matching hardware where firmware compatibility matters, and dedicated heartbeat interfaces. VRRP is a standard protocol that any VRRP-speaking device can participate in, which matters in exactly one scenario the exam cares about: mixed-vendor first-hop redundancy, where a FortiGate needs to participate in a shared virtual gateway alongside a non-Fortinet device, or where an existing VRRP design (inherited from a migration, or shared with another team’s equipment) needs a FortiGate to slot into an established virtual IP rather than replace the whole redundancy model.

VRRP gives you gateway-IP failover and nothing else: no session sync, no config sync, no UTM load distribution. If the requirement is genuinely just “this IP needs to keep responding to ARP even if one box dies,” and the environment already has non-Fortinet VRRP peers or an existing design built around it, VRRP is the right tool. If the requirement is “these two FortiGates need to behave as one logical firewall,” that’s FGCP’s job, and VRRP won’t get you there no matter how it’s configured.

The Design Decision the Exam Is Actually Testing

Across all three mechanisms, the underlying question the blueprint’s HA task is built around is: given a described topology and traffic pattern, which mechanism actually applies, and why do the other two not fit? A single-site pair of matched FortiGates wanting full behavioral equivalence and automatic failover is FGCP. Two independently-addressed devices that need to stay session-aware across an asymmetric or cloud-native path is FGSP. A first-hop-redundancy requirement that has to interoperate with non-Fortinet gear is VRRP. Getting the mechanism right for the topology described is worth more marks than knowing any single mechanism’s CLI syntax in isolation.

Part 4 moves from HA to the segmentation layer underneath it: VLANs and VDOMs at the scale an enterprise design actually needs, building on the VDOM fundamentals already on this site.