Fortinet Document Library

Version:

Version:

Version:

Version:


Table of Contents

FortiGate-7000 Handbook

Download PDF
Copy Link

Primary FortiGate-7000 selection

Once two FortiGate-7000s recognize that they can form a cluster, they negotiate to select a primary FortiGate-7000. Primary FortiGate-7000 selection occurs automatically based on the selection criteria shown in the diagram below. After the cluster selects the primary FortiGate-7000, the other FortiGate-7000 becomes the secondary.

Negotiation and primary FortiGate-7000 selection also takes place if the one of the criteria for selecting the primary FortiGate-7000 changes. For example, an interface can become disconnected or an FIM can fail. After this happens, the cluster can renegotiate to select a new primary FortiGate-7000 using the same selection criteria.

If there are no FIM failures and if you haven't configured any settings to influence primary FortiGate-7000 selection, the FortiGate-7000 with the highest serial number becomes the primary FortiGate-7000.

This section highlights some aspects of primary FortiGate-7000 selection. For more details about how this works, see Primary unit selection.

Age and primary FortiGate-7000 selection

Age (or uptime) is also a factor in primary FortiGate-7000 selection. Normally when two FortiGate-7000s start, their uptimes are similar and do not affect primary FortiGate-7000 selection. However, during operation, if one of the FortiGate-7000s goes down the other will have a much higher age or uptime and will be selected as the primary FortiGate-7000 before checking priority and serial number.

In some cases, age differences can result in the wrong FortiGate-7000 becoming the primary FortiGate-7000. For example, if the FortiGate-7000 set to a high priority reboots, it will have a lower age than other FortiGate-7000 when it rejoins the cluster. Since age takes precedence over priority it will become the secondary FortiGate-7000 when it rejoins the cluster.

One way to resolve this issue is to reboot both FortiGate-7000s in the cluster at the same time to reset the age of both FortiGate-7000s. However, doing this would disrupt traffic. Instead you can use the following command to reset the age of one the primary FortiGate-7000 to zero.

diagnose sys ha reset-uptime

The primary FortiGate-7000 now has the lowest age and the other FortiGate-7000 will have the highest age and can then become the primary FortiGate-7000.

Note The diagnose sys ha reset-uptime command should only be used as a temporary solution. You should reboot the FortiGate-7000s during a maintenance window to permanently bring their ages back together.

Device priority and primary FortiGate-7000 selection

In some situations you may want to select a FortiGate-7000 to always become the primary FortiGate-7000. You can do this by setting its device priority higher. You can change the device priority of an FIM from the System > HA GUI page or by using the following command:

config system ha

set priority <number>

end

The default priority is 128.

During negotiation, the FortiGate-7000 with the highest device priority becomes the primary FortiGate-7000.

Override and primary FortiGate-7000 selection

You can enable override to select a FortiGate-7000 to always becomes the primary FortiGate-7000. Enabling override changes how primary select works.

FIM or FPM failure and primary FortiGate-7000 selection

If an FIM or an FPM fails, the FortiGate-7000 cluster negotiates to select a new Primary FortiGate-7000 and the FortiGate-7000 with the most operating FIMs becomes the primary FortiGate-7000.

You can also configure board failover tolerance to control how a FortiGate-7000 cluster responds to an FIM failure.

config system ha

set board-failover-tolerance <tolerance>

end

Where <tollerance> can be from 0 to 3. A tolerance of 0 (the default) means that if a single FIM or FPM fails in the primary FortiGate-7000, a failover occurs and the FortiGate-7000 with the fewest failed modules becomes the new primary FortiGate-7000. Higher failover tolerances mean that more module failures must occur before an FGCP failover occurs.

Verifying primary FortiGate-7000 selection

You can use the get system ha status command to verify which FortiGate-7000 has become the primary FortiGate-7000. The command output shows which FortiGate-7000 is currently operating as the primary FortiGate-7000. The following command output excerpt shows that the FortiGate-7000 labeled as chassis 2 has become the primary (master) FortiGate-7000:

get system ha status
Master selected using:
HA Health Status: OK
Model: FortiGate-7000E
Mode: HA A-P
Group: 7
Debug: 0
Cluster Uptime: 0 days 16:42:5
... Master: CH16 , FG74E83E16000016, cluster index = 0 Slave : FG74E83E16000015, FG74E83E16000015, cluster index = 1 number of vcluster: 1 vcluster 1: work 10.101.11.20 Master: FG74E83E16000016, operating cluster index = 0 Slave : FG74E83E16000015, operating cluster index = 1 Chassis Status: (Local chassis ID: 2) Chassis ID 1: Slave Chassis Slot ID 1: Master Slot Slot ID 2: Slave Slot Chassis ID 2: Master Chassis Slot ID 1: Master Slot Slot ID 2: Slave Slot

