High availability is often described as a pair of firewalls, but FortiGate Clustering Protocol (FGCP) is really a design for coordinated device state, failure detection and traffic continuity. The goal is to avoid a single appliance failure taking down a service. Achieving that goal requires correct links, compatible members, monitored dependencies, synchronized settings and a tested failover response. The FortiOS 7.6 Administrator exam asks candidates to understand typical FGCP operation, HA management interfaces, session synchronization, upgrades and fault scenarios.
The most important distinction is between a cluster that reports healthy members and a service that actually survives the event the business cares about. A pair may synchronize configuration and elect a primary correctly while a dependent switch, asymmetric route or unsynchronized session makes application recovery incomplete. Treat HA as an end-to-end network behavior.
Understand member roles and election behavior
FGCP clusters have member roles that determine which FortiGate manages active traffic in an active-passive deployment, with other supported arrangements available when appropriate. Configuration synchronization is intended to keep relevant settings consistent; the election process selects an operational primary according to configured criteria and member health. An administrator should learn what triggers a role change instead of assuming that the preferred unit always remains primary.
Fortinet’s 7.6 FGCP documentation emphasizes equivalent heartbeat connections and appropriate matching internal/external network attachments. Heartbeat links are not ordinary user uplinks. A lost or miswired heartbeat can make member-state decisions unreliable; deploying two devices without validating their heartbeat paths does not create safe redundancy.
In a two-member deployment, map the interface names and connected switches on both appliances. If port1 of the primary connects to an internal VLAN while port1 of the secondary connects to a different network, a promotion may route traffic to an unexpected segment. Similarly, duplicating a physical failure domain leaves an unseen common point of failure. The cabling and switching diagram is therefore a necessary operational artifact, not merely installation paperwork.
Design heartbeat and monitored-interface behavior
Heartbeat traffic carries status information that members use to assess one another. Administrators need to understand which interfaces are dedicated to it, how the links are protected from unrelated traffic and how a loss of heartbeat is interpreted. Monitoring outside or inside service-facing interfaces adds different evidence: a member can be alive and exchanging heartbeat messages while losing the network path required by the application.
Suppose the primary device keeps power and heartbeat connectivity but its WAN attachment fails. If the organization expects the secondary to take over, the monitoring and upstream routing design must recognize the failed dependency. A cluster that monitors only device liveness can remain apparently stable while internet service is unavailable. Conversely, overly aggressive failure sensitivity may trigger unnecessary role changes during a brief link disturbance.
Distinguish physical link failure, logical upstream reachability and application-layer health. A port link can be up while a provider route is broken. The design should document which condition the cluster will detect automatically, which requires separate network monitoring, and what change in role or path is expected.
Separate configuration synchronization from session continuity
Config sync distributes appropriate settings so that a promoted member can enforce the intended rules. It does not mean every packet-level detail of every session is continuously reconstructable under all conditions. Session pickup and synchronization options influence whether traffic can continue after failover, and the effect varies by protocol, state and platform resources. Fortinet documents distinct FortiGate session synchronization behavior in a related FGSP context; FGSP and FGCP should not be mislabeled as the same architecture. Always use FGCP-specific configuration for an FGCP question.
A long-lived HTTPS download, a short DNS query and a stateful VPN have different recovery requirements. Some applications can transparently reconnect when a session is lost; others may fail and require a user retry. A credible acceptance test measures relevant application outcomes, not simply the time it takes for the status page to show a new primary.
When evaluating session continuity, account for asymmetric routing and upstream switch/ARP behavior. A promoted firewall may be ready while traffic still reaches the failed unit or takes a return path that misses the new active appliance. The cluster’s configuration and the network’s forwarding convergence must be considered together.
Reach individual cluster members safely
Operational management of a cluster includes both the logical cluster entry point and supported methods for reaching a specific member. Maintenance tasks such as interface inspection, firmware verification or device hardware diagnosis may need access to the subordinate unit. FortiOS supports HA management-interface concepts for this purpose, subject to the deployed model and firmware.
Do not make the management subnet share an address plan that collides with the production forwarding path. An HA management interface should allow approved administrative access without becoming a bypass into protected traffic. If administrators can reach the cluster address but cannot reach a secondary member, check the intended management interface, addressing and allowed source path before making unrelated policy changes.
Record serial numbers, role history and installed build per member. Looking only at the logical cluster name can conceal the fact that a replacement unit is running a different software release or has an unresolved licensing issue. These details become particularly important when a failover occurs during a maintenance window.
Interpret a failover event end to end
Imagine two FortiGates protecting a branch that has an internet circuit and a private-WAN circuit. The primary appliance shuts down unexpectedly. The secondary is elected, but users report that a file-transfer session stopped and a new browser tab connects normally. The first observation may indicate a session-recovery limitation while the second shows new session handling. Diagnose the two separately.
The event timeline should include the health failure, member role change, interface and routing changes, ARP or adjacency convergence and application reconnection. Logs from both cluster members and upstream devices may be needed. If a firewall log says a session was allowed after failover, that does not prove that the remote server returned traffic through the same path.
An alternative scenario is a heartbeat disruption without loss of the primary’s actual forwarding capability. This creates a different risk: multiple devices may attempt conflicting active roles or the cluster may report an unexpected state. The solution is to repair heartbeat design and verify member state, not to create broad allow policies to hide the symptom.
Upgrade a cluster without assuming zero downtime
HA upgrades are a managed maintenance operation. The upgrade route must be supported for the existing firmware build, members should be compatible, and configuration backup/restore must be prepared before work begins. A rolling approach can reduce disruption under supported conditions, but actual session and application behavior depends on topology, traffic type and configured HA options.
Before changing firmware, record the current primary, all members’ builds, health status, heartbeat reliability, management access and business critical traffic. Maintain the recoverable configuration source and an escalation path. Afterward, confirm synchronized cluster status and verify the routes, policies, logs, VPNs and application behavior that matter at the site. An apparently successful firmware version display does not substitute for those tests.
Fortinet’s active exam scope includes HA firmware upgrades alongside session sync and ordinary cluster operation. An exam preparation plan should therefore include the decision about when not to proceed—for example, when a member is already unhealthy, a rollback configuration is missing, or the upstream network lacks a recoverable alternate path.
Distinguish HA from WAN and VPN redundancy
Two firewalls can protect against appliance failure but not automatically against a shared fiber cut or remote route failure. SD-WAN load steering, IPsec tunnel redundancy and FGCP are complementary tools with different fault domains. If a branch has redundant firewalls but only one physical upstream switch, it still has a switching single point of failure. If it has two tunnels over one ISP, it may have protocol redundancy without transport diversity.
Choose a realistic failure model and test each layer independently. First test member failure under a controlled window. Next validate individual physical uplinks and route recovery. If the service depends on a site-to-site VPN, validate encrypted connectivity after role change. Comparing failures shows which availability mechanism is actually responsible for preserving access.
A robust design statement is specific: “A member failure should result in the surviving unit accepting new sessions within the approved recovery target, and these named applications must be retested for their session behavior.” That is more defensible than an unspecified promise of uninterrupted operation.
Study for operational decisions rather than a healthy status icon
The practical questions to rehearse are why a particular member was elected, which failure causes a role change, how heartbeat differs from service-interface health, which sessions can recover, and how an administrator reaches and maintains both members. These decisions connect deployment, routing, VPN and logging domains rather than standing alone.
Review topology drawings or an authorized lab’s observed log/role evidence. For each scenario, name a hypothesis and the cluster state that would confirm or refute it. Do not claim a real failover was tested unless the exercise was actually performed. With that discipline, FGCP administration becomes an exercise in controlled fault handling rather than memorization of the HA wizard.