Introduction to FortiGate 7000F FGCP HA

FortiGate 7000F supports active-passive FortiGate Clustering Protocol (FGCP) HA between two (and only two) identical FortiGate 7000Fs. You can configure FortiGate 7000F HA in much the same way as any FortiGate HA setup except that only active-passive HA is supported.

In Multi VDOM mode, virtual clustering is supported. Virtual clustering is not supported in Split-Task VDOM mode. Split-Task VDOM mode supports standard FGCP HA.

You must select two interfaces in each chassis to be HA heartbeat interfaces. You can choose from any two of the 100Gbps M1 and M2 interfaces or the 25Gbps M3 and M4 interfaces of the FIMs in slot 1 and 2. You cannot use LAGs for HA heartbeat interfaces. In most cases, using the M3 or M4 interfaces should provide enough bandwidth so the recommended configuration is to use the M3 interface of the FIM in slot1 and the M3 interface of the FIM in slot 2 for HA heartbeat interfaces.

To set up HA heartbeat communication between two FortiGate 7000F chassis you can connect the M3 interface of the FIM in slot 1 of one chassis to the M3 interface of the FIM in slot 1 of the second chassis and repeat these connections for the M3 interface of the FIM in slot 2 of each chassis. These can be direct cable connections or you can use switches.

HA heartbeat traffic uses VLANs. In the HA configuration, the hbdev-vlan-id option sets the VLAN for the first HA heartbeat interface and the hbdev-second-vlan-id sets the VLAN ID of the second HA heartbeat interface. These VLAN IDs must be different. If you use switches to connect the HA heartbeat interfaces the switches must allow VLAN-tagged packets.

FortiGate 7000F FGCP HA also requires separating session synchronization traffic from HA heartbeat traffic. FortiGate 7000F HA supports configuring one or two interfaces in each chassis to be session synchronization interfaces. The session synchronization interfaces can be physical interfaces or LAGs and your configuration can include both.

The recommended session synchronization configuration is to add two 100Gbps FIM management interfaces to a LAG and configure the HA session-sync-dev option to use this LAG for session synchronization. The recommended interfaces to use for this LAG are the M1 interface of the FIM in slot1 and the M1 interface of the FIM in slot 2. You should use a switch to connect the LAGs in the two chassis.

Using LAGs for session sync interfaces has two benefits: Session sync traffic is load balanced between the interfaces in the LAG. On the FortiGate 7000F platform, if you configure individual interfaces for session sync, no load balancing takes place. There is only one active interface at a time. If one of the interfaces in the LAG fails, in most cases no sessions are lost. Traffic continues to be processed by the LAG, it just contains fewer active interfaces. If you configure individual interfaces for session sync, if the active interface fails, the system takes a short time to re-assign the IP address from the failed interface to the remaining active interface. Some sessions might not be synced to the secondary chassis during this transition.

Session synchronization traffic does not use VLANs. If the HA heartbeat and session synchronization interfaces are connected to the same switch, make sure HA heartbeat and session synchronization traffic is separated.

To successfully form an FGCP HA cluster, both FortiGate 7000Fs must be operating in the same VDOM mode (Multi or Split-Task). You can change the VDOM mode after the cluster has formed, but this will disrupt traffic.

As part of the FortiGate 7000F HA configuration, you assign each of the FortiGate 7000Fs in the HA cluster a chassis ID of 1 or 2. The chassis IDs just allow you to identify individual FortiGate 7000Fs and do not influence primary unit selection.

If both FortiGate 7000Fs in a cluster are configured with the same chassis ID, both chassis begin operating in HA mode without forming a cluster. A message similar to the following is displayed on the CLI console of both devices: HA cannot be formed because this box's chassis-id 1 is the same from the HA peer 'F7CF1ATB20000014' chassis-id 1. As well, a log message similar to the following is created: Jan 29 16:29:46 10.160.45.70 date=2021-01-29 time=16:29:51 devname="CH-02" devid="F7CF1ATB20000014" slot=1 logid="0108037904" type="event" subtype="ha" level="error" vd="mgmt-vdom" eventtime=1580344192162305962 tz="-0800" logdesc="Device set as HA primary" msg="HA group detected chassis-id conflict" ha_group=7 sn="F7CF1ATB20000014 chassis-id=1" You can resolve this issue by logging into one of the FortiGate 7000Fs and changing its Chassis ID to 2. When this happens, the two chassis will form a cluster.

Example FortiGate 7000F HA configuration

In a FortiGate 7000F FGCP HA configuration, the primary FortiGate 7000F processes all traffic. The secondary FortiGate 7000F operates in hot standby mode. The FGCP synchronizes the configuration, active sessions, routing information, and so on to the secondary FortiGate 7000F. If the primary FortiGate 7000F fails, traffic automatically fails over to the secondary.