Links and synchronizes 2 – 4 FortiGate devices to create a cluster for redundancy.
Active-Passive:
One FortiGate operates as the primary device and handles the process of traffic.
If the primary device fails, the secondary device will assume the role as the primary device and starts processing traffic.
Active-Active:
All FortiGate devices are operation for processing the traffic.
The FortiGate Clustering Protocol (FCP) is used for discovering members, primary device election process, data synchronization with other devices within the cluster, and monitor member health.
All members are required to have the same:
Firmware version
Model of device
Licensing information
Use the same HA group ID, group name, password and heartbeat interface configurations.
Ensure the heartbeat interfaces can see each other.
If possible, use at least 2 heartbeat interfaces (up to a total of 8 interfaces)
Disable DHCP and PPPoE.
This FortiGate within the cluster broadcast hello packets to other members within the cluster for discovery and monitoring.
The primary FortiGate synchronizes its configurations, FIB entries, DHCP leases, ARP table, FortiGuard definitions, IPsec tunnel SAs and Sessions with other members.
This device also broadcast hello packets for performing member discovery and monitoring.
It synchronizes its data from the primary device within the cluster.
Monitors the health status of the primary FortiGate in the cluster.
IP addresses are automatically assigned to heartbeat interfaces within a cluster based on the serial number of the FortiGate devices.
The highest IP address is assigned to the FortiGate with the highest serial number. For instance, 169.254.0.1 is assigned to the device with the highest serial number.
If a failover should occur, members of a cluster keeps their heartbeat IP addresses regardless of their role in the cluster.
The heartbeat addresses are used to identify members and synchronize data.
When setting up heartbeat interfaces, either connect the interfaces to a dedicate switch or to the same VLAN on a switch.
Heartbeat interfaces should be a physical interface.
This type of interfaces are commonly used for link failover.
Monitored interfaces should be those which are critical for user traffic such as physical links, redundant links, and Link Aggregation Group (LAG).
Before configuring monitored interfaces, sure heartbeat interfaces are up.
When a new FortiGate joins the cluster, the primary firewall compares the checksum of this configurations to the newly joined FortiGate.
If the checksum values are different, the primary FortiGate sends its configurations to the new firewall in the cluster.
If a change is made on the primary firewall, it sends only the change and not the entire configurations to the other firewalls within the cluster.
Once the checksum of the configuration files on the primary and secondary firewall is matched, the cluster is synchronized.
If the checksum is not the same after 5 attempts to synchronize, the secondary firewall downloads the entire configuration from the primary firewall.
The following configurations are not synchronized between devices within a cluster:
HA management interface configurations
In-band HA management interfaces
HA override
HA device priority
HA virtual cluster priority
Device hostnames
Ping server HA priorities
FortiGate synchronizes TCP sessions.
Does not always synchronize UDP and ICMP session as this is an optional feature.
SIP session are inspected by the SIP ALG.
All local sessions are not synchronized.
FortiGate synchronizes IPsec (IKE and IPsec SAs) and SSL VPN web mode (authentication information).
FortiGate does not synchronize SSL VPN tunnel mode users.
Device failover – This occurs when the secondary device is no longer receiving hello packets from the primary device within the cluster.
Link failover – This occurs when one or more monitored interfaces goes down.
Remote link failover - This occurs when one or more interfaces are monitored using the link health monitor.
Memory-based failover – This occurs when the memory of the primary device has exceeded the configured threshold and monitoring period.
SSD failover – This occurs when the FortiOS detects errors within the SSD.
Configure failover time:
config system ha
set hb-interval <1 - 20> //number of heartbeats intervals
set hb-interval-in-milliseconds 100ms | 10ms //heartbeat intervals
set hb-lost-threshold <1 - 60> //number of failed heartbeats before failover occurs
Configure one or more monitored interface:
config system ha
set monitor <interface 1> <interface 2>
end
Configure link health monitor
config system link-monitor
edit "port1-ha"
set srcintf "port1"
set server "4.2.2.1" "4.2.2.2"
set ha-priority 10 //dead link norminal penalty
next
end
Configure HA settings
config system ha
set pingserver-monitor-interface port1 //perform remote link failove on port 1
set pingserver-failover-threshold 5 //elect a new primary if the accumulated penalty reaches this threshold
set pingserver-secondary-force-reset enable //elect a new primary again at the end of the flip timeout
set pingserver-flip-timeout 30 //the next primary election is in 30 minutes
Configuring memory-based failover:
config system ha
set memory-based-failover enable //enables the memory-based failover feature
set memory-fa
end
set memory-failover-monitor-period 30
set memory-failover-sample-rate 2
end
Configuring SSD failover:
config system ha
set ssd-failover enable
end
When a cluster is created, the primary FortiGate is assigned a virtual MAC addresses on each interface.
The HA heartbeat interfaces are not assigned virtual MAC address.
Whenever a failover occurs, the new primary device uses the virtual machine as the previous primary firewall.
This enables a FortiGate device with multiple VDOMs to be the primary for some VDOMs and the secondary for other VDOMs.
The HA cluster must contains only 2 FortiGate devices.
For instance FortiGate 1 contains 3 VDOMs, VDOM_A (primary), VDOM_B (primary) and VDOM_C (secondary). FortiGate 2 contains 3 VDOMs, VDOM_A (secondary), VDOM_B (secondary) and VDOM_C (primary).
Go to, System > HA
Go to, Dashboard > Status
Get system ha status
Check the cluster checksum:
diagnose sys ha checksum show
diagnose sys ha checksum cluster
diagnose sys ha checksum recalculate