Tag Archives: FortiWAN in HA (High Availability) Mode

FortiWAN in HA (High Availability) Mode

Leave a reply

FortiWAN in HA (High Availability) Mode

Installing FortiWAN in HA mode

When two FortiWAN units work together, they can be configured to HA (High Availability) double-device backup mode. This setup allows two FortiWAN units to server as backup for each other. The master is the main functioning unit, while the slave is the backup unit in standby. An FortiWAN unit alone already has built-in fault tolerance mechanism. All its OS and control applications are stored in Flash Memory, so sudden loss of electricity will not damage the system. But when the network must provide non-stop service for mission-critical applications, the HA mode becomes a must. With HA, FortiWAN serves a significant solution to accomplish network fault tolerance.

FortiWAN supports hot backup in HA by heartbeat mechanism. When both FortiWAN are on, one unit (the master) performs operations, with the other (the slave) in standby. If the master fails for power failure or hardware failure (including normal power off and system reboot), hot backup performs a switch-over to the slave (heartbeat detection fails). This function logically promotes the slave to activate HA and to resume the role of the master. The failed master unit will take the role of slave after it resumes from reboot. The HA hot-backup solution significantly limits the downtime, and secures uninterrupted operation for critical applications.

Hot backup also implies data synchronization. FortiWAN HA performs system configurations synchronization between the master and slave units. Applying configurations to the master unit from Web UI triggers a synchronization to the slave unit. Besides, as long as the peer unit resumes as slave mode from system rebooting, the master also synchronizes system configures with it. This mechanism guarantees the identical system configurations for the two units.

In case that two units are inconsistent with firmware version, FortiWAN model and throughput license, only one unit takes the role of master while the peer unit stay the booting status. A master unit cannot synchronize system configurations with the unit that is in booting status. A message “Incompatible” is displayed for Peer Information in the Summary page of the master’s Web UI.

Setting Up HA

FortiWAN’s double-device backup setup is easy to use. Simply connect the HA RJ-45 ports on both FortiWAN units with a Ethernet cable. Note that HA deployment requires identical firmware version, model and throughput license on the two units.

Activating HA Mode

  1. Install the master FortiWAN.
  2. Connect the slave FortiWAN to the master with a Ethernet cable.
  3. Switch on the slave.

FortiWAN-VM uses the vNIC1 as the HA port. To deploy FortiWAN-VM appliances as HA mode, allocate the vNIC1 of two appliances to the same virtual network (vSwitch). HA deployment is not supported for two FortiWAN-VM appliances that both are 15-day trails. It requires one 60-day trial or a permanent license for the two appliances (in DH mode) at least.

After HA mode has been activated, the Master emits 4 beeps, and the Slave does 3. The status of the Slave is displayed under [System] > [Summary] > [Peer Information] on the master’s Web UI. Note that a slave’s Web UI is not available.

Once the master is down, the slave emits 1 beep and resumes the role of the master to keep network alive.

Switching on the two units together, then the unit with larger Up Time or Serial Number takes the role of master, while the peer unit takes the role of slave.

Note: Ensure the cable is solidly plugged in both units. Otherwise, it may cause errors. After the master locates the slave, system will activate HA mode.

Redundant LAN Port and/or redundant DMZ port: FortiWAN in HA mode

As illustrated in the topology below, two FortiWAN units work in HA mode, with one active and the other in standby. Port1 and port2 acts as redundant LAN port for each other, putting the two units into hot backup mode. This mode offers a significant solution against single point failure in LAN/DMZ (See “Configurations for VLAN and Port Mapping”).

High Availability (HA) Scenarios

Firmware Update Procedure in HA Deployment

Firmware update on both master and slave units under HA deployment can be completed at once (one firmware update instruction). The firmware update procedure in HA deployment is similar to the non-HA (single unit) procedure:

  1. Log onto the master unit as Administrator, go to [System]→[Summary], double check and make sure the peer device is under normal condition (See “Summary”).
  2. Execute the firmware update with uploading the firmware file (See “Administrator”). Please wait as this may take a while.

The master unit starts with verifying the uploaded firmware file for master and slave units (system can not be uploaded with a firmware file that is earlier than the version system is running on). The slave unit then receives a duplicate of firmware file from master unit, and starts to update firmware. The master unit holds on updating itself until the update on slave unit completes. Once slave completes its update, the master unit starts updating itself then, while slave gets into reboot procedure. The whole update procedure will complete after the two units recover from system reboot. The asynchronous update procedure on the two units causes the peer unit recovering from reboot earlier than local unit, and the master-slave relationship will switch therefore.

The whole firmware update will be aborted if any abnormality happens during updating on slave. The master unit will not get updating itself without updating successfully on slave unit. Abnormal termination of firmware update does not trigger system reboot, and therefore the master-slave relationship will not switch.

During the firmware update, the heartbeat mechanism over master and slave units stops temporarily until the firmware update succeeds or is terminated by abnormality.

