Technical Tip: What to expect for FortiSwitches managed by HA FortiGates
Description
This article describes some expected behaviors for FortiSwitches managed by FortiGates in High-Availability (HA) clusters, such as what to expect for FortiSwitch management status when checking primary vs. secondary FortiGates, as well as what to expect when a failover occurs.
Scope
FortiGate, FortiSwitch.
Solution
Similar to FortiAP, FortiLink-managed FortiSwitches will form persistent control channel connections back to the managing FortiGate (which acts as an 'access controller' or AC). However, each managed FortiSwitch will only form a control channel connection to a single FortiGate at a time, even when that FortiGate is operating in an HA cluster. For comparison, newer FortiAP platforms support the concept of 'hitless' failover, where the FortiAP maintains control channel connections to both the primary and secondary HA FortiGate members: CAPWAP hitless failover using FGCP.
Given the above information, the following are some key facts to keep in mind when managing a FortiSwitch environment with an HA cluster of FortiGates:
Only the current HA primary FortiGate will have control channel connectivity to the managed FortiSwitches; no control channel traffic is exchanged between the HA Secondary FortiGates and the managed FortiSwitches.
The FortiSwitch is still capable of forwarding user traffic regardless of the state of management connectivity to the FortiGate (i.e. control plane functionality is distinctly separate from the data plane), as the configuration is stored locally on the FortiSwitch and then synchronized to the managed configuration on the FortiGate. However, features that require FortiLink management communication may not function while that connectivity is down (see also: FortiSwitchOS Feature Matrix).
When checking the HA secondary FortiGates for FortiSwitch connectivity, it is expected that managed FortiSwitches will show as disconnected/offline in most GUI pages (the status information is not synchronized between HA members). The CLI debug commands will always show the most up-to-date FortiSwitch information.
The List view has been observed to retain stale Status information when the FortiGate is not the HA primary. For example, after rebooting the secondary FortiGate, the Status field will show each FortiSwitch as offline (which matches the CLI), whereas after a controlled failover, the secondary FortiGate may show some/all FortiSwitches as online.For example, the following CLI output sample is taken from the primary and secondary FortiGates, respectively, using the command execute switch-controller get-conn-status:
FGT_01 # execute switch-controller get-conn-status
Managed-devices in current vdom root:
FortiLink interface : fortilink
SWITCH-ID VERSION STATUS FLAG ADDRESS JOIN-TIME SERIAL
FSXXXXXXXXXX2759 v7.6.7 (6615) Authorized/Up 2 10.255.1.2 Thu Sep 3 17:59:22 2026 FSXXXXXXXXXX2759
FSXXXXXXXXXX2760 v7.6.7 (6615) Authorized/Up 2 10.255.1.5 Thu Sep 3 17:58:59 2026 FSXXXXXXXXXX2760
FSXXXXXXXXXX2761 v7.6.7 (6615) Authorized/Up 2 10.255.1.3 Thu Sep 3 17:59:14 2026 FSXXXXXXXXXX2761
FSXXXXXXXXXX2762 v7.6.7 (6615) Authorized/Up 2 10.255.1.4 Thu Sep 3 17:59:00 2026 FSXXXXXXXXXX2762
Flags: C=config sync, U=upgrading, S=staged, D=delayed reboot pending, E=config sync error, 2=L2, 3=L3, V=VXLAN, T=tunnel, X=External
Managed-Switches: 4 (UP: 0 DOWN: 4 MAX: 300)FGT_02 # execute switch-controller get-conn-status
Managed-devices in current vdom root:
FortiLink interface : fortilink
SWITCH-ID VERSION STATUS FLAG ADDRESS JOIN-TIME SERIAL
FSXXXXXXXXXX2759 N/A Authorized/Down 2 N/A FSXXXXXXXXXX2759
FSXXXXXXXXXX2760 N/A Authorized/Down 2 N/A FSXXXXXXXXXX2760
FSXXXXXXXXXX2761 N/A Authorized/Down 2 N/A FSXXXXXXXXXX2761
FSXXXXXXXXXX2762 N/A Authorized/Down 2 N/A FSXXXXXXXXXX2762
Flags: C=config sync, U=upgrading, S=staged, D=delayed reboot pending, E=config sync error, 2=L2, 3=L3, V=VXLAN, T=tunnel, X=External
Managed-Switches: 4 (UP: 0 DOWN: 4 MAX: 300)Related to the above, the following are screenshots of the Topology GUI view under WiFi & Switch Controller -> Managed FortiSwitches. Notice how the link statuses are active on the Primary FortiGate but inactive on the secondary FortiGate (when viewed using HA reserved management interfaces):
Primary FortiGate:
Secondary FortiGate:
Regarding HA failovers and FortiSwitch management:
When an HA failover occurs on the FortiGates, it is expected that there will be a brief disruption in FortiSwitch/FortiLink management connectivity. Note that the exact amount of time will vary depending on the network setup (e.g., the volume of user traffic, the total number of FortiSwitches, the system resource usage on the managing FortiGates, the protocol used for FortiLink management, etc.).
As a point of reference, testing was done in a virtualized FortiGate/FortiSwitch lab using 2x FortiGates and 4x FortiSwitches (2x as an MC-LAG core pair, 2x downstream as access switches). The following results were observed when either triggering an HA failover or when restarting the cu_acd process on the FortiGate (responsible for FortiLink connectivity management):
When using DTLS/CAPWAP for FortiLink (the default method), it took approximately 60-90 seconds for all four FortiSwitches to shift from Authorized/Down to Authorized/Up in the output of execute switch-controller get-conn-status. The FortiGate GUI needed to be refreshed afterwards to reflect the new state.
When using HTTPS-based FortiLink (supported as of FortiOS and FortiSwitchOS V7.4.2 and later; see: FortiLink with HTTPS), it took approximately 25-30 seconds for the FortiSwitches to reach Authorized/Up status.
Note that FortiSwitches are not expected to reconnect simultaneously, and instead will 'trickle in' during the aforementioned reconnect periods. For example, in one of the CAPWAP test cases, the FortiSwitches reconnected one-by-one at the 71, 76, 83, and 90 second marks.
For CAPWAP-based FortiLink, it was also observed that the caputp-echo-interval and caputp-max-retransmit timers available under the config switch-controller system could be adjusted to reduce the reconnection delay (see also: Improving the FortiLink connection). For example, reducing caputp-echo-interval from the default of 30 seconds to 15 seconds resulted in the recovery time decreasing from 60-90 seconds down to 40-50 seconds. However, adjusting these timers did not appear to have any impact on HTTPS-based FortiLink when it came to reconnection times, so there is no need to adjust these settings in that case.
config switch-controller system
set caputp-echo-interval <8-600, default = 30 seconds>
set caputp-max-retransmit <0-64, default = 5>
end
Caution: The above two timers are utilized for the recurring health check traffic transmitted between the FortiSwitch and the managing FortiGate. Setting these timers too aggressively may result in instability for the FortiLink management network, such that the FortiSwitches will appear to frequently flap between online/offline status. Be careful when lowering these settings and be prepared to revert to default settings (or less-aggressive settings) if any FortiLink instability is observed.
As a final note, it is important to reiterate that data plane forwarding is decoupled from the FortiLink control plane, which means that the FortiSwitches can continue to operate and forward user traffic while the FortiLink management connection to the FortiGate is offline.
For example, when an HA failover occurs, the FortiLink connectivity will be offline, but clients connected to the FortiSwitch(es) will still be able to reach other hosts on the same VLAN, and devices on non-connected subnets (such as the Internet) will also be reachable as long as Layer 3 routing services are accessible (e.g., the FortiGate, another router, or the FortiSwitch performing routing offload).
However, be aware that issues impacting the data plane (such as broadcast storms) can still impact the FortiLink control plane (i.e., an issue with the data plane could impact the control plane, but an issue with the control plane should not impact the data plane).