Primary FortiGate-7000 selection

Once two FortiGate-7000s recognize that they can form a cluster, they negotiate to select a primary FortiGate-7000. Primary FortiGate-7000 selection occurs automatically based on the selection criteria shown in the diagram below. After the cluster selects the primary FortiGate-7000, the other FortiGate-7000 becomes the secondary.

Negotiation and primary FortiGate-7000 selection also takes place if the one of the criteria for selecting the primary FortiGate-7000 changes. For example, an interface can become disconnected or an FIM can fail. After this happens, the cluster can renegotiate to select a new primary FortiGate-7000 using the same selection criteria.

If there are no FIM failures and if you haven't configured any settings to influence primary FortiGate-7000 selection, the FortiGate-7000 with the highest serial number becomes the primary FortiGate-7000.

This section highlights some aspects of primary FortiGate-7000 selection. For more details about how this works, see Primary unit selection.

Age and primary FortiGate-7000 selection

Age (or uptime) is also a factor in primary FortiGate-7000 selection. Normally when two FortiGate-7000s start, their uptimes are similar and do not affect primary FortiGate-7000 selection. However, during operation, if one of the FortiGate-7000s goes down the other will have a much higher age or uptime and will be selected as the primary FortiGate-7000 before checking priority and serial number.

In some cases, age differences can result in the wrong FortiGate-7000 becoming the primary FortiGate-7000. For example, if the FortiGate-7000 set to a high priority reboots, it will have a lower age than other FortiGate-7000 when it rejoins the cluster. Since age takes precedence over priority it will become the secondary FortiGate-7000 when it rejoins the cluster.

One way to resolve this issue is to reboot both FortiGate-7000s in the cluster at the same time to reset the age of both FortiGate-7000s. However, doing this would disrupt traffic. Instead you can use the following command to reset the age of one the primary FortiGate-7000 to zero.

diagnose sys ha reset-uptime

The primary FortiGate-7000 now has the lowest age and the other FortiGate-7000 will have the highest age and can then become the primary FortiGate-7000.

Note The diagnose sys ha reset-uptime command should only be used as a temporary solution. You should reboot the FortiGate-7000s during a maintenance window to permanently bring their ages back together.

Device priority and primary FortiGate-7000 selection

In some situations you may want to select a FortiGate-7000 to always become the primary FortiGate-7000. You can do this by setting its device priority higher. You can change the device priority of an FIM from the System > HA GUI page or by using the following command:

config system ha

set priority <number>

end

The default priority is 128.

During negotiation, the FortiGate-7000 with the highest device priority becomes the primary FortiGate-7000.

Override and primary FortiGate-7000 selection

You can enable override to select a FortiGate-7000 to always becomes the primary FortiGate-7000. Enabling override changes how primary select works.

FIM or FPM failure and primary FortiGate-7000 selection

If an FIM or an FPM fails, the FortiGate-7000 cluster negotiates to select a new Primary FortiGate-7000 and the FortiGate-7000 with the most operating FIMs becomes the primary FortiGate-7000.

You can also configure board failover tolerance to control how a FortiGate-7000 cluster responds to an FIM failure.

config system ha

set board-failover-tolerance <tolerance>

end

Where <tollerance> can be from 0 to 3. A tolerance of 0 (the default) means that if a single FIM or FPM fails in the primary FortiGate-7000, a failover occurs and the FortiGate-7000 with the fewest failed modules becomes the new primary FortiGate-7000. Higher failover tolerances mean that more module failures must occur before an FGCP failover occurs.

Verifying primary FortiGate-7000 selection

You can use the get system ha status command to verify which FortiGate-7000 has become the primary FortiGate-7000. The command output shows which FortiGate-7000 is currently operating as the primary FortiGate-7000. The following command output excerpt shows that the FortiGate-7000 labeled as chassis 2 has become the primary (master) FortiGate-7000:

get system ha status
Master selected using:
HA Health Status: OK
Model: FortiGate-7000E
Mode: HA A-P
Group: 7
Debug: 0
Cluster Uptime: 0 days 16:42:5
... Master: CH16 , FG74E83E16000016, cluster index = 0 Slave : FG74E83E16000015, FG74E83E16000015, cluster index = 1 number of vcluster: 1 vcluster 1: work 10.101.11.20 Master: FG74E83E16000016, operating cluster index = 0 Slave : FG74E83E16000015, operating cluster index = 1 Chassis Status: (Local chassis ID: 2) Chassis ID 1: Slave Chassis Slot ID 1: Master Slot Slot ID 2: Slave Slot Chassis ID 2: Master Chassis Slot ID 1: Master Slot Slot ID 2: Slave Slot