Fortinet black logo

FGCP - FortiGate Clustering Protocol

6.4.0
Copy Link
Copy Doc ID 23a6ef88-6864-11ea-9384-00505692583a:564712
Download PDF

FGCP - FortiGate Clustering Protocol

In an active-passive HA configuration, the FortiGate Clustering Protocol (FGCP) provides failover protection, whereby the cluster can provide FortiGate services even when one of the cluster units loses connection. FGCP is also a Layer 2 heartbeat that specifies how FortiGate units communicate in an HA cluster and keeps the cluster operating.

Note

You cannot mix FGCP and SLBC clusters in the same chassis.

The FortiGate's HA Heartbeat listens on ports TCP/703, TCP/23, or ETH layer 2/8890.

Virtual MAC addresses

FGCP assigns virtual MAC addresses to each primary unit interface in an HA cluster. Virtual MAC addresses are in place so that, if a failover occurs, the new primary unit interfaces will have the same MAC addresses as the failed primary unit interfaces. If the MAC addresses were to change after a failover, the network would take longer to recover because all attached network devices would have to learn the new MAC addresses before they could communicate with the cluster.

If a cluster is operating in Transparent mode, FGCP assigns a virtual MAC address for the primary unit management IP address. Since you can connect to the management IP address from any interface, all of the FortiGate interfaces appear to have the same virtual MAC address.

When a cluster starts up, after a failover, the primary unit sends gratuitous ARP packets to update the switches connected to the cluster interfaces with the virtual MAC address. The switches update their MAC forwarding tables with this MAC address. As a result, the switches direct all network traffic to the primary unit. Depending on the cluster configuration, the primary unit either processes this network traffic itself or load balances the network traffic among all of the cluster units.

You cannot disable sending gratuitous ARP packets, but you can change the number of packets that are sent (1-60 ARP packets) by entering the following command:

config system ha

set arps <integer>

end

You can change the time between ARP packets (1-20 seconds) by entering the following command:

config system ha

set arps-interval <integer>

end

Assigning virtual MAC addresses

Virtual MAC addresses are determined based on the following formula:

00-09-0f-09-<group-id_hex>-<vcluster_integer><idx>

where:

  • <group-id_hex>: The HA group ID for the cluster converted to hexadecimal. The table below lists some example virtual MAC addresses set for each group ID:

    Integer group ID

    Hexadecimal group ID

    0

    00

    1

    01

    2

    02

    3

    03

    ...

    ...

    10

    0a

    11

    0b

    ...

    ...

    63

    3f

    ...

    ...

    255

    ff

  • <vcluster_integer>: This value is 0 for virtual cluster 1 and 2 for virtual cluster 2. If virtual domains are not enabled, HA sets the virtual cluster to 1 and by default all interfaces are in the root virtual domain. Including virtual cluster and virtual domain factors in the virtual MAC address formula means that the same formula can be used whether or not virtual domains and virtual clustering is enabled.

  • <idx>: The index number of the interface. In NAT mode, interfaces are numbered from 0 to x (where x is the number of interfaces). The interfaces are listed in alphabetical order on the GUI and CLI. The interface at the top of the interface list is first in alphabetical order by name and has an index of 0. The second interface in the list has an index of 1 and so on. In Transparent mode, the index number foe the management IP address is 0.

Every FortiGate unit physical interface has two MAC addresses: the current hardware address and the permanent hardware address. The permanent hardware address cannot be changed, as it is the actual MAC address of the interface hardware. The current hardware address can be changed, but only when a FortiGate unit is not operating in HA. For an operating cluster, the current hardware address of each cluster unit interface is changed to the HA virtual MAC address by the FGCP.

You cannot change an interface MAC address and you cannot view MAC addresses from the system interface CLI command.

You can use the get hardware nic <interface_name_str> (or diagnose hardware deviceinfo nic <interface_str>) command to display both MAC addresses for any FortiGate interface. This command displays hardware information for the specified interface, including the current hardware address (as Current_HWaddr) and the permanent hardware address (as Permanent_HWaddr). For some interfaces, the current hardware address is displayed as MAC.

