Technical Tip: FortiManager VRRP HA does not support automatic pre-emptive failover

[heng]

Description	This article describes that VRRP HA configuration is supported and introduced from version 7.2 and later, and FortiManager VRRP HA does not support automatic pre-empt failover. When the original master VRRP comes back as backup VRRP due to a reboot, a failure, or an RMA hardware replacement, it will not pre-empt as master VRRP even though it has a higher VRRP priority than the current master VRRP (previously is the backup VRRP). But in the upcoming 7.2.4, 7.4.1 will introduce a CLI command to force a VRRP new role election based on the configured VRRP priority.
Scope	FortiManager version 7.2.3, 7.2.4, 7.4.0, 7.4.1.
Solution	Perform a simple test as follow to verify this function.  The primary FortiManager is set with priority VRRP 253 and the secondary FortiManager is set with priority VRRP 250. Run CLI get sys ha to check the config: FMG-PRIMARY # get sys ha clusterid : 11 failover-mode : vrrp file-quota : 4096 hb-interval : 10 hb-lost-threshold : 30 local-cert : (null) mode : primary monitored-interfaces: monitored-ips: == [ 1 ] id: 1 password : * peer: == [ 1 ] id: 1 priority : 253 unicast : disable vip : 10.47.19.58 vrrp-adv-interval : 3 vrrp-interface : port1 FMG-SECONDARY # get sys ha clusterid : 11 failover-mode : vrrp file-quota : 4096 hb-interval : 10 hb-lost-threshold : 30 local-cert : (null) mode : secondary monitored-interfaces: monitored-ips: == [ 1 ] id: 1 password : * peer: == [ 1 ] id: 1 priority : 250 unicast : disable vip : 10.47.19.58 vrrp-adv-interval : 3 vrrp-interface : port1 Primary FortiManager on the role of Master VRRP (Primary HA) and Secondary FMG on the role of Backup VRRP (Secondary HA), HA mode can be checked with CLI get sys status: FMG-PRIMARY # get sys status ... Hostname : FMG-PRIMARY ... HA Mode : HA Primary <- ... FMG-SECONDARY # get sys status ... Hostname : FMG-SECONDARY ... HA Mode : HA Secondary ... Do a reboot on Primary FortiManager.  Secondary FortiManager took over the role of Master VRRP (Primary HA) right after the Primary FortiManager failed due to a reboot. The Primary FortiManager comes back online but however, moves to the role of Backup VRRP (Secondary HA) even though it has a higher priority of 253. Secondary FortiManager will continue to stay in the role of Master VRRP with no change.  At this point, verify that Primary FortiManager will not pre-empt even if it is being set with higher VRRP priority.  FMG-PRIMARY # get sys status ... Hostname : FMG-PRIMARY ... HA Mode : HA Secondary ... FMG-SECONDARY # get sys status ... Hostname : FMG-SECONDARY ... HA Mode : HA Primary <- ... To re-elect the Master VRRP based on the configure VRRP priority, there is a CLI command diagnose ha force-vrrp-election being introduced in the upcoming version 7.2.4, 7.4.1 to be manually run to re-elect the role and the CLI command to be run in the current Master VRRP (Primary HA). For this example here, it will be the Secondary FortiManager. The VRRP debug is visible by enabling the debug command diagnose debug application ha 8 follows by diagnose debug enable. FMG-SECONDARY # diagnose ha force-vrrp-election ... VRRP enters new state STOP VRRP enters new state: setting HA to secondary role=2,1,id=11,11,passwd=******,****** HA parameters changed, re-start 2023-08-05 19:10:44 --- starting HA daemon --- VRRP enters new state BACKUP VRRP enters new state: setting HA to secondary ... FMG-PRIMARY # ... VRRP enters new state MASTER VRRP enters new state: setting HA to primary role=1,2,id=11,11,passwd=******,****** HA parameters changed, re-start 2023-08-05 19:10:44 --- starting HA daemon --- ... FMG-PRIMARY # get sys status ... Hostname : FMG-PRIMARY ... HA Mode : HA Primary <- ... FMG-SECONDARY # get sys status ... Hostname : FMG-SECONDARY ... HA Mode : HA Secondary ...