FAQ

What is the requirement of FortiWeb nodes to establish an HA group?

To set up FortiWeb HA, the below configuration are required at least:

• ha mode

• ha group-id

• set hbdev <port_id> #send heartbeat signals & synchronization data

• set monitor <port_id> #not must but recommended; support physical & aggregate ports only (not support VLAN or 4-port switch)

• set tunnel-local 10.0.0.1 #when network-type is udp-tunnel

• set tunnel-peer 10.0.0.2 #when network-type is udp-tunnel

What is the basic configuration to set up HA?

To establish normal HA status, 4S (4 Sames) are required:

• Same Platform

• Same Firmware Version

• Same Group ID

• Same Override option

In addition to the basic settings, you need to add HA members to Node Allocation and set Traffic Distributions for the high volume active-active mode.

How is FortiWeb appliance elected to be the primary node?

On 7.0.2 and previous builds, FortiWeb HA nodes elect the primary role by these rules:

• If Override is disabled:

  Available ports number (Monitor) > Uptime > Priority > SN

• If Override is enabled:

  Available ports number (Monitor) > Priority > Uptime > SN

The Serial numbers are sorted by comparing each character from left to right, where 9 and z are the greatest values, and rank in the highest place at the sorted list. Since it’s very rare that different nodes have the exact same uptime, SN is rarely compared.

From 7.0.4, corefile-ha-failover is supported. If it’s enabled in server-policy setting, the election orders can be treated as below:

• If Override is disabled:

  Corefile (Monitor) > Available monitored ports (Monitor) > Uptime > Priority > SN

• If Override is enabled:

  Corefile (Monitor) > Available monitored ports (Monitor) > Priority > Uptime > SN

As above, the Corefile and Available ports share the same factor “Monitor” in selection, just the corefile has higher weight. So if a proxyd coredump is detected on the primary device, the weight of corefile-ha-failover will be reduced thus the total weight of Monitor will become lower than that of other secondary devices, then HA failover will take place.

In event logs, HA failover triggered by corefile-ha-failover will be also recorded like as “HA switch from primary to secondary, the effective factor of the election is Monitor”:

Please refer to What to do when coredump files are truncated or damaged for more detailed description of corefile-ha-failover.

What is the requirement for heartbeat links?

Verify that heartbeat links are correctly configured and connected:

• Heartbeat interfaces should be dedicated ones, cannot be used as monitor interfaces or reserved management interfaces at the same time

• 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

• The heartbeat interface will be assigned with an IP address within169.254.0.0/16, so do not configure other network interfaces (including VLANs) with this subnet

• Connect one heartbeat port to the same port number on the other HA group members.

• FortiWeb supports up to 2 heartbeat interfaces, however please make sure that the primary and secondary link is not crossed (that is, the primary heartbeat interface is not connected to the secondary heartbeat interface on the other appliance).

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

Does heartbeat work in layer 2 or layer 3 (Network Type)?

Bases on different HA modes and platforms, heartbeat will work in layer 2 or layer 3

• Flat: by default, HA uses ether type 0x8890 to send layer 2 multicast heartbeat packets

• Udp-tunnel: one needs to specify the tunnel-local and tunnel-peer IP address and HA sends heartbeat packets via UDP port 6055 between these two IPs.

Platform	Hardware	VMware	KVM
HA mode supported	Active-Passive Active-Active-Standard Active-Active-High-Volume	Active-Passive Active-Active-Standard Active-Active-High-Volume	Active-Passive Active-Active-Standard Active-Active-High-Volume
Network Type	Flat	Flat, UDP Tunnel (AP & AAHV, Reverse Proxy mode)	Flat, UDP Tunnel (AP & AAHV, Reverse Proxy mode)
Platform	AWS	Azure	OCI
HA mode	Active-Passive Active-Active-High-Volume Manager	Active-Passive Active-Active-High-Volume Manager	Active-Passive Active-Active-High-Volume
Network Type	UDP	UDP	UDP

Will HA nodes use physical MAC address or virtual MAC address for communication?

The situation is different on different HA modes:

• Active-Passive mode: IP addresses on all traffic ports and VIPs on the primary node will use a virtual mac address formatted like “00:09:0F:A0:CC:02” to reply to a visit.

  The secondary nodes will still use the real-mac until it switches to be the primary node.

• Active-Active-Standard mode: the same as Active-Passive mode.

• Active-Active-High-Volume mode: IP addresses on the physical ports will still use the original mac address, while VIPs will use virtual mac address.

This implementation leads to extra configuration on the hypervisors (ESXI, etc.) to allow communication for such virtualized MAC addresses that do not actually exist on physical ports.

How to manage HA nodes, especially the secondary nodes via SSH or GUI?

If HA is deployed in active-passive or standard active-active modes, it’s necessary to add a reserved management interface (or interfaces) and HA static/policy route to manage HA nodes, especially the secondary nodes.

• This option is not a MUST for HA setup but is necessary for active-passive and standard active-active modes, because in these two modes, the IP address and other settings on all interfaces will be synchronized to other HA members unless a port is set as “Reserved Management Interface”.

• If the reserved network interfaces are not in the same subnet with the management computer, you need to configure the next-hop gateways in HA Static Route or HA Policy route

  CLI:

  config system ha-mgmt-router-static

  config system ha-mgmt-router-policy

  GUI:

  

Does FortiWeb synchronize session information in HA mode?

Session synchronization can be enabled for session fail-over protection, but it’s not supported by all HA modes.

• Session Pickup: Available only in Active-Active-Standard mode.

  Session information will be synchronized from the primary node to other HA members, so if HA failover takes place, the other node elected as the new primary will use the session information to resume connections without interruption.

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

• Layer 7 Persistence Synchronization: Available only in Active-Passive mode.

  Actually this feature is not implemented by synchronizing sessions.

  When this option is on, FortiWeb enforces session persistence between the primary and secondary appliances at the application layer.