Security Fabric root shows "No topology devices"
Hello,
I am experiencing a Security Fabric GUI issue on a FortiGate HA cluster after an HA failover and failback.
Environment:
- Root FortiGate: FortiGate 101F HA Active-Passive cluster
- FortiOS: 7.4.11
- Five downstream FortiGates
- All FortiGates are running FortiOS 7.4.11
- Security Fabric uses TCP/8013
Issue timeline:
1. Before the HA event, the original primary FortiGate displayed all downstream FortiGates correctly in the Security Fabric device dropdown and topology.
2. The original primary FortiGate was powered off.
3. The secondary FortiGate became the new primary.
4. Immediately after logging in to the new primary, the Security Fabric device dropdown already displayed "No topology devices", and the topology could not be displayed correctly.
5. The original primary later came back online and became primary again.
6. The issue remained present after the failback.
7. However, when logging in directly to any downstream FortiGate, the full Fabric Root and downstream device list is displayed correctly.
The Security Fabric connections themselves appear healthy.
On the root FortiGate:
diagnose sys csf downstream
All five downstream FortiGates are listed and show:
data received: Y
The downstream FortiGates show:
diagnose sys csf upstream
Connection status: Authorized
A packet capture on the root confirms bidirectional Security Fabric traffic:
diagnose sniffer packet wan1 'host <DOWNSTREAM_PUBLIC_IP> and tcp port 8013' 4 0 l
The capture shows bidirectional PSH/ACK traffic between the downstream FortiGate and the root on TCP/8013.
Troubleshooting already performed:
- Confirmed TCP/8013 is bidirectional
- Confirmed all downstream devices are Authorized
- Confirmed root WAN interface has Security Fabric Connection enabled
- Confirmed all FortiGates use FortiOS 7.4.11
- Tested Chrome incognito mode
- Cleared browser cache
- Restarted the root httpsd process
- Executed:
diagnose sys csf get-bulk-global-view 0
None of these actions resolved the root GUI issue.
The HA cluster currently has an out-of-sync status caused by a stale wireless-controller WTP object, which may or may not be related.
Questions:
1. Is this a known FortiOS issue after an HA failover/failback?
2. Is the device dropdown controlled only by httpsd and csfd, or is another process/database involved?
3. Is restarting csfd considered a safe next troubleshooting step?
4. Would deauthorizing and reauthorizing one downstream FortiGate rebuild the topology metadata?
5. Is there a supported method to rebuild or refresh the root Security Fabric topology database without rebuilding the entire Fabric?
Thank you.
