Fortinet black logo

AWS Administration Guide

Testing FortiGate-VM HA failover

Copy Link
Copy Doc ID e129c4eb-867b-11eb-9995-00505692583a:876802
Download PDF

Testing FortiGate-VM HA failover

The following prerequisites are required for successful failover:

  • Two FortiGates exist in the same virtual private cloud and different availability zones. The two FortiGates must also have the same FortiOS build (FGT_VM64_AWS or FGT_VM64_AWSONDEMAND) installed and the same instance shape. In this example, both FortiGate-VM instances were deployed as C5.xlarge.
  • The high availability (HA) management port can resolve DNS and make API calls to AWS. The HA management port is not blocked by the security group and routed to the Internet gateway on all cluster members.
  • If using FortiGate-VM BYOL instances, both FortiGate-VMs have valid licenses.
  • Minimum sufficient IAM roles as shown in Updating the route table and adding an IAM policy
To test FortiGate-VM HA failover:
  1. To ensure that the FortiGate-VMs are in sync, run get system ha status:

    master # get sys ha stat

    HA Health Status: OK

    Model: FortiGate-VM64-AWSONDEMAND

    Mode: HA A-P

    Group: 0

    Debug: 0

    Cluster Uptime: 1 days 1:50:18

    Cluster state change time: 2019-01-31 18:20:47

    Master selected using:

    <2019/01/31 18:20:47> FGTAWS0006AB1961 is selected as the master because it has the largest value of override priority.

    <2019/01/31 18:20:47> FGTAWS0006AB1961 is selected as the master because it's the only member in the cluster.

    ses_pickup: enable, ses_pickup_delay=disable

    override: disable

    Master: FGTAWS0006AB1961, HA operating index = 0

    Slave : FGTAWS000B29804F, HA operating index = 1

  2. Enable debug mode on the secondary FortiGate:

    diagnose debug enable

    diagnose debug application awsd -1

    Debug messages will be on for unlimited time.

  3. Shut down the primary FortiGate. In the event of a successful failover, the secondary FortiGate CLI shows the following:

    slave # Become HA master

    send_vip_arp: vd root master 1 intf port1 ip 10.0.10.11

    send_vip_arp: vd root master 1 intf port2 ip 10.0.11.11

    awsd get instance id i-0b29804fd38976af4

    awsd get iam role WikiDemoHARole

    awsd get region us-west-2

    awsd get vpc id vpc-0ade7ea6e64befbfc

    awsd doing ha failover for vdom root

    awsd associate elastic ip for port1

    awsd associate elastic ip allocation eipalloc-06b849dbb0f76555f to 10.0.10.11 of eni eni-0ab045a4d6dce664a

    awsd associate elastic ip successfully

    awsd update route table rtb-0a7b4fec57feb1a21, replace route of dst 0.0.0.0/0 to eni-0c4c085477aaff8c5

    awsd update route successfully

  4. Verify on AWS that the public EIP on port1 and the Sec_VPC_Internal route table point to the new primary FortiGate port2 ENI.

Testing FortiGate-VM HA failover

The following prerequisites are required for successful failover:

  • Two FortiGates exist in the same virtual private cloud and different availability zones. The two FortiGates must also have the same FortiOS build (FGT_VM64_AWS or FGT_VM64_AWSONDEMAND) installed and the same instance shape. In this example, both FortiGate-VM instances were deployed as C5.xlarge.
  • The high availability (HA) management port can resolve DNS and make API calls to AWS. The HA management port is not blocked by the security group and routed to the Internet gateway on all cluster members.
  • If using FortiGate-VM BYOL instances, both FortiGate-VMs have valid licenses.
  • Minimum sufficient IAM roles as shown in Updating the route table and adding an IAM policy
To test FortiGate-VM HA failover:
  1. To ensure that the FortiGate-VMs are in sync, run get system ha status:

    master # get sys ha stat

    HA Health Status: OK

    Model: FortiGate-VM64-AWSONDEMAND

    Mode: HA A-P

    Group: 0

    Debug: 0

    Cluster Uptime: 1 days 1:50:18

    Cluster state change time: 2019-01-31 18:20:47

    Master selected using:

    <2019/01/31 18:20:47> FGTAWS0006AB1961 is selected as the master because it has the largest value of override priority.

    <2019/01/31 18:20:47> FGTAWS0006AB1961 is selected as the master because it's the only member in the cluster.

    ses_pickup: enable, ses_pickup_delay=disable

    override: disable

    Master: FGTAWS0006AB1961, HA operating index = 0

    Slave : FGTAWS000B29804F, HA operating index = 1

  2. Enable debug mode on the secondary FortiGate:

    diagnose debug enable

    diagnose debug application awsd -1

    Debug messages will be on for unlimited time.

  3. Shut down the primary FortiGate. In the event of a successful failover, the secondary FortiGate CLI shows the following:

    slave # Become HA master

    send_vip_arp: vd root master 1 intf port1 ip 10.0.10.11

    send_vip_arp: vd root master 1 intf port2 ip 10.0.11.11

    awsd get instance id i-0b29804fd38976af4

    awsd get iam role WikiDemoHARole

    awsd get region us-west-2

    awsd get vpc id vpc-0ade7ea6e64befbfc

    awsd doing ha failover for vdom root

    awsd associate elastic ip for port1

    awsd associate elastic ip allocation eipalloc-06b849dbb0f76555f to 10.0.10.11 of eni eni-0ab045a4d6dce664a

    awsd associate elastic ip successfully

    awsd update route table rtb-0a7b4fec57feb1a21, replace route of dst 0.0.0.0/0 to eni-0c4c085477aaff8c5

    awsd update route successfully

  4. Verify on AWS that the public EIP on port1 and the Sec_VPC_Internal route table point to the new primary FortiGate port2 ENI.