Triggering a failover on FortiNAC can be performed to validate that the High Availability (HA) functionality is operating correctly or to meet additional business requirements. This can be achieved using one of the following scenarios:
Scenario 1 – Network Loss:
Disconnect the port1 Interface on the primary server or administratively shut down the switch port connected to the primary node.
Scenario 2 – Management processes down:
Trigger the failover through the CLI by stopping the management processes on the primary node (recommended method).
Verify the node currently In Control either from the GUI or CLI:

get system ha status
Example output:
get system ha status
HA Type: Primary
Primary Server: 10.10.10.239 (Active)
Secondary Server: 10.10.10.232
NAC Type: Network Control Application Server
Shared IP: 10.10.10.253
Shared Mask: 18
Shared Hostname: fnac
Run the following command on the primary node CLI to trigger the failover:
execute ha failover
Example output:
execute ha failover
This operation will force a failover to the secondary server of this HA pair
Would you like to continue? (y/N) y
Completed forcing failover
Validate the node currently In Control either from the GUI or CLI:
Log in to the Administration UI and navigate to Dashboard -> Main -> System Summary's widget panel:

get system ha status
Example output:
get system ha status
HA Type: Primary
Primary Server: 10.10.10.239
Secondary Server: 10.10.10.232 (Active)
NAC Type: Network Control Application Server
Shared IP: 10.10.10.253
Shared Mask: 18
Shared Hostname: fnac
Control can be resumed either through the Admin UI or CLI.
To Resume Control to the primary node via the GUI:
 To Resume Control via the CLI, run the following command on the Primary node CLI:
execute enter-shell
$ sudo hsRestartCMMaster
Example output:
execute enter-shell
fortinac1:~$ sudo hsRestartCMMaster
Recovery started using 10.5.139.232 as the source
DB synchronization is up to date
sending incremental file list
deleting bsc/backups/database/FortiNAC_DataBase_BackUp_2026_03_11_00_01_51_forti nac1.gz
bsc/backups/database/
bsc/campusMgr/.keystorePrimary
bsc/www/portal/registration/site/css/
bsc/www/portal/registration/site/css/customRulesMobile_Portal.css
bsc/www/portal/registration/site/css/customRulesMobile_RegistrationPortal.css
bsc/www/portal/registration/site/css/customRulesMobile_RestrictedPortal.css
bsc/www/portal/registration/site/css/customRules_Portal.css
bsc/www/portal/registration/site/css/customRules_RegistrationPortal.css
bsc/www/portal/registration/site/css/customRules_RestrictedPortal.css
bsc/www/portal/registration/site/css/customSkin_Portal.css
bsc/www/portal/registration/site/css/customSkin_RegistrationPortal.css
bsc/www/portal/registration/site/css/customSkin_RestrictedPortal.css
sent 41,270 bytes received 2,634 bytes 29,269.33 bytes/sec
total size is 338,401,899 speedup is 7,707.77
2026-06-09 16:05:00.538 +0200 [ForkJoinPool.commonPool-worker-5] INFO ActiveAct iveStandbyServiceGRPCClient - forceUpdateCampusManagerStatus successfully update d 10.5.139.232 to status 1
2026-06-09 16:05:03.036 +0200 [ForkJoinPool.commonPool-worker-3] INFO ActiveAct iveStandbyServiceGRPCClient - forceUpdateCampusManagerStatus successfully update d 127.0.0.1 to status 1
forceUpdateStatus finished update local and 10.5.139.232 status to 1
Set status to Primary in control on both servers
arping 10.5.139.239 interface port1
arping 10.5.139.253 interface port1
arping 10.22.11.232 interface port2
winbind already installed
Failed checking/installing winbind
Sufficient freeradius installed
Clobbering logrotate.d/radiusd
Enabling modules
Updating Permissions
chmod: cannot access '/var/log/radius/*.log*': No such file or directory
Important note: Before performing a failover, ensure that a Database backup (see Overview) is available outside of the appliance and that a VM backup or snapshot has been created in virtual machine environments.
Contact Fortinet Support (Welcome to Fortinet Support) if assistance is required. |