Fortinet white logo
Fortinet white logo

CLI Reference

system ha

system ha

Use this command to configure the FortiWeb appliance to act as a member of a high availability (HA) cluster in order to improve availability.

By default, FortiWeb appliances are each a single, standalone appliance and operate independently.

If you have purchased more than one FortiWeb appliance, you can configure them to form an active-passive or active-active high availability (HA) FortiWeb cluster. This improves availability so that you can achieve your service level agreement (SLA) uptimes even if hardware failures occur or maintenance periods are required.

note icon If you have multiple FortiWeb appliances but do not need failover, you can still synchronize the configuration. This can be useful for cloned network environments and externally load-balanced active-active HA. For details, see server-policy custom-application application-policy.

HA requirements

  • Two (for active-passive mode and active-active mode) or more (for active-active mode) identical physical FortiWeb appliances and firmware versions
  • Redundant network topology: if the active appliance fails, physical network cabling and routes must redirect web traffic to the standby appliance
  • At least one physical port on both HA appliances connected directly, via crossover cables, or through switches
note icon FortiWeb-VM now supports HA. However, if you do not wish to use the native HA, you can use your hypervisor or VM environment manager to install your virtual appliances over a hardware cluster to improve availability. For example, VMware clusters can use vMotion or VMware HA.

If FortiWeb HA is active-passive: one appliance is selected to be the active appliance (also called the primary, main, or master), applying the policies for all connections. The other is a passive standby (also called the secondary, standby, or slave), which assumes the role of the active appliance and begins processing connections only if the active appliance fails.

If FortiWeb HA is active-active: all the cluster members are operating as active appliances together to simultaneously handle the traffic between clients and the back web servers. In an active-active HA cluster, one of the member appliances will be selected as the master appliance to centrally receive traffic from clients and back web servers to distribute the traffic to all the cluster members (including itself) according to the specified load balancing algorithm. An active-active HA cluster requires heartbeat detection and configuration and session synchronization between the cluster members. If the master appliance fails, one of the slaves will take it over. An active-active HA cluster can be created only in Reverse Proxy and True Transparent Proxy mode, and at most eight FortiWeb appliances are allowed in the cluster.

For more information on HA, including troubleshooting, failover behavior, synchronized data, and network topology, see the FortiWeb Administration Guide:

https://docs.fortinet.com/fortiweb/admin-guides

To use this command, your administrator account’s access control profile must have either w or rw permission to the sysgrp area. For details, see Permissions.

Syntax

config system ha

set mode {active-passive | active-active | standalone}

set group-id <group_int>

set group-name "<pair-name_str>"

set priority <level_int>

set override {enable | disable}

set network-type {flat | udp-tunnel}

set tunnel-local "<class_ip>"

set tunnel-peer "<class_ip>"

set hbdev "<interface_name>"

set hbdev-backup "<interface_name>"

set lacp-ha-slave {enable | disable}

set link-failed-signal {enable | disable}

set hb-interval <milliseconds_int>

set hb-lost-threshold <seconds_int>

set arps <arp_int>

set arp-interval <seconds_int>

set monitor {"<interface_name>" ...}

set boot-time <limit_int>

set ha-mgmt-status {enable | disable}

set ha-mgmt-interface "<interface_name>"

set schedule {ip | leastconnection | round-robin}le {ip | leastconnection | round-robin}

set session-sysession-sync-broadcast {enable | disable}nc-broadcast {enable | disable}

set session-sync-dev {"<interface_name>" ...}

set session-warm-up <seconds_int>

set weight-1 <weight_int>

set weight-2 <weight_int>

set weight-3 <weight_int>

set weight-4 <weight_int>

set weight-5 <weight_int>

set weight-6 <weight_int>

set weight-7 <weight_int>

set weight-8 <weight_int>

set session-pickup {enable | disable}

set persistence-sync {enable | disable}

set eip-addr <class_ip>

set eip-aid <eip-aid_str>

set ha-eth-type <ha-eth-type_str>

set hc-eth-type <hc-eth-type_str>

set hbcast-eth-type <hbcast-eth-type_str>

set l2ep-eth-type <l2ep-eth-type_str>

set 17-persistence-sync {enable | disable}

set server-policy-hlck {enable | disable}

end

Variable Description Default

mode {active-passive | active-active | standalone}

Select one of the following:

  • active-passive—Form an HA group with another FortiWeb appliance. The appliances operate together, with the standby assuming the role of the active appliance if it fails.
  • active-active—Form an HA group with other FortiWeb appliances. All the appliances are active simultaneously to handle the receiving traffic together.
  • standalone—Operate each appliance independently.

Note: To avoid connectivity issues, do not use config system ha to remove an appliance from an HA cluster. Instead, use ha disconnect, which removes the appliance from the cluster and changes the HA mode to standalone.

standalone

group-id <group_int>

Enter a number that identifies the HA pair.