Failover protection

FGCP supports three kinds of failover protection:

  1. Device failover: Automatically replaces a failed device and restarts traffic flow with minimal impact on the network. All subordinate units in an active-passive HA cluster are constantly waiting to negotiate to become primary units. Only the heartbeat packets sent by the primary unit keep the subordinate units from becoming primary units. Each received heartbeat packet resets negotiation timers in the subordinate units. If this timer is allowed to run out because the subordinate units do not receive heartbeat packets from the primary unit, the subordinate units assume that the primary unit has failed, and negotiate to become primary units themselves. The default time interval between HA heartbeats is 200 ms.

  2. Link failover: Maintains traffic flow if a link fails. In this case, the primary unit does not stop operating, and therefore participates in the negotiation of selecting a new primary unit. The old primary unit then joins the cluster as a subordinate unit. Furthermore, any subordinate units with a link failure are unlikely to become the primary unit in future negotiations.

  3. Session failover: With session failover (also called session pickup) enabled, the primary unit informs the subordinate units of changes to the primary unit connection and state tables, keeping the subordinate units up-to-date with the traffic currently being processed by the cluster. This helps new primary units resume communication sessions with minimal loss of data, avoiding the need to restart active sessions.

Synchronization of configurations

The FGCP uses a combination of incremental and periodic synchronization to make sure that the configuration of all cluster units is synchronized to that of the primary unit. However, there are certain settings that are not synchronized between cluster units:

  • HA override

  • HA device priority

  • The virtual cluster priority

  • The FortiGate unit host name

  • The HA priority setting for a ping server (or dead gateway detection) configuration

  • The system interface settings of the HA reserved management interface

  • The HA default route for the reserved management interface, set using the ha-mgmt-interface-gateway option of the config system ha command.

You can disable configuration synchronization by entering the following command:

config system ha

set sync-config disable

end

The command execute ha synchronize can be used to perform a manual synchronization.

The FGCP heartbeat operates on TCP port 703 with an independent IP address not assigned to any FortiGate interface. You can create an FGCP cluster of up to four FortiGate units. Below is an example of FGCP used to create an HA cluster installed between an internal network and the Internet.

FGCP HA provides a solution for two key requirements of critical enterprise networking: enhanced reliability and increased performance, through device, link, and remote link failover protection. Extended FGCP features include full mesh HA and virtual clustering. You can also fine tune the performance of the FGCP to change how a cluster forms and shares information among cluster units and how the cluster responds to failures.

Before configuring an FGCP HA cluster, make sure your FortiGate interfaces are configured with static IP addresses. If any interface gets its address using DHCP or PPPoE you should temporarily switch it to a static address and enable DHCP or PPPoE after the cluster has been established.

How to set up FGCP clustering

This example describes how to enhance the reliability of a network protected by a FortiGate unit by adding a second FortiGate unit to create a FortiGate Clustering Protocol (FGCP) HA cluster. The FortiGate already on the network will be configured to become the primary unit by increasing its device priority and enabling override. The new FortiGate will be prepared by setting it to factory defaults to wipe any configuration changes. Then it will be licensed, configured for HA, and then connected to the FortiGate already on the network. The new FortiGate becomes the backup unit and its configuration is overwritten by the primary unit.

If you have not already done so, register the primary FortiGate and apply licenses to it before setting up the cluster. This includes FortiCloud activation and FortiClient licensing, and entering a license key if you purchased more than 10 Virtual Domains (VDOMs). You can also install any third-party certificates on the primary FortiGate before forming the cluster.

The FortiGates should be running the same FortiOS firmware version, and their interfaces should not be configured to get their addresses from DHCP or PPPoE.

