FortiSwitch Stack Configuration: Architecture, Requirements, and Deployment Strategies
.
Comprehensive guide to FortiSwitch stack configuration covering hardware requirements, CLI setup, high availability, and operational best practices for enterprise networks.
Unpacking the Stack: What Fortinet's Switch Aggregation Really Delivers
Network architects seeking to consolidate management overhead while preserving redundancy have long evaluated switch stacking as a viable topology. Fortinet's FortiSwitch stacking implementation permits up to four physical units to operate as a single logical device, presenting one management IP address, one configuration plane, and unified Layer-2 forwarding behavior. This architectural choice reduces operational complexity but introduces specific constraints that demand careful scrutiny before deployment.
Understanding FortiSwitch Stacking Architecture
Supported Hardware and Port Configurations
Stacking functionality remains restricted to homogeneous hardware deployments. The FS-624F and FS-624F-FPOE models utilize ports 25–28 for stacking interconnects, while the FS-648F and FS-648F-FPOE reserve ports 49–56. Port configuration options vary by model: the 624F series supports 24+4R (four stack ports) or 26+2R (two stack ports), whereas the 648F series offers 48+8R, 48+4+4R, or 48+2+6R allocations. Selecting an inappropriate port configuration during initial setup triggers a factory reset, underscoring the importance of pre-deployment planning.
Node Roles and Failover Mechanics
Each stack member assumes one of three operational roles. The primary node serves as the active stack controller, holding the management IP address and processing configuration commands. A designated backup node maintains synchronization and assumes control automatically if the primary fails, inheriting the management address without service interruption. Follower nodes participate in forwarding and configuration synchronization but never assume controller responsibilities. This hierarchy enables predictable failover behavior, though administrators may configure non-revertive mode to prevent automatic role reassignment when a recovered primary rejoins the stack.
Configuration Prerequisites and Constraints
Homogeneity Requirements and Model Limitations
Fortinet enforces strict hardware uniformity: all stack members must share identical model numbers and port configurations. Mixing FPOE and non-FPOE variants within a single stack is explicitly unsupported. Additional constraints include 802.1X authentication limits (240 MAC addresses for 624F models, 480 for 648F), per-switch VLAN learning boundaries, and the inability to combine stacking with Multi-Chassis Link Aggregation (MCLAG). Standalone FortiSwitch units are required; FortiLink and FortiEdge Cloud management paradigms remain incompatible with stacking mode.
CLI Commands with Local vs. Global Scope
Once stacking activates, most configuration commands propagate across all nodes as if addressing a single device. However, several CLI contexts retain local significance and require per-node execution: config system stacking global, config system stacking physical-port, config system stacking nodes, and config system stacking settings. Interface configurations for node.mgmt and node.internal, along with SNMP, certificate, and console settings, also operate at the individual node level. Misunderstanding this scope distinction represents a frequent source of deployment errors.
Deployment Procedures: From Physical Cabling to Logical Management
Ring Topology Wiring Specifications
Physical interconnection follows a deterministic ring pattern. On FS-624F units using the default 24+4R configuration, odd-numbered stack ports (25, 27) connect exclusively to even-numbered ports (26, 28) on adjacent nodes. This odd-to-even pairing prevents loop formation while preserving redundancy. The FS-648F series applies identical logic across its eight potential stack ports. Direct-attach copper or compatible SFP+ transceivers operating at 10Gbps or 25Gbps provide the required inter-switch bandwidth.
Enabling Stacking and Assigning Node Identifiers
Stack activation proceeds via CLI on each unit independently. Administrators first enable stacking mode, assign a unique node identifier (1–4), and specify the port configuration. Subsequent commands define the stack identifier (a 16-character string beginning with "FSWSTK"), ring order, node role, and administrative status. All nodes must share identical stack identifiers and ring-order sequences. Any modification to status or node-id parameters triggers an immediate reboot and configuration reset, preserving only stacking-related settings.
Management Interface Configuration
The stack presents a single management interface (mgmt) accessible via the primary node's IP address. Administrators may configure this interface for static assignment or DHCP. A default static route typically directs management traffic through the same gateway used for data plane operations. For firmware upgrades, each node's node.mgmt interface requires individual IP configuration, enabling out-of-band access during rolling updates.
Operational Considerations and Maintenance Protocols
Firmware Upgrade Strategies for Stacked Environments
Upgrading stack firmware demands sequential node restarts, temporarily degrading aggregate forwarding capacity. Best practice dictates upgrading follower nodes first, followed by the backup, and finally the primary. Each node receives the firmware image via its node.mgmt interface using TFTP, SFTP, or direct upload. During the upgrade window, the stack continues forwarding traffic, but configuration changes should be deferred until all members report synchronized status.
High Availability Integration with FortiGate Clusters
When managed by an HA FortiGate pair, FortiSwitch stacks connect via redundant FortiLink interfaces. The active and passive FortiGate units each establish physical or aggregated links to the first (and optionally last) stack member. Administrators should verify that FortiLink ports and interface types match across both firewall units. Split-link configurations, which distribute FortiLink traffic across multiple physical interfaces, often improve stability compared to single-link redundant interfaces, particularly in high-throughput environments.
Frequently Asked Questions
What happens if a stack member loses power or connectivity?
The stack detects node failure through heartbeat monitoring over stacking links. If the primary node fails, the backup assumes controller responsibilities within seconds, preserving management access and configuration continuity. Follower node failures reduce aggregate port density but do not interrupt stack operation.
Can I mix different FortiSwitch models within a single stack?
No. All stack members must share identical model numbers and stack port configurations. Attempting to combine different models or mixing FPOE with non-FPOE variants prevents stack formation and triggers configuration errors.
How does stacking affect Spanning Tree Protocol behavior?
The entire stack presents as a single STP bridge with one bridge ID. Internal stacking links do not participate in STP calculations, eliminating the need for portfast or edge port configurations on inter-switch connections. External links from the stack to other switches follow standard STP rules.
Is configuration synchronization automatic across stack members?
Yes. After initial stack formation, configuration changes applied to the active node propagate to all online members. However, commands with local scope—such as physical port settings or node-specific interface configurations—require explicit per-node execution.
What monitoring capabilities exist for stack health?
Administrators can query stack status via CLI commands like diagnose stacking status summary or diagnose stacking status detail, which report node state, role, synchronization status, and HA state. The GUI dashboard similarly displays stack topology, member roles, and port utilization across the logical device.