Both members of the HA pair must have the same group ID. If you have more than one HA pair on the same network, each HA pair must have a different group ID.

Changing the group ID changes the cluster’s virtual MAC address.

The valid range is 0 to 63.

0

group-name "<pair-name_str>"

Enter a name to identify the HA pair if you have more than one.

This setting is optional, and does not affect HA function.

The maximum length is 63 characters.

No default.

priority <level_int>

Enter the priority of the appliance when electing the primary appliance in the HA pair. On standby devices, this setting can be reconfigured using the CLI command ha manage.

This setting is optional. The smaller the number, the higher the priority. The valid range is 0 to 9.

Note: By default, unless you enable override {enable | disable}, uptime is more important than this setting.

5

override {enable | disable}

Enable to make priority <level_int> a more important factor than uptime when selecting the primary appliance. disable

network-type {flat | udp-tunnel}

Select the common HA mode flat or udp-tunnel mode on OpenStack platform. flat

tunnel-local "<class_ip>"

Set the local IP address on OpenStack platform.
This filed can be configured only when the network type is upd-tunnel.
No default.

tunnel-peer "<class_ip>"

Set the peer IP address on OpenStack platform.
This filed can be configured only when the network type is upd-tunnel.
No default.

hbdev "<interface_name>"

Select which port on this appliance that the main and standby appliances will use to send heartbeat signals and synchronization data between each other (i.e. the HA heartbeat link). The maximum length is 15 characters.

Connect this port to the same port number on the other member of the HA cluster. (e.g., If you select port3 for the primary heartbeat link, connect port3 on this appliance to port3 on the other appliance.)

At least one heartbeat interface must be selected on each appliance in the HA cluster. Ports that currently have an IP address assigned for other purposes (that is, virtual servers or bridges) cannot be re-used as a heartbeat link.

At least one heartbeat interface must be selected on each appliance in the HA cluster. Ports that currently have an IP address assigned for other purposes (that is, virtual servers or bridges) cannot be re-used as a heartbeat link.

Tip: If enough ports are available, you can select both a primary heartbeat interface and a secondary heartbeat interface (hbdev-backup "<interface_name>") on each appliance in the HA pair to provide heartbeat link redundancy. You cannot use the same port as both the primary and secondary heartbeat interface on the same appliance, as this is incompatible with the purpose of link redundancy.

Note: If a switch is used to connect the heartbeat interfaces, the heartbeat interfaces must be reachable by Layer 2 multicast.

No default.

hbdev-backup "<interface_name>"

Select a secondary, standby port on this appliance that the main and standby appliances will use to send heartbeat signals and synchronization data between each other (i.e. the HA heartbeat link).

It must not be the same network interface as hbdev "<interface_name>". The maximum length is 15 characters.

Connect this port to the same port number on the other member of the HA cluster. (e.g., If you select port4 for the secondary heartbeat link, connect port4 on this appliance to port4 on the other appliance.)

Ports that currently have an IP address assigned for other purposes (that is, virtual servers or bridges) cannot be re-used as a heartbeat link.

No default.

lacp-ha-slave {enable | disable}

Enable to provide support for 2 LACP interfaces, also known as "bridges," "V-zones," or "aggregated links." For more information about configuring bridges, see the FortiWeb Administration Guide:

http://docs.fortinet.com/fortiweb/admin-guides

disable

link-failed-signal {enable | disable}

Enable to ensure that all equipment in the network detects the new primary unit in a cluster after a failover occurs.

When a failover occurs in an HA active-passive cluster, the new primary unit broadcasts gratuitous ARP packets so that switches will refresh their MAC forwarding tables and detect the new primary unit. However, sometimes switches will not immediately detect a failover and refresh MAC forwarding tables to recognize a new primary unit.

This command shuts down each interface (except for the heartbeat interfaces and reserve management interfaces) of the former primary unit for about a second so that any remaining equipment that did not automatically detect the failover will refresh their MAC forwarding tables and recognize the new primary unit,

disable

arps <arp_int>

Enter the number of times that the FortiWeb appliance will broadcast address resolution protocol (ARP) packets (IPv4 environment) or Neighbor Solicitation (NS) packets (IPv6 environment) when it takes on the main role. Even though a new NIC has not actually been connected to the network, FortiWeb does this to notify the network that a different physical port has become associated with the IP address and virtual MAC of the HA pair.

This is sometimes called “using gratuitous ARP packets to train the network,” and can occur when the main appliance is starting up, or during a failover. Also configure arp-interval <seconds_int>.

Normally, you do not need to change this setting. Exceptions include:

  • Increase the number of times the main appliance sends gratuitous ARP packets if your HA pair takes a long time to fail over or to train the network. Sending more gratuitous ARP packets may help the failover to happen faster.
  • Decrease the number of times the main appliance sends gratuitous ARP packets if your HA pair has a large number of VLAN interfaces and virtual domains. Because gratuitous ARP packets are broadcast, sending them may generate a large amount of network traffic. As long as the HA pair still fails over successfully, you could reduce the number of times gratuitous ARP packets are sent to reduce the amount of traffic produced by a failover.

