Skip to main content
I_Omel
Staff
Staff
May 20, 2026

Troubleshooting Tip: GUI Cluster status page fails to load Sessions, Memory and CPU for FPM/FPC

  • May 20, 2026
  • 0 replies
  • 127 views

Description

This article describes why FortiGate's GUI dashboard 'Cluster Status' may show 'Failed to load' for Sessions, Memory and CPU status:

5a4f095e.png

Scope

Modular FortiGate 6K/7K.

 Solution

The architecture of a modular FortiGate 6K/7K differs from low-/mid-range devices. High-end firewalls act as cluster of forwarding boards (FPC), managed by one management board (MBD), compared to the 'monolith' architecture of smaller models.


As a result, for proper operation, FortiGates 6K/7K series must have the Security Fabric enabled for synchronization and communication between the MBD and FPCs, as well as for correct GUI operation: FortiGate 6000F and the Security Fabric.

config system csf
    set status enable
    set legacy-authentication enable


But when these firewalls are deployed in HA A-P mode, the Secondary (Passive) node does not display information for Sessions, Memory, and CPU states of each cluster member, despite the healthy status of all boards:

diagnose load-balance  status

  Primary FPC Blade: slot-2

     Slot  1: 
       Status:Dead      Function:Active 
       Link:      Base: Up          Fabric: Up  
       Heartbeat: Management: Good   Data: Good
       Status Message:"Running"
     Slot  2: FPC6KFT0xxxx
       Status:Working   Function:Active 
       Link:      Base: Up          Fabric: Up  
       Heartbeat: Management: Good   Data: Good  
       Status Message:"Running"
     Slot  3: FPC6KFT0xxxx
       Status:Working   Function:Active 
       Link:      Base: Up          Fabric: Up  
       Heartbeat: Management: Good   Data: Good  
       Status Message:"Running"
...
     Slot 10: FPC6KFT0xxxx
       Status:Working   Function:Active 
       Link:      Base: Up          Fabric: Up  
       Heartbeat: Management: Good   Data: Good  
       Status Message:"Running"


The Security Fabric status also confirms that CSF is functioning as expected:


# diagnose test application csfd 1
Dump CSF daemon info
group name:
group pwd: *
status: Active
accept auth by cert: y
forticloud account enforcement: y

Upstream info
N/A

Downstream info
device total: 10

# 1
sn: FPC6KFT0xxxx
id: 11
ip: 10.101.20.6
port: 9935
status: link-ok SSL-ok hello-ok auth-ok
no response: 0
SLBC member: y

# 2
sn: FPC6KFT0xxxx
id: 10
ip: 10.101.20.9
port: 17002
status: link-ok SSL-ok hello-ok auth-ok
no response: 0
SLBC member: y

# 3
sn: FPC6KFT0xxxx
id: 9
ip: 10.101.20.11
port: 20782
status: link-ok SSL-ok hello-ok auth-ok
no response: 0
SLBC member: y

...

10
sn: FPC6KFT0xxxx
id: 2
ip: 10.101.20.12
port: 24351
status: link-ok SSL-ok hello-ok auth-ok
no response: 0
SLBC member: y


The explanation for this behavior is the current Session-aware Load Balancing Cluster (SLBC) design, where the csf tree is intentionally not formed on the secondary chassis.

As a result, it is expected to see 'Failed to load' for all of the members of the Passive unit in HA deployments.