Configuring the primary FortiGate

  1. Connect to the primary FortiGate and go to Dashboard > Main > System Information. Change the unit's Host Name to identify it as the primary FortiGate.

    You can also enter this CLI command:

    config system global

    set hostname Primary_FortiGate

    end

  2. You then need to set the HA mode to active-passive. Enter the following CLI command to set the HA mode to active-passive, set a group name and password, increase the device priority to a higher value (for example, 250) and enable override:

    config system ha

    set mode a-p

    set group-name My-HA-Cluster

    set password

    set priority 250

    set override enable

    set hbdev ha1 50 ha2 50

    end

    This command also selects ha1 and ha2 to be the heartbeat interfaces, with their priorities set to 50. Enabling override and increasing the priority ensures that this FortiGate should become the primary unit.

Note

You can configure these settings in the GUI under System > HA, however the override can only be enabled in the CLI.

Configuring the backup FortiGate

  1. Enter the CLI command below to reset the new FortiGate to factory default settings (skip this step if the FortiGate is fresh from the factory). It is recommended to set it back to factory defaults to reduce the chance of synchronization problems:

    execute factoryreset

  2. Make sure to change the firmware running on the new FortiGate to the same version running on the primary unit, register, and apply licenses to it before adding it to the cluster.

  3. Then go to Dashboard > Main > System Information. Change the unit's Host Name to identify it as the backup FortiGate.

    You can also enter this CLI command:

    config system global

    set hostname Backup_FortiGate

    end

  4. Duplicate the primary unit's HA settings, except make sure to set the backup device's priority to a lower value and do not enable override.

Connecting the cluster

Connect the HA cluster as shown in the initial diagram above. Making these connections will disrupt network traffic as you disconnect and re-connect cables.

When connected, the primary and backup FortiGates find each other and negotiate to form an HA cluster. The primary unit synchronizes its configuration with the backup FortiGate. Forming the cluster happens automatically with minimal or no disruption to network traffic.

Heartbeat packet EtherTypes

Normal IP packets are 802.3 packets that have an ethernet type (EtherType) field value of 0x0800. EtherType values other than 0x0800 are understood as level 2 frames rather than IP packets.

By default, HA heartbeat packets use the following EtherTypes:

  • HA heartbeat packets for NAT mode clusters use EtherType 0x8890. These packets are used by cluster units to find other cluster units and to verify the status of other cluster units while the cluster is operating. You can change the EtherType of these packets using the ha-eth-type option under config system ha.

  • HA heartbeat packets for Transparent mode clusters use EtherType 0x8891. These packets are used by cluster units to find other cluster units and to verify the status of other cluster units while the cluster is operating. You can change the EtherType of these packets using the hc-eth-type option under config system ha.

  • Session synchronization packets use Ethertype 0x8892. The interfaces used for session synchronization must be connected together, either directly using an appropriate cable (possible if there are only two units in the cluster) or using switches. If one of the interfaces becomes disconnected, the cluster uses the remaining interfaces for session synchronization. If all the session synchronization interfaces become disconnected, session synchronization reverts to using the HA heartbeat link. All session synchronization traffic is between the primary unit and each secondary unit.

    Note

    Large amounts of session synchronization traffic can increase network congestion. It is recommended that you keep this traffic off of your network by using dedicated connections for it:

    config system ha
        set session-sync-dev port10 port12
    end

    Session synchronization is always using UDP 708, but this will be encapsulated differently depending on session-sync-dev setting. If session-sync-dev is specified, the packets will use 0x8892 and will exit over the mentioned port. If session-sync-dev is not specified, the packets will use 0x8893 and will exit the heartbeat port.

  • HA telnet sessions between cluster units over HA heartbeat links use EtherType 0x8893. The telnet sessions allow an administrator to connect between FortiGates in the cluster using the execute ha manage command. You can change the EtherType of these packets using the l2ep-eth-type option under config system ha.

Because heartbeat packets are recognized as level 2 frames, the switches and routers on your heartbeat network that connect to heartbeat interfaces must be configured to allow them. If level 2 frames are dropped by these network devices, heartbeat traffic will not be allowed between the cluster units.

