|
Deploying a High Availability (HA) Active-Passive FortiGate manually can pose certain challenges. These challenges may result in malfunctions, but addressing them requires careful attention to the deployment and configuration of the cluster.
For this document, it is assumed that the cluster is not set up using Terraform or CloudFormation. The official documentation (ref: Deploying FortiGate-VM A-P HA on AWS within one zone) has been followed for deploying the cluster.
After the cluster is deployed, a simple yet effective test to ensure everything is functioning correctly is as follows:
diagnose debug application awsd -1
diagnose debug enable
diagnose test application awsd 3
awsd get iam role yourRole
awsd get instance id i-123456
awsd get region lol-central-2
awsd get vpc id vpc-abcdef
Success
If this does not happen and a message like the following arising :
aws curl failed, 28
awsd failed to get instances for ha peers
awsd failed to collect instance eni info
Before opening a ticket, check on each unit the HA configuration that should have the following form:
config system ha
set group-name "AWS-HA"
set mode a-p
set hbdev "port3" 100
set session-pickup enable
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface "port4"
set gateway 20.1.3.1
next
end
set override disable
set priority 255
set unicast-hb enable
set unicast-hb-peerip 20.1.12.10
end
The 'config ha-mgmt-interfaces' section plays a crucial role in ensuring proper failover management. This management port is responsible for directing all API requests to AWS, facilitating failover, and managing the switch of the cluster's public IP.
However, verifying the configuration of the ha-mgmt-interface is not the sole consideration. Another vital aspect to confirm is the configuration of the VPC's routing table.
As outlined in the official documentation under the 'Configure the Routing Tables in AWS' section, the management network must have a route associated with the AWS Internet Gateway (IGW). This association enables the management network to send requests to the AWS API system.
Once this is verified the above test can be performed again and check that it is a success.
Another crucial test to conduct involves simulating a failover. To do this on the secondary unit, execute the following commands:
diagnose debug application awsd -1
diagnose debug enable
Next, initiate the failover simulation by either restarting the primary unit, adjusting the priority of the unit, or, for a more controlled approach, executing the following command:
execute ha failover set 1
Note that this command will trigger an HA failover and is intended strictly for testing purposes. A message will appear asking if it is desired to proceed with the simulation (y/n).
Once answered yes the secondary unit's shell will become very talkative and a debug flow is shown and should have the following form:
HA state: primary
send_vip_arp: vd root primary 1 intf port1 ip 20.1.10.10
send_vip_arp: vd root primary 1 intf port2 ip 20.1.11.10
send_vip_arp: vd root primary 1 intf fortilink ip 10.255.1.1
awsd get iam role FortiOS_generic
awsd get instance id i-0748d7fda800973a0
awsd get region eu-central-2
awsd get vpc id vpc-0f686941962f64aa8
awsd checking ha status for vdom root
awsd checking elastic ip for port1
awsd associate elastic ip 16.63.71.34 to 20.1.10.10 of eni eni-0b67526e3bd19cb3c
awsd associate elastic ip 16.63.71.34 successfully
awsd checking elastic ip for port2
awsd checking route table rtb-09542b034041cfa79
awsd update route table rtb-09542b034041cfa79, replace route of dst 0.0.0.0/0 to eni-09949e9bc0b5623a9
awsd update route successfully
Note: to get back to the initial state of the cluster, on the unit where the execute command has been used to perform the following unset:
execute ha failover unset 1
|