The valid range is 1–16.

3

arp-interval <seconds_int>

Enter the number of seconds to wait between each broadcast of ARP/NS packets.

Normally, you do not need to change this setting. Exceptions include:

  • Decrease the interval if your HA pair takes a long time to fail over or to train the network. Sending ARP packets more frequently may help the failover to happen faster.
  • Increase the interval if your HA pair has a large number of VLAN interfaces and virtual domains. Because gratuitous ARP packets are broadcast, sending them may generate a large amount of network traffic. As long as the HA pair still fails over successfully, you could increase the interval between when gratuitous ARP packets are sent to reduce the rate of traffic produced by a failover.

The valid range is 1–20.

1

hb-interval <milliseconds_int>

Enter the number of 100-millisecond intervals to set the pause between each heartbeat packet that the one FortiWeb appliance sends to the other FortiWeb appliance in the HA pair. This is also the amount of time that a FortiWeb appliance waits before expecting to receive a heartbeat packet from the other appliance.

This part of the configuration is synchronized between the active appliance and standby appliance.

The valid range is 1–20 (that is, between 100 and 2,000 milliseconds).

Note: Although this setting is synchronized between the main and standby appliances, you should initially configure both appliances with the same hb-interval <milliseconds_int> to prevent inadvertent failover from occurring before the initial synchronization.

1

hb-lost-threshold <seconds_int>

Enter the number of times one of HA appliances retries the heartbeat and waits to receive HA heartbeat packets from the other HA appliance before assuming that the other appliance has failed.

This part of the configuration is synchronized between the main appliance and standby appliance.

Normally, you do not need to change this setting. Exceptions include:

  • Increase the failure detection threshold if a failure is detected when none has actually occurred. For example, during peak traffic times, if the main appliance is very busy, it might not respond to heartbeat packets in time, and the standby appliance may assume that the main appliance has failed.
  • Reduce the failure detection threshold or detection interval if administrators and HTTP clients have to wait too long before being able to connect through the main appliance, resulting in noticeable down time.

The valid range is 1–60.

Note: Although this setting is synchronized between the main and standby appliances, you should initially configure both appliances with the same hb-lost-threshold <seconds_int> to prevent inadvertent failover from occurring before the initial synchronization.

Note: You can use SNMP traps to notify you when a failover is occurring. For details, see system snmp community.

3

monitor {"<interface_name>" ...}

Enter the name of one or more network interfaces that each directly correlate with a physical link. These ports will be monitored for link failure.

Separate the name of each network interface with a space. To remove from or add to the list of monitored network interfaces, retype the entire list.

Port monitoring (also called interface monitoring) monitors physical network ports to verify that they are functioning properly and linked to their networks. If the physical port fails or the cable becomes disconnected, a failover occurs. You can monitor physical interfaces, but not VLAN subinterfaces or 4-port switches.

Note: To prevent an unintentional failover, do not configure port monitoring until you configure HA on both appliances in the HA pair, and have plugged in the cables to link the physical network ports that will be monitored.

No default.

boot-time <limit_int>

Enter the maximum number of seconds that a appliance will wait for a heartbeat or synchronization connection after the appliance returns online.

If this limit is exceeded, the appliance will assume that the other unit is unresponsive, and assume the role of the main appliance.

Due to the default heartbeat and synchronization intervals, as long as the HA pair are cabled directly together, the default value is usually sufficient. If the HA heartbeat link passes through other devices, such as routers and switches, however, a larger value may be needed. You may notice this especially when updating the firmware.

The valid range is 1–100 seconds.

30

ha-mgmt-status {enable | disable}

Specifies whether the network interface you select provides administrative access to this appliance when it is a member of the HA cluster.

When this option is selected, you can access the configuration for this cluster member using the IP address of the specified network interface. The interface configuration, including administrative access and other settings, is not synchronized with other cluster members.

You can configure up to eight reserve management ports in each HA cluster. You cannot configure routing for the port you select.

disable

ha-mgmt-interface "<interface_name>"

Specifies the network interface that provides administrative access to this appliance when it is a member of the HA cluster. No default.

schedule {ip | leastconnection | round-robin}

Specifies the load-balancing algorithm used by the master appliance (in an active-active HA cluster) to distribute received traffic over the available cluster members.

  • ip—Consistently distribute the traffic coming from a source to the same cluster member.
  • leastconnection—Dynamically distribute traffic to a cluster member who has the fewest connections processing.
  • round-robin—Distribute traffic among the available members in a circular order.

Note that FortiWeb's Session Management is not supposed by the active-active HA deployment with the algorithm By connections or Round-robin being used for the load-balancing.

Available only when mode {active-passive | active-active | standalone} is active-active.

ip