Some third-party network equipment may use packets with these EtherTypes for other purposes. For example, Cisco N5K/Nexus switches use EtherType 0x8890 for some functions. When one of these switches receives EtherType 0x8890 packets from an attached cluster unit, the switch generates CRC errors and the packets are not forwarded. As a result, FortiGate units connected with these switches cannot form a cluster.

In some cases, if the heartbeat interfaces are connected and configured so regular traffic flows but heartbeat traffic is not forwarded, you can change the configuration of the switch that connects the HA heartbeat interfaces to allow level2 frames with EtherTypes 0x8890, 0x8891, and 0x8893 to pass.

Alternatively, you can use the following CLI options to change the EtherTypes of the HA heartbeat packets:

config system ha

set ha-eth-type <ha_EtherType _4-digit_hex

set hc-eth-type <hc_EtherType _4-digit_ex>

set l2ep-eth-type <l2ep_EtherType _4-digit_hex>

end

For example, use the following command to change the EtherType of the HA heartbeat packets from 0x8890 to 0x8895 and to change the EtherType of HA Telnet session packets from 0x8891 to 0x889f:

config system ha

set ha-eth-type 8895

set l2ep-eth-type 889f

end

Enabling or disabling HA heartbeat encryption and authentication

You can enable HA heartbeat encryption and authentication to encrypt and authenticate HA heartbeat packets. HA heartbeat packets should be encrypted and authenticated if the cluster interfaces that send HA heartbeat packets are also connected to your networks.

If HA heartbeat packets are not encrypted the cluster password and changes to the cluster configuration could be exposed and an attacker may be able to sniff HA packets to get cluster information. Enabling HA heartbeat message authentication prevents an attacker from creating false HA heartbeat messages. False HA heartbeat messages could affect the stability of the cluster.

HA heartbeat encryption and authentication are disabled by default. Enabling HA encryption and authentication could reduce cluster performance. Use the following CLI command to enable HA heartbeat encryption and authentication.

config system ha

set authentication enable

set encryption enable

end

HA authentication and encryption uses AES-128 for encryption and SHA1 for authentication.

FGCP - FortiGate Clustering Protocol

In an active-passive HA configuration, the FortiGate Clustering Protocol (FGCP) provides failover protection, whereby the cluster can provide FortiGate services even when one of the cluster units loses connection. FGCP is also a Layer 2 heartbeat that specifies how FortiGate units communicate in an HA cluster and keeps the cluster operating.

Note

You cannot mix FGCP and SLBC clusters in the same chassis.

The FortiGate's HA Heartbeat listens on ports TCP/703, TCP/23, or ETH layer 2/8890.

Virtual MAC addresses

FGCP assigns virtual MAC addresses to each primary unit interface in an HA cluster. Virtual MAC addresses are in place so that, if a failover occurs, the new primary unit interfaces will have the same MAC addresses as the failed primary unit interfaces. If the MAC addresses were to change after a failover, the network would take longer to recover because all attached network devices would have to learn the new MAC addresses before they could communicate with the cluster.

If a cluster is operating in Transparent mode, FGCP assigns a virtual MAC address for the primary unit management IP address. Since you can connect to the management IP address from any interface, all of the FortiGate interfaces appear to have the same virtual MAC address.

When a cluster starts up, after a failover, the primary unit sends gratuitous ARP packets to update the switches connected to the cluster interfaces with the virtual MAC address. The switches update their MAC forwarding tables with this MAC address. As a result, the switches direct all network traffic to the primary unit. Depending on the cluster configuration, the primary unit either processes this network traffic itself or load balances the network traffic among all of the cluster units.

You cannot disable sending gratuitous ARP packets, but you can change the number of packets that are sent (1-60 ARP packets) by entering the following command:

config system ha

set arps <integer>

end

You can change the time between ARP packets (1-20 seconds) by entering the following command:

config system ha

set arps-interval <integer>

end

Assigning virtual MAC addresses

Virtual MAC addresses are determined based on the following formula:

00-09-0f-09-<group-id_hex>-<vcluster_integer><idx>

where:

  • <group-id_hex>: The HA group ID for the cluster converted to hexadecimal. The table below lists some example virtual MAC addresses set for each group ID:

    Integer group ID

    Hexadecimal group ID

    0

    00

    1

    01

    2

    02

    3

    03

    ...

    ...

    10

    0a

    11

    0b

    ...

    ...

    63

    3f

    ...

    ...

    255

    ff

  • <vcluster_integer>: This value is 0 for virtual cluster 1 and 2 for virtual cluster 2. If virtual domains are not enabled, HA sets the virtual cluster to 1 and by default all interfaces are in the root virtual domain. Including virtual cluster and virtual domain factors in the virtual MAC address formula means that the same formula can be used whether or not virtual domains and virtual clustering is enabled.

  • <idx>: The index number of the interface. In NAT mode, interfaces are numbered from 0 to x (where x is the number of interfaces). The interfaces are listed in alphabetical order on the GUI and CLI. The interface at the top of the interface list is first in alphabetical order by name and has an index of 0. The second interface in the list has an index of 1 and so on. In Transparent mode, the index number foe the management IP address is 0.

Every FortiGate unit physical interface has two MAC addresses: the current hardware address and the permanent hardware address. The permanent hardware address cannot be changed, as it is the actual MAC address of the interface hardware. The current hardware address can be changed, but only when a FortiGate unit is not operating in HA. For an operating cluster, the current hardware address of each cluster unit interface is changed to the HA virtual MAC address by the FGCP.

You cannot change an interface MAC address and you cannot view MAC addresses from the system interface CLI command.

You can use the get hardware nic <interface_name_str> (or diagnose hardware deviceinfo nic <interface_str>) command to display both MAC addresses for any FortiGate interface. This command displays hardware information for the specified interface, including the current hardware address (as Current_HWaddr) and the permanent hardware address (as Permanent_HWaddr). For some interfaces, the current hardware address is displayed as MAC.

Failover protection

FGCP supports three kinds of failover protection:

  1. Device failover: Automatically replaces a failed device and restarts traffic flow with minimal impact on the network. All subordinate units in an active-passive HA cluster are constantly waiting to negotiate to become primary units. Only the heartbeat packets sent by the primary unit keep the subordinate units from becoming primary units. Each received heartbeat packet resets negotiation timers in the subordinate units. If this timer is allowed to run out because the subordinate units do not receive heartbeat packets from the primary unit, the subordinate units assume that the primary unit has failed, and negotiate to become primary units themselves. The default time interval between HA heartbeats is 200 ms.

  2. Link failover: Maintains traffic flow if a link fails. In this case, the primary unit does not stop operating, and therefore participates in the negotiation of selecting a new primary unit. The old primary unit then joins the cluster as a subordinate unit. Furthermore, any subordinate units with a link failure are unlikely to become the primary unit in future negotiations.

  3. Session failover: With session failover (also called session pickup) enabled, the primary unit informs the subordinate units of changes to the primary unit connection and state tables, keeping the subordinate units up-to-date with the traffic currently being processed by the cluster. This helps new primary units resume communication sessions with minimal loss of data, avoiding the need to restart active sessions.

Synchronization of configurations

The FGCP uses a combination of incremental and periodic synchronization to make sure that the configuration of all cluster units is synchronized to that of the primary unit. However, there are certain settings that are not synchronized between cluster units:

  • HA override

  • HA device priority

  • The virtual cluster priority

  • The FortiGate unit host name

  • The HA priority setting for a ping server (or dead gateway detection) configuration

  • The system interface settings of the HA reserved management interface

  • The HA default route for the reserved management interface, set using the ha-mgmt-interface-gateway option of the config system ha command.

You can disable configuration synchronization by entering the following command:

config system ha

set sync-config disable

end

The command execute ha synchronize can be used to perform a manual synchronization.

