In this recipe you set up a FortiGate Clustering Protocol (FGCP) virtual clustering configuration with two FortiGates to provide redundancy and failover protection for two networks. The FortiGate configuration includes two VDOMs. The root VDOM handles internal network traffic and the Engineering VDOM handles Engineering network traffic.
To setup a virtual cluster with four FortiGates, see FGCP virtual clustering with four FortiGates (expert).
In this virtual cluster configuration the primary FortiGate processes all internal network traffic and the backup FortiGate processes all Engineering network traffic. (Back-2
This recipe describes the recommended steps for setting up a virtual cluster. If you are looking for a basic HA recipe see High availability with two FortiGates or High Availability with FGCP (Expert).
Before you start, the FortiGates should be running the same FortiOS firmware version and their interfaces should not be configured to get addresses from DHCP or PPPoE.
This recipe features two FortiGate-51Es. FortiGate-51Es have a 5-port switch lan interface. Before configuring HA, the lan interface was converted to 5 separate interfaces (lan1 to lan5).
1. Configuring clustering |
|
If required, upgrade the firmware running on both FortiGates. Both FortiGates should be running the same version of FortiOS. On each FortiGate, enter the following command to reset it to factory default settings. execute factoryreset You can skip this step if the FortiGates are fresh from the factory. But if their configurations have changed at all, it’s a best practice to reset them to factory defaults to reduce the chance of synchronization problems. |
|
Change the primary FortiGate Host name to identify it as the primary FortiGate by going to System > Settings. |
|
Change the backup FortiGate Host name to identify it as the backup FortiGate by going to System > Settings. |
|
You can also use the CLI to change the host name. From the Primary FortiGate: config system global set hostname Primary end From the Backup FortiGate: config system global set hostname Backup end |
|
Register and apply licenses to both FortiGates before forming the cluster. This includes licensing for FortiCare Support, IPS, AntiVirus, Web Filtering, Mobile Malware, FortiClient, FortiCloud, Security Rating, Outbreak Prevention, and additional virtual domains (VDOMs). Both FortiGates in the cluster must have the same level of licensing for FortiGuard, FortiCloud, FortiClient, and VDOMs. You can add FortiToken licenses and install third-party certificates at any time because they’re synchronized to all cluster members. |
|
On the primary FortiGate, enter the following CLI command to set the HA mode to active-passive, set a group-id, group name, and password, increase the device priority to 200, enable override, and configure the heartbeat interfaces (lan4 and lan5 in this example). config system ha set mode a-p set group-id 88 set group-name My-vcluster set password <password> set priority 200 set override enable set hbdev lan4 200 lan5 100 end |
|
You can also configure most of these settings from the GUI (go to Global > System > HA). The group-id and override can only be configured from the CLI. |
|
On the backup FortiGate, duplicate the primary FortiGate HA mode, group-id, group-name, password, override, and heartbeat device settings. Set the device priority to 50. config system ha set mode a-p set group-id 88 set group-name My-vcluster set password <password> set priority 50 set override enable set hbdev lan4 200 lan5 100 end |
|
After you enabe HA, the FortiGates negotiate to establish an HA cluster. You may temporarily lose connectivity as FGCP negotiation takes place and the MAC addresses of the FortiGate interfaces change to HA virtual MAC addresses. To reconnect sooner, you can update the ARP table of your management PC by deleting the ARP table entry for the FortiGate (or just deleting all ARP table entries). You can usually delete the ARP table from a command prompt using a command similar to The FGCP uses virtual MAC addresses for failover. The virtual MAC address assigned to each FortiGate interface depends on the HA group ID. A group ID of 88 sets FortiGate interfaces to the following MAC addresses: 00:09:0f:09:58:00, 00:09:0f:09:58:01, 00:09:0f:09:58:02 and so on. For details, see Cluster virtual MAC addresses. You can verify that the FGCP has set the virtual MAC addresses by viewing the configuration of each FortiGate interface from the GUI (go to Network > Interfaces) or by entering the following CLI command (shown below for lan2 on a FortiGate-51E): get hardware nic lan2 ... Current_HWaddr 00:09:0f:09:58:01 Permanent_HWaddr 70:4c:a5:98:11:54 ... You can also use the The output shows the current hardware (MAC) address (the virtual MAC set by the FGCP) and the permanent hardware (MAC) address for the interface. |
|
2. Connecting and verifying cluster operation |
|
Connect the primary and backup FortiGates together and to your networks as shown in the network diagram at the start of the recipe. Making these connections disrupts network traffic as you disconnect and re-connect cables. Switches must be used between the cluster and the Internet, between the cluster and the internal network, and between the cluster and the Engineering network as shown in the diagram. You can use any good quality switches to make these connections. You can also use one switch for all of these connections as long as you configure the switch to separate traffic from the different networks. You can connect the heartbeat interfaces (lan4 and lan5) with direct cable connections as shown. |
|
When you connect the heartbeat interfaces and power on the FortiGates, they find each other and negotiate to form a cluster. The cluster will have the same IP addresses as the primary FortiGate. You can log into the cluster by logging into the primary FortiGate GUI or CLI using one of the original IP addresses of the primary FortiGate. |
|
Check the cluster synchronization status to make sure the primary and backup FortiGates both have the same configuration. Log into the primary FortiGate CLI and enter this command: diagnose sys ha checksum cluster The command output lists all cluster members’ configuration checksums. If both cluster members have identical checksums you can be sure that their configurations are synchronized. If the checksums are different, wait a short while and enter the command again. Repeat until the checksums are identical. It may take a while for some parts of the configuration to be synchronized. If the checksums never become identical you can use the information in Synchronizing the configuration to troubleshoot the problem or visit the Fortinet Support website for assistance. You can also use the |
|
The HA Status dashboard widget widget also shows synchronization status. Hover over the host names of each FortiGate in the widget to verify that they are synchronized and both have the same checksum. |
|
3. Adding VDOMs and setting up virtual clustering |
|
Enable VDOMs by going to System > Settings > System Operation Settings and enabling Virtual Domains. Or enter the following CLI command. config system global set vdom-admin enable end Add VDOMs as required. Go to Global > System > VDOM and select Create New. Or enter the following CLI command to add the Engineering VDOM. config global edit Engineering end |
|
Configure virtual clustering and VDOM partitioning on the primary FortiGate. The following command enables virtual cluster 2, adds the Engineering VDOM to virtual cluster 2, and sets the virtual cluster 2 device priority of the primary FortiGate to 50. config global config system ha set vcluster2 enable config secondary-vcluster set vdom Engineering set priority 50 end |
|
You can also configure virtual clustering and VDOM partitioning from the GUI by going to Global > System > HA. |
|
Set the virtual cluster 2 priority of the backup FortiGate to a relatively high value (in this example, 200) so that the backup FortiGate processes traffic for the VDOMs in virtual cluster 2. The FGCP synchronizes all other HA settings from the primary FortiGate. You can only configure the virtual cluster 2 priority of the backup FortiGate from the CLI. Use config global config system ha config secondary-vcluster set priority 200 end |
|
4. Checking virtual cluster operation |
|
Once again use the |
|
The HA Status dashboard widget shows the VDOMs in the virtual clusters. You can hover over the VDOM names to see status information for the VDOMs. You can hover over the host names of each FortiGate to verify that they are synchronized and both have the same checksum. |
|
To view more information about the cluster status, click on the HA Status widget and select Configure Settings in System > HA (or go to System > HA). The HA status page shows both FortiGates in the cluster. It also shows that Primary is the primary (master) FortiGate for the root VDOM (so the primary FortiGate processes all root VDOM traffic). The page also shows that Backup is the primary (Master) FortiGate for the Engineering VDOM (so the backup FortiGate processes all Engineering VDOM traffic). |
|
7. Results |
|
All root VDOM traffic should now be flowing through the primary FortiGate and Engineering VDOM traffic should be flowing through the backup FortiGate. If the primary FortiGate becomes unavailable, the cluster negotiates and traffic fails over and all traffic would be processed by the backup FortiGate. |
|
To test failover, ping a reliable IP address from a PC on the internal or Engineering network. After a moment, power off the primary FortiGate. You will see a momentary pause in the ping results while the cluster negotiates and then ping traffic can continue. 64 bytes from 184.25.76.114: icmp_seq=69 ttl=52 time=8.719 ms\ 64 bytes from 184.25.76.114: icmp_seq=70 ttl=52 time=8.822 ms\ 64 bytes from 184.25.76.114: icmp_seq=71 ttl=52 time=9.034 ms\ 64 bytes from 184.25.76.114: icmp_seq=72 ttl=52 time=9.536 ms\ 64 bytes from 184.25.76.114: icmp_seq=73 ttl=52 time=8.877 ms\ 64 bytes from 184.25.76.114: icmp_seq=74 ttl=52 time=8.901 ms\ Request timeout for icmp_seq 75\ 64 bytes from 184.25.76.114: icmp_seq=76 ttl=52 time=8.860 ms\ 64 bytes from 184.25.76.114: icmp_seq=77 ttl=52 time=9.174 ms\ 64 bytes from 184.25.76.114: icmp_seq=78 ttl=52 time=10.108 ms\ 64 bytes from 184.25.76.114: icmp_seq=79 ttl=52 time=8.719 ms\ 64 bytes from 184.25.76.114: icmp_seq=80 ttl=52 time=10.861 ms\ 64 bytes from 184.25.76.114: icmp_seq=81 ttl=52 time=10.757 ms\ 64 bytes from 184.25.76.114: icmp_seq=82 ttl=52 time=8.158 ms\ 64 bytes from 184.25.76.114: icmp_seq=83 ttl=52 time=8.639 ms} |
|
You can log into the cluster GUI or CLI using the same IP address as you had been using to the log into the primary FortiGate. If the primary FortiGate is powered off you will be logging into the backup FortiGate. Check the host name to verify the FortiGate that you have logged into. When you restart the primary FortiGate, after a few minutes it should rejoin the cluster and because override is enabled, the original virtual cluster configuration should be re-established. Traffic may be temporarily disrupted when the restarted primary FortiGate rejoins the cluster. |
For further reading, check out Virtual clustering in the FortiOS 6.0 Handbook.
The post FGCP Virtual Clustering with two FortiGates (expert) appeared first on Fortinet Cookbook.