session-sync-broadcast {enable | disable}

Specifies whether the master appliance in an active-active HA cluster synchronizes sessions to others in broadcast. By default, session information is synchronized in unicast. Broadcast will be recommended if a active-active HA cluster contains many appliances.

Available only when mode {active-passive | active-active | standalone} is active-active.

disable

session-sync-dev {"<interface_name>" ...}

The master appliance use the heartbeat interface (hbdev "<interface_name>") to synchronize its session table to other appliances in an active-active HA cluster by default. However, you can use extra interfaces (up to four interfaces) for the session synchronization when the HA cluster is in heavy traffic.

Specifies the network interface(s) of this FortiWeb appliance for session synchronizations. For example, typing set session-sync-dev port3 port4 port5 for using port3, port4 and port5 to synchronize session information.

Note:

  • Only the master appliance in the active-active HA cluster is allowed to set session-sync-dev. The configuration here will be synchronized to all the slave appliance in the cluster by the master, and all the appliances send or receive session information with the same interface configuration.
  • The heartbeat interface will not participate in the session synchronization anymore if other interfaces are specified here.
  • It can not specify the heartbeat interface to session-sync-dev.
  • Available only when mode {active-passive | active-active | standalone} is active-active.
No default.

session-warm-up <seconds_int>

Specifies the active-active HA warm-up time that the master appliance will hold traffic distribution to wait for the active-active HA negotiation (determine the master and slave, and necessary synchronizations) completes (when every time the active-active HA starts).

Available only when mode {active-passive | active-active | standalone} is active-active.

10

weight-1 <weight_int>

When the system ha algorithm is ip, sets the weight for the first unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-2 <weight_int>

When the schedule algorithm is ip, sets the weight for the second unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-3 <weight_int>

When the system ha algorithm is ip, sets the weight for the third unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-4 <weight_int>

When the system ha algorithm is ip, sets the weight for the fourth unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-5 <weight_int>

When the system ha algorithm is ip, sets the weight for the fifth unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-6 <weight_int>

When the system ha algorithm is ip, sets the weight for the sixth unit in an active-active HA cluster.

The master unit perform weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-7 <weight_int>

When the system ha algorithm is ip, sets the weight for the seventh unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-8 <weight_int>

When the system ha algorithm is ip, sets the weight for the eighth unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

session-pickup {enable | disable}

Enable so that the master unit in the HA cluster synchronizes the session table with all cluster units. If a cluster unit fails, the HA session table information is available to the remaining cluster units which can use the session table to resume connections without interruption.

Enable for session fail-over protection. If this is not required, disabling may reduce CPU usage and reduce HA heartbeat network bandwidth usage.

Note: Only sessions that have been established for longer than 30 seconds will be synchronized.

disable

persistence-sync {enable | disable}

Enable/disable the persistence synchronization. disable

eip-addr <class_ip>

Enter the elastic IP address for HA on AWS.

No default.

eip-aid <eip-aid_str>

Enter the ID of the elastic IP for HA on AWS.

No default.

ha-eth-type <ha-eth-type_str>

HA heartbeat packet Ethertype (4-digit hex). The range is 0x8890–0x889F.

No default.

hc-eth-type <hc-eth-type_str>

Tuple session HA heartbeat packet Ethertype (4-digit hex). The range is 0x8890–0x889F.

No default.

hbcast-eth-type <hbcast-eth-type_str>

Broadcast HA heartbeat packet Ethertype (4-digit hex). The range is 0x8890–0x889F.

No default.

l2ep-eth-type <l2ep-eth-type_str>

Telnet session HA heartbeat packet Ethertype (4-digit hex). The range is 0x8890–0x889F.

No default.

17-persistence-sync {enable | disable}

When FortiWeb is operating in HA Active-Passive (AP) mode, you can enable Layer 7 Persistence Synchronization.

This option enables session synchronization when there's a failover that causes the slave appliance to take over as the new master, and is useful for web applications that require sticky sessions.

disable

server-policy-hlck {enable | disable}

Enable to check the server policy health.
Server policy health check is only available if the operation mode is Reverse Proxy, and the HA mode is Active-Active.

disable

Example

This example configures a FortiWeb appliance as one appliance in an active-passive HA pair whose group ID is 1. The primary heartbeat occurs over port3, and the secondary heartbeat link is over port4. Priority is more important than uptime when electing the main appliance. The appliance will wait 30 seconds after boot time for a heartbeat or synchronization before assuming that it should be that main appliance. Aside from the heartbeat link, failover can also be triggered by port monitoring of port1 and port2.

config system ha

set mode active-passive

set group-id 1

set priority 6

set override enable

set hbdev port3

set hbdev-backup port4

set arps 3

set arp-interval 2

set hb-interval 1

set hb-lost-threshold 3

set monitor port1 port2

set boot-time 30

end

Related topics

system ha

system ha