The FGCP heartbeat operates on TCP port 703 with an independent IP address not assigned to any FortiGate interface. You can create an FGCP cluster of up to four FortiGate units. Below is an example of FGCP used to create an HA cluster installed between an internal network and the Internet.

FGCP HA provides a solution for two key requirements of critical enterprise networking: enhanced reliability and increased performance, through device, link, and remote link failover protection. Extended FGCP features include full mesh HA and virtual clustering. You can also fine tune the performance of the FGCP to change how a cluster forms and shares information among cluster units and how the cluster responds to failures.

Before configuring an FGCP HA cluster, make sure your FortiGate interfaces are configured with static IP addresses. If any interface gets its address using DHCP or PPPoE you should temporarily switch it to a static address and enable DHCP or PPPoE after the cluster has been established.

How to set up FGCP clustering

This example describes how to enhance the reliability of a network protected by a FortiGate unit by adding a second FortiGate unit to create a FortiGate Clustering Protocol (FGCP) HA cluster. The FortiGate already on the network will be configured to become the primary unit by increasing its device priority and enabling override. The new FortiGate will be prepared by setting it to factory defaults to wipe any configuration changes. Then it will be licensed, configured for HA, and then connected to the FortiGate already on the network. The new FortiGate becomes the backup unit and its configuration is overwritten by the primary unit.

If you have not already done so, register the primary FortiGate and apply licenses to it before setting up the cluster. This includes FortiCloud activation and FortiClient licensing, and entering a license key if you purchased more than 10 Virtual Domains (VDOMs). You can also install any third-party certificates on the primary FortiGate before forming the cluster.

The FortiGates should be running the same FortiOS firmware version, and their interfaces should not be configured to get their addresses from DHCP or PPPoE.

Configuring the primary FortiGate

  1. Connect to the primary FortiGate and go to Dashboard > Main > System Information. Change the unit's Host Name to identify it as the primary FortiGate.

    You can also enter this CLI command:

    config system global

    set hostname Primary_FortiGate

    end

  2. You then need to set the HA mode to active-passive. Enter the following CLI command to set the HA mode to active-passive, set a group name and password, increase the device priority to a higher value (for example, 250) and enable override:

    config system ha

    set mode a-p

    set group-name My-HA-Cluster

    set password

    set priority 250

    set override enable

    set hbdev ha1 50 ha2 50

    end

    This command also selects ha1 and ha2 to be the heartbeat interfaces, with their priorities set to 50. Enabling override and increasing the priority ensures that this FortiGate should become the primary unit.

Note

You can configure these settings in the GUI under System > HA, however the override can only be enabled in the CLI.

Configuring the backup FortiGate

  1. Enter the CLI command below to reset the new FortiGate to factory default settings (skip this step if the FortiGate is fresh from the factory). It is recommended to set it back to factory defaults to reduce the chance of synchronization problems:

    execute factoryreset

  2. Make sure to change the firmware running on the new FortiGate to the same version running on the primary unit, register, and apply licenses to it before adding it to the cluster.

  3. Then go to Dashboard > Main > System Information. Change the unit's Host Name to identify it as the backup FortiGate.

    You can also enter this CLI command:

    config system global

    set hostname Backup_FortiGate

    end

  4. Duplicate the primary unit's HA settings, except make sure to set the backup device's priority to a lower value and do not enable override.

Connecting the cluster

Connect the HA cluster as shown in the initial diagram above. Making these connections will disrupt network traffic as you disconnect and re-connect cables.

When connected, the primary and backup FortiGates find each other and negotiate to form an HA cluster. The primary unit synchronizes its configuration with the backup FortiGate. Forming the cluster happens automatically with minimal or no disruption to network traffic.

Heartbeat packet EtherTypes

Normal IP packets are 802.3 packets that have an ethernet type (EtherType) field value of 0x0800. EtherType values other than 0x0800 are understood as level 2 frames rather than IP packets.