After the firmware update is complete, the firmware version number displayed in fields [System Information] and [Peer Information] on Web UI page [System > Summary] should be updated and identical. The information displayed in field [Peer Information] gives reference to judge the update.

Version = Updated version number, State = Slave: Firmware update succeeds on both units.

Version = Non-updated version number, State = Slave: Firmware update is aborted by abnormalities. Both units fail to update. Please perform the HA firmware update again (with [Update Slave] being checked).

Version = Updated version number, State = Incompatible: The peer unit succeeds in updating, but the local unit fails. Please perform the single unit firmware update (without [Update Slave] being checked).

Version = Non-updated version number, State = Incompatible: The local unit succeeds in updating, but the peer unit fails. Please reboot local unit to switch the master-slave relationship of the two units. Reconnect and login to Web UI, and perform the single unit firmware update (without [Update Slave] being checked).

Note: If there are abnormal behaviors in the DMZ or public IP servers, go to [System] → [Diagnostic Tools] → [ARP Enforcement] and execute [Enforce] for troubleshooting. Also notice that if the Ethernet cable for HA between the master and slave is removed or disconnected.

If abnormal behaviors appear consistently, please remove the network and HA cable, and perform the firmware update procedure again to both system individually.Then reconnect them to the network as well as the HA deployment.

If repetitive errors occur during the firmware update process, DO NOT ever switch off the device and contact your dealer for technical support.

HA Fallback to Single Unit Deployment

The steps to fallback to single unit deployment from HA are:

  1. Log onto Web UI via Administrator account. Go to [System] → [Summary]and double check and make sure the peer device is under normal condition (See “Summary”).
  2. Turn the Master off if the Master is to be removed. The Slave will take over the network immediately without impacting services. If the Slave is to be removed, then simply turn the Slave off.
  3. Remove the device and the associated cables. Steps of the Slave Take Over are:
  4. In the HA setup, the Master unit is in an active state and serving the network at the meanwhile the Slave unit is monitoring the Master.
  5. In the case of unit failover (Hardware failure, Power failure, HA cable failure, etc), the Slave takes over the network and beeps once when the switchover is completed. The switchover requires 15 seconds or so since negotiations for states.
  6. The switched Master unit becomes the Slave unit in the HA deployment even it is repaired from failures. You can power cycle the Master unit to have another switchover to the units.

Long-distance HA deployment

Sometimes the two FortiWAN appliances used to establish HA deployment are apart from each other geographically. It requires several Ethernet switches or bridges to connect the two appliances across areas or buildings. Since FortiWAN is designed to join a HA deployment by directly connecting the two RJ-45 ports (HA ports) with a Ethernet cable, it is supposed that there is not any non-HA Ethernet frames broadcasted between the two appliances. The HA messages interchanged for availability detection are raw Ethernet frames of EtherType 0x88B6 (LOCAL2), not 0x0800 (IPv4); and the mechanism of FortiWAN’s HA deployment is very sensitive to non-HA Ethernet frames. For this reason, it requires STP and ARP being disabled on the switch (connecting the two FortiWAN units) to avoid misleading the judgment on HA takeover. Besides, please create a port base VLAN on the switch to isolate the HA connectivity from other subnets if necessary.

Get HA information via SNMP and event notifications via SNMP trap

You can use SNMP manager to get slave unit information and receive notifications when the slave unit fails, recovers and take over the master unit. Configure SNMP for your FortiWAN unit (See “SNMP”) to get the information in a MIB field via SNMP manager. Configure the SNMP manager on your FortiWAN and enable the event types “HA slave failure and recovery” and “HA takeover” to notify (See “Notification”), then notifications will be delivered to your SNMP manager for the events. The correspondent MIB fields and OIDs are listed as following:

SNMP field names and OIDs

MIB Field OID Description
fwnSysHAMode 1.3.6.1.4.1.12356.118.1.1 Boolean values used to indicate if the FortiWAN unit supports HA deployment.
fwnSysSlaveVersion 1.3.6.1.4.1.12356.118.1.2 Firmware version of the slave unit deployed with this local unit in HA mode.

 

MIB Field OID Description
fwnSysSlaveSerialNumber 1.3.6.1.4.1.12356.118.1.3 Serial number of the slave unit deployed with this local unit in HA mode.
fwnSysSlaveUptime 1.3.6.1.4.1.12356.118.1.4 Uptime of the slave unit deployed with this local unit in HA mode.
fwnSysSlaveState 1.3.6.1.4.1.12356.118.1.5 State of the slave unit deployed with this local unit in HA mode.
fwnEventHASlaveState 1.3.6.1.4.1.12356.118.3.1.3.1 Send event notification when the slave unit deployed with the local (master) unit in HA mode fails or recovers from a failure: recovery

(1), failure(2).
fwnEventHATakeover 1.3.6.1.4.1.12356.118.3.1.3.2 Send event notification when the master (local) unit in HA deployment is took over by its slave unit: true(1), false(2).
See also
  • Summary
  • Configurations for VLAN and Port Mapping l Administrator