Use this command to configure the FortiWeb appliance to act as a member of a high availability (HA) cluster in order to improve availability.

By default, FortiWeb appliances are each a single, standalone appliance and operate independently.

If you have purchased more than one FortiWeb appliance, you can configure them to form an active-passive or active-active high availability (HA) FortiWeb cluster. This improves availability so that you can achieve your service level agreement (SLA) uptimes even if hardware failures occur or maintenance periods are required.

note icon If you have multiple FortiWeb appliances but do not need failover, you can still synchronize the configuration. This can be useful for cloned network environments and externally load-balanced active-active HA. For details, see server-policy custom-application application-policy.

HA requirements

  • Two (for active-passive mode and active-active mode) or more (for active-active mode) identical physical FortiWeb appliances and firmware versions
  • Redundant network topology: if the active appliance fails, physical network cabling and routes must redirect web traffic to the standby appliance
  • At least one physical port on both HA appliances connected directly, via crossover cables, or through switches
note icon FortiWeb-VM now supports HA. However, if you do not wish to use the native HA, you can use your hypervisor or VM environment manager to install your virtual appliances over a hardware cluster to improve availability. For example, VMware clusters can use vMotion or VMware HA.

If FortiWeb HA is active-passive: one appliance is selected to be the active appliance (also called the primary, main, or master), applying the policies for all connections. The other is a passive standby (also called the secondary, standby, or slave), which assumes the role of the active appliance and begins processing connections only if the active appliance fails.

If FortiWeb HA is active-active: all the cluster members are operating as active appliances together to simultaneously handle the traffic between clients and the back web servers. In an active-active HA cluster, one of the member appliances will be selected as the master appliance to centrally receive traffic from clients and back web servers to distribute the traffic to all the cluster members (including itself) according to the specified load balancing algorithm. An active-active HA cluster requires heartbeat detection and configuration and session synchronization between the cluster members. If the master appliance fails, one of the slaves will take it over. An active-active HA cluster can be created only in Reverse Proxy and True Transparent Proxy mode, and at most eight FortiWeb appliances are allowed in the cluster.

For more information on HA, including troubleshooting, failover behavior, synchronized data, and network topology, see the FortiWeb Administration Guide:

https://docs.fortinet.com/fortiweb/admin-guides

To use this command, your administrator account’s access control profile must have either w or rw permission to the sysgrp area. For details, see Permissions.

Syntax

config system ha

set mode {active-passive | active-active | standalone}

set group-id <group_int>

set group-name "<pair-name_str>"

set priority <level_int>

set override {enable | disable}

set network-type {flat | udp-tunnel}

set tunnel-local "<class_ip>"

set tunnel-peer "<class_ip>"

set hbdev "<interface_name>"

set hbdev-backup "<interface_name>"

set lacp-ha-slave {enable | disable}

set link-failed-signal {enable | disable}

set hb-interval <milliseconds_int>

set hb-lost-threshold <seconds_int>

set arps <arp_int>

set arp-interval <seconds_int>

set monitor {"<interface_name>" ...}

set boot-time <limit_int>

set ha-mgmt-status {enable | disable}

set ha-mgmt-interface "<interface_name>"

set schedule {ip | leastconnection | round-robin}le {ip | leastconnection | round-robin}

set session-sysession-sync-broadcast {enable | disable}nc-broadcast {enable | disable}

set session-sync-dev {"<interface_name>" ...}

set session-warm-up <seconds_int>

set weight-1 <weight_int>

set weight-2 <weight_int>

set weight-3 <weight_int>

set weight-4 <weight_int>

set weight-5 <weight_int>

set weight-6 <weight_int>

set weight-7 <weight_int>

set weight-8 <weight_int>

set session-pickup {enable | disable}

set persistence-sync {enable | disable}

set eip-addr <class_ip>

set eip-aid <eip-aid_str>

set ha-eth-type <ha-eth-type_str>

set hc-eth-type <hc-eth-type_str>

set hbcast-eth-type <hbcast-eth-type_str>

set l2ep-eth-type <l2ep-eth-type_str>

set 17-persistence-sync {enable | disable}

set server-policy-hlck {enable | disable}

end

Variable Description Default

mode {active-passive | active-active | standalone}

Select one of the following:

  • active-passive—Form an HA group with another FortiWeb appliance. The appliances operate together, with the standby assuming the role of the active appliance if it fails.
  • active-active—Form an HA group with other FortiWeb appliances. All the appliances are active simultaneously to handle the receiving traffic together.
  • standalone—Operate each appliance independently.

Note: To avoid connectivity issues, do not use config system ha to remove an appliance from an HA cluster. Instead, use ha disconnect, which removes the appliance from the cluster and changes the HA mode to standalone.

standalone

group-id <group_int>

Enter a number that identifies the HA pair.

Both members of the HA pair must have the same group ID. If you have more than one HA pair on the same network, each HA pair must have a different group ID.

Changing the group ID changes the cluster’s virtual MAC address.

The valid range is 0 to 63.

0

group-name "<pair-name_str>"

Enter a name to identify the HA pair if you have more than one.

This setting is optional, and does not affect HA function.

The maximum length is 63 characters.

No default.

priority <level_int>

Enter the priority of the appliance when electing the primary appliance in the HA pair. On standby devices, this setting can be reconfigured using the CLI command ha manage.

This setting is optional. The smaller the number, the higher the priority. The valid range is 0 to 9.

Note: By default, unless you enable override {enable | disable}, uptime is more important than this setting.

5

override {enable | disable}

Enable to make priority <level_int> a more important factor than uptime when selecting the primary appliance. disable

network-type {flat | udp-tunnel}

Select the common HA mode flat or udp-tunnel mode on OpenStack platform. flat

tunnel-local "<class_ip>"

Set the local IP address on OpenStack platform.
This filed can be configured only when the network type is upd-tunnel.
No default.

tunnel-peer "<class_ip>"

Set the peer IP address on OpenStack platform.
This filed can be configured only when the network type is upd-tunnel.
No default.

hbdev "<interface_name>"

Select which port on this appliance that the main and standby appliances will use to send heartbeat signals and synchronization data between each other (i.e. the HA heartbeat link). The maximum length is 15 characters.

Connect this port to the same port number on the other member of the HA cluster. (e.g., If you select port3 for the primary heartbeat link, connect port3 on this appliance to port3 on the other appliance.)

At least one heartbeat interface must be selected on each appliance in the HA cluster. Ports that currently have an IP address assigned for other purposes (that is, virtual servers or bridges) cannot be re-used as a heartbeat link.

At least one heartbeat interface must be selected on each appliance in the HA cluster. Ports that currently have an IP address assigned for other purposes (that is, virtual servers or bridges) cannot be re-used as a heartbeat link.

Tip: If enough ports are available, you can select both a primary heartbeat interface and a secondary heartbeat interface (hbdev-backup "<interface_name>") on each appliance in the HA pair to provide heartbeat link redundancy. You cannot use the same port as both the primary and secondary heartbeat interface on the same appliance, as this is incompatible with the purpose of link redundancy.

Note: If a switch is used to connect the heartbeat interfaces, the heartbeat interfaces must be reachable by Layer 2 multicast.

No default.

hbdev-backup "<interface_name>"

Select a secondary, standby port on this appliance that the main and standby appliances will use to send heartbeat signals and synchronization data between each other (i.e. the HA heartbeat link).

It must not be the same network interface as hbdev "<interface_name>". The maximum length is 15 characters.

Connect this port to the same port number on the other member of the HA cluster. (e.g., If you select port4 for the secondary heartbeat link, connect port4 on this appliance to port4 on the other appliance.)

Ports that currently have an IP address assigned for other purposes (that is, virtual servers or bridges) cannot be re-used as a heartbeat link.

No default.

lacp-ha-slave {enable | disable}

Enable to provide support for 2 LACP interfaces, also known as "bridges," "V-zones," or "aggregated links." For more information about configuring bridges, see the FortiWeb Administration Guide:

http://docs.fortinet.com/fortiweb/admin-guides

disable

link-failed-signal {enable | disable}

Enable to ensure that all equipment in the network detects the new primary unit in a cluster after a failover occurs.

When a failover occurs in an HA active-passive cluster, the new primary unit broadcasts gratuitous ARP packets so that switches will refresh their MAC forwarding tables and detect the new primary unit. However, sometimes switches will not immediately detect a failover and refresh MAC forwarding tables to recognize a new primary unit.

This command shuts down each interface (except for the heartbeat interfaces and reserve management interfaces) of the former primary unit for about a second so that any remaining equipment that did not automatically detect the failover will refresh their MAC forwarding tables and recognize the new primary unit,

disable

arps <arp_int>

Enter the number of times that the FortiWeb appliance will broadcast address resolution protocol (ARP) packets (IPv4 environment) or Neighbor Solicitation (NS) packets (IPv6 environment) when it takes on the main role. Even though a new NIC has not actually been connected to the network, FortiWeb does this to notify the network that a different physical port has become associated with the IP address and virtual MAC of the HA pair.

This is sometimes called “using gratuitous ARP packets to train the network,” and can occur when the main appliance is starting up, or during a failover. Also configure arp-interval <seconds_int>.

Normally, you do not need to change this setting. Exceptions include:

  • Increase the number of times the main appliance sends gratuitous ARP packets if your HA pair takes a long time to fail over or to train the network. Sending more gratuitous ARP packets may help the failover to happen faster.
  • Decrease the number of times the main appliance sends gratuitous ARP packets if your HA pair has a large number of VLAN interfaces and virtual domains. Because gratuitous ARP packets are broadcast, sending them may generate a large amount of network traffic. As long as the HA pair still fails over successfully, you could reduce the number of times gratuitous ARP packets are sent to reduce the amount of traffic produced by a failover.

The valid range is 1–16.

3

arp-interval <seconds_int>

Enter the number of seconds to wait between each broadcast of ARP/NS packets.

Normally, you do not need to change this setting. Exceptions include:

  • Decrease the interval if your HA pair takes a long time to fail over or to train the network. Sending ARP packets more frequently may help the failover to happen faster.
  • Increase the interval if your HA pair has a large number of VLAN interfaces and virtual domains. Because gratuitous ARP packets are broadcast, sending them may generate a large amount of network traffic. As long as the HA pair still fails over successfully, you could increase the interval between when gratuitous ARP packets are sent to reduce the rate of traffic produced by a failover.

The valid range is 1–20.

1

hb-interval <milliseconds_int>

Enter the number of 100-millisecond intervals to set the pause between each heartbeat packet that the one FortiWeb appliance sends to the other FortiWeb appliance in the HA pair. This is also the amount of time that a FortiWeb appliance waits before expecting to receive a heartbeat packet from the other appliance.

This part of the configuration is synchronized between the active appliance and standby appliance.

The valid range is 1–20 (that is, between 100 and 2,000 milliseconds).

Note: Although this setting is synchronized between the main and standby appliances, you should initially configure both appliances with the same hb-interval <milliseconds_int> to prevent inadvertent failover from occurring before the initial synchronization.

1

hb-lost-threshold <seconds_int>

Enter the number of times one of HA appliances retries the heartbeat and waits to receive HA heartbeat packets from the other HA appliance before assuming that the other appliance has failed.

This part of the configuration is synchronized between the main appliance and standby appliance.

Normally, you do not need to change this setting. Exceptions include:

  • Increase the failure detection threshold if a failure is detected when none has actually occurred. For example, during peak traffic times, if the main appliance is very busy, it might not respond to heartbeat packets in time, and the standby appliance may assume that the main appliance has failed.
  • Reduce the failure detection threshold or detection interval if administrators and HTTP clients have to wait too long before being able to connect through the main appliance, resulting in noticeable down time.

The valid range is 1–60.

Note: Although this setting is synchronized between the main and standby appliances, you should initially configure both appliances with the same hb-lost-threshold <seconds_int> to prevent inadvertent failover from occurring before the initial synchronization.

Note: You can use SNMP traps to notify you when a failover is occurring. For details, see system snmp community.

3

monitor {"<interface_name>" ...}

Enter the name of one or more network interfaces that each directly correlate with a physical link. These ports will be monitored for link failure.

Separate the name of each network interface with a space. To remove from or add to the list of monitored network interfaces, retype the entire list.

Port monitoring (also called interface monitoring) monitors physical network ports to verify that they are functioning properly and linked to their networks. If the physical port fails or the cable becomes disconnected, a failover occurs. You can monitor physical interfaces, but not VLAN subinterfaces or 4-port switches.

Note: To prevent an unintentional failover, do not configure port monitoring until you configure HA on both appliances in the HA pair, and have plugged in the cables to link the physical network ports that will be monitored.

No default.

boot-time <limit_int>

Enter the maximum number of seconds that a appliance will wait for a heartbeat or synchronization connection after the appliance returns online.

If this limit is exceeded, the appliance will assume that the other unit is unresponsive, and assume the role of the main appliance.

Due to the default heartbeat and synchronization intervals, as long as the HA pair are cabled directly together, the default value is usually sufficient. If the HA heartbeat link passes through other devices, such as routers and switches, however, a larger value may be needed. You may notice this especially when updating the firmware.

The valid range is 1–100 seconds.

30

ha-mgmt-status {enable | disable}

Specifies whether the network interface you select provides administrative access to this appliance when it is a member of the HA cluster.

When this option is selected, you can access the configuration for this cluster member using the IP address of the specified network interface. The interface configuration, including administrative access and other settings, is not synchronized with other cluster members.

You can configure up to eight reserve management ports in each HA cluster. You cannot configure routing for the port you select.

disable

ha-mgmt-interface "<interface_name>"

Specifies the network interface that provides administrative access to this appliance when it is a member of the HA cluster. No default.

schedule {ip | leastconnection | round-robin}

Specifies the load-balancing algorithm used by the master appliance (in an active-active HA cluster) to distribute received traffic over the available cluster members.

  • ip—Consistently distribute the traffic coming from a source to the same cluster member.
  • leastconnection—Dynamically distribute traffic to a cluster member who has the fewest connections processing.
  • round-robin—Distribute traffic among the available members in a circular order.

Note that FortiWeb's Session Management is not supposed by the active-active HA deployment with the algorithm By connections or Round-robin being used for the load-balancing.

Available only when mode {active-passive | active-active | standalone} is active-active.

ip

session-sync-broadcast {enable | disable}

Specifies whether the master appliance in an active-active HA cluster synchronizes sessions to others in broadcast. By default, session information is synchronized in unicast. Broadcast will be recommended if a active-active HA cluster contains many appliances.

Available only when mode {active-passive | active-active | standalone} is active-active.

disable

session-sync-dev {"<interface_name>" ...}

The master appliance use the heartbeat interface (hbdev "<interface_name>") to synchronize its session table to other appliances in an active-active HA cluster by default. However, you can use extra interfaces (up to four interfaces) for the session synchronization when the HA cluster is in heavy traffic.

Specifies the network interface(s) of this FortiWeb appliance for session synchronizations. For example, typing set session-sync-dev port3 port4 port5 for using port3, port4 and port5 to synchronize session information.

Note:

  • Only the master appliance in the active-active HA cluster is allowed to set session-sync-dev. The configuration here will be synchronized to all the slave appliance in the cluster by the master, and all the appliances send or receive session information with the same interface configuration.
  • The heartbeat interface will not participate in the session synchronization anymore if other interfaces are specified here.
  • It can not specify the heartbeat interface to session-sync-dev.
  • Available only when mode {active-passive | active-active | standalone} is active-active.
No default.

session-warm-up <seconds_int>

Specifies the active-active HA warm-up time that the master appliance will hold traffic distribution to wait for the active-active HA negotiation (determine the master and slave, and necessary synchronizations) completes (when every time the active-active HA starts).

Available only when mode {active-passive | active-active | standalone} is active-active.

10

weight-1 <weight_int>

When the system ha algorithm is ip, sets the weight for the first unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-2 <weight_int>

When the schedule algorithm is ip, sets the weight for the second unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-3 <weight_int>

When the system ha algorithm is ip, sets the weight for the third unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-4 <weight_int>

When the system ha algorithm is ip, sets the weight for the fourth unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-5 <weight_int>

When the system ha algorithm is ip, sets the weight for the fifth unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-6 <weight_int>

When the system ha algorithm is ip, sets the weight for the sixth unit in an active-active HA cluster.

The master unit perform weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-7 <weight_int>

When the system ha algorithm is ip, sets the weight for the seventh unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

weight-8 <weight_int>

When the system ha algorithm is ip, sets the weight for the eighth unit in an active-active HA cluster.

The master unit performs weighted round-robin according to the specified weight to distribute the first packet coming from the source IP to cluster members.

The weight of each unit can be set with a range of 0–256.

1

session-pickup {enable | disable}

Enable so that the master unit in the HA cluster synchronizes the session table with all cluster units. If a cluster unit fails, the HA session table information is available to the remaining cluster units which can use the session table to resume connections without interruption.

Enable for session fail-over protection. If this is not required, disabling may reduce CPU usage and reduce HA heartbeat network bandwidth usage.

Note: Only sessions that have been established for longer than 30 seconds will be synchronized.

disable

persistence-sync {enable | disable}

Enable/disable the persistence synchronization. disable

eip-addr <class_ip>

Enter the elastic IP address for HA on AWS.

No default.

eip-aid <eip-aid_str>

Enter the ID of the elastic IP for HA on AWS.

No default.

ha-eth-type <ha-eth-type_str>

HA heartbeat packet Ethertype (4-digit hex). The range is 0x8890–0x889F.

No default.

hc-eth-type <hc-eth-type_str>

Tuple session HA heartbeat packet Ethertype (4-digit hex). The range is 0x8890–0x889F.

No default.

hbcast-eth-type <hbcast-eth-type_str>

Broadcast HA heartbeat packet Ethertype (4-digit hex). The range is 0x8890–0x889F.

No default.

l2ep-eth-type <l2ep-eth-type_str>

Telnet session HA heartbeat packet Ethertype (4-digit hex). The range is 0x8890–0x889F.

No default.

17-persistence-sync {enable | disable}

When FortiWeb is operating in HA Active-Passive (AP) mode, you can enable Layer 7 Persistence Synchronization.

This option enables session synchronization when there's a failover that causes the slave appliance to take over as the new master, and is useful for web applications that require sticky sessions.

disable

server-policy-hlck {enable | disable}

Enable to check the server policy health.
Server policy health check is only available if the operation mode is Reverse Proxy, and the HA mode is Active-Active.

disable

Example

This example configures a FortiWeb appliance as one appliance in an active-passive HA pair whose group ID is 1. The primary heartbeat occurs over port3, and the secondary heartbeat link is over port4. Priority is more important than uptime when electing the main appliance. The appliance will wait 30 seconds after boot time for a heartbeat or synchronization before assuming that it should be that main appliance. Aside from the heartbeat link, failover can also be triggered by port monitoring of port1 and port2.

config system ha

set mode active-passive

set group-id 1

set priority 6

set override enable

set hbdev port3

set hbdev-backup port4

set arps 3

set arp-interval 2

set hb-interval 1

set hb-lost-threshold 3

set monitor port1 port2

set boot-time 30

end

Related topics