By default, HA heartbeat packets use the following EtherTypes:

  • HA heartbeat packets for NAT mode clusters use EtherType 0x8890. These packets are used by cluster units to find other cluster units and to verify the status of other cluster units while the cluster is operating. You can change the EtherType of these packets using the ha-eth-type option under config system ha.

  • HA heartbeat packets for Transparent mode clusters use EtherType 0x8891. These packets are used by cluster units to find other cluster units and to verify the status of other cluster units while the cluster is operating. You can change the EtherType of these packets using the hc-eth-type option under config system ha.

  • Session synchronization packets use Ethertype 0x8892. The interfaces used for session synchronization must be connected together, either directly using an appropriate cable (possible if there are only two units in the cluster) or using switches. If one of the interfaces becomes disconnected, the cluster uses the remaining interfaces for session synchronization. If all the session synchronization interfaces become disconnected, session synchronization reverts to using the HA heartbeat link. All session synchronization traffic is between the primary unit and each secondary unit.

    Note

    Large amounts of session synchronization traffic can increase network congestion. It is recommended that you keep this traffic off of your network by using dedicated connections for it:

    config system ha
        set session-sync-dev port10 port12
    end

    Session synchronization is always using UDP 708, but this will be encapsulated differently depending on session-sync-dev setting. If session-sync-dev is specified, the packets will use 0x8892 and will exit over the mentioned port. If session-sync-dev is not specified, the packets will use 0x8893 and will exit the heartbeat port.

  • HA telnet sessions between cluster units over HA heartbeat links use EtherType 0x8893. The telnet sessions allow an administrator to connect between FortiGates in the cluster using the execute ha manage command. You can change the EtherType of these packets using the l2ep-eth-type option under config system ha.

Because heartbeat packets are recognized as level 2 frames, the switches and routers on your heartbeat network that connect to heartbeat interfaces must be configured to allow them. If level 2 frames are dropped by these network devices, heartbeat traffic will not be allowed between the cluster units.

Some third-party network equipment may use packets with these EtherTypes for other purposes. For example, Cisco N5K/Nexus switches use EtherType 0x8890 for some functions. When one of these switches receives EtherType 0x8890 packets from an attached cluster unit, the switch generates CRC errors and the packets are not forwarded. As a result, FortiGate units connected with these switches cannot form a cluster.

In some cases, if the heartbeat interfaces are connected and configured so regular traffic flows but heartbeat traffic is not forwarded, you can change the configuration of the switch that connects the HA heartbeat interfaces to allow level2 frames with EtherTypes 0x8890, 0x8891, and 0x8893 to pass.

Alternatively, you can use the following CLI options to change the EtherTypes of the HA heartbeat packets:

config system ha

set ha-eth-type <ha_EtherType _4-digit_hex

set hc-eth-type <hc_EtherType _4-digit_ex>

set l2ep-eth-type <l2ep_EtherType _4-digit_hex>

end

For example, use the following command to change the EtherType of the HA heartbeat packets from 0x8890 to 0x8895 and to change the EtherType of HA Telnet session packets from 0x8891 to 0x889f:

config system ha

set ha-eth-type 8895

set l2ep-eth-type 889f

end

Enabling or disabling HA heartbeat encryption and authentication

You can enable HA heartbeat encryption and authentication to encrypt and authenticate HA heartbeat packets. HA heartbeat packets should be encrypted and authenticated if the cluster interfaces that send HA heartbeat packets are also connected to your networks.

If HA heartbeat packets are not encrypted the cluster password and changes to the cluster configuration could be exposed and an attacker may be able to sniff HA packets to get cluster information. Enabling HA heartbeat message authentication prevents an attacker from creating false HA heartbeat messages. False HA heartbeat messages could affect the stability of the cluster.

HA heartbeat encryption and authentication are disabled by default. Enabling HA encryption and authentication could reduce cluster performance. Use the following CLI command to enable HA heartbeat encryption and authentication.

config system ha

set authentication enable

set encryption enable

end

HA authentication and encryption uses AES-128 for encryption and SHA1 for authentication.