FortiSwitch CLI Management via FortiGate: A Technical Investigation

January 31, 2026.

Master FortiSwitch management from FortiGate CLI: FortiLink configuration, authorization commands, Layer-3 deployment, and operational best practices.

The Architecture of Centralized Switch Control

Network administrators managing Fortinet ecosystems frequently encounter a pivotal operational question: how to exert precise, command-line control over FortiSwitch units without direct console access. The answer resides in FortiLink, Fortinet's proprietary management protocol that transforms a FortiGate firewall into a centralized switch controller. This investigation examines the CLI pathways, configuration sequences, and operational nuances that define this management paradigm.

FortiLink operates as both a control plane and data plane conduit. When properly configured, it enables administrators to execute FortiSwitchOS commands through the FortiGate CLI, eliminating the need for separate switch management sessions. The architecture supports physical port connections, logical interface aggregation, and even Layer-3 network topologies—each with distinct configuration requirements and operational implications.

Establishing the FortiLink Foundation

Physical Port Configuration Sequence

The most straightforward deployment method configures a dedicated physical port on the FortiGate as the FortiLink interface. The procedure demands precise command sequencing:

config system virtual-switch     edit lan     config port         delete port1     end end  config system interface     edit port1     set auto-auth-extension-device enable     set fortilink enable end  config system ntp     set server-mode enable     set interface port1 end  config switch-controller managed-switch     edit FS224D3W14000370     set fsw-wan1-admin enable end 

Critical observations emerge from this sequence. First, removing the port from any existing virtual switch prevents configuration conflicts. Second, enabling auto-auth-extension-device permits automatic device recognition. Third, NTP synchronization on the FortiLink interface ensures time-consistent logging across the management domain. Finally, the authorization command triggers an immediate FortiSwitch reboot—a deliberate design choice that enforces configuration consistency but requires maintenance window planning.

Logical Interface Aggregation for Resilience

Production environments often demand link redundancy. FortiLink supports aggregation through link-aggregation groups (LAG), hardware switches, or software switches. The LAG configuration introduces additional parameters:

config system interface     edit flink1     set ip 169.254.3.1 255.255.255.0     set allowaccess ping capwap https     set vlanforward enable     set type aggregate     set member port4 port5     set lacp-mode static     set fortilink enable     set fortilink-split-interface enable end 

The fortilink-split-interface directive warrants particular attention. When aggregate interface members connect to multiple FortiSwitch units, this setting prevents control-plane confusion by logically separating management traffic per downstream device. Omitting this parameter in multi-switch topologies can produce intermittent connectivity failures difficult to diagnose without packet captures.

Layer-3 FortiLink: Extending Management Boundaries

Discovery and Authorization Over Routed Networks

FortiLink traditionally operates at Layer 2, but certain deployments require management across routed segments. This capability demands explicit configuration on both FortiGate and FortiSwitch:

1. Reset the FortiSwitch to factory defaults
2. Configure FortiLink management mode:

   config system global     set switch-mgmt-mode fortilink end 

3. Define discovery method (DHCP option 138 or static IP list)
4. Enable Layer-3 mode on the uplink port:

   config switch interface     edit <port_number>     set fortilink-l3-mode enable end 

This architecture introduces operational constraints. Layer-2 VLANs cannot span the routed boundary between FortiGate and FortiSwitch. Each FortiSwitch island must maintain independent Layer-3 reachability to its managing FortiGate. NTP and DHCP services must remain accessible across the routed path. These limitations reflect deliberate architectural boundaries rather than implementation shortcomings.

In-Band Versus Out-of-Band Management Paths

Layer-3 FortiLink deployments present two connectivity models. In-band management utilizes the FortiSwitch internal data interface, sharing bandwidth with production traffic but simplifying cabling. Out-of-band management leverages the dedicated management port, isolating control traffic at the cost of additional physical infrastructure. Mixing these approaches within a single FortiSwitch island produces undefined behavior and should be avoided.

Operational Commands and Diagnostic Pathways

Accessing the FortiSwitch CLI Console

Once FortiLink is established, administrators can access the FortiSwitch CLI through multiple pathways:

• GUI Method: Navigate to Wifi & Switch Controller > Managed FortiSwitches, right-click the target device, and select Connect to CLI
• SSH via DNS: When CAPWAP management is active, execute execute ssh admin@<switch-name>.fsw from the FortiGate CLI
• Direct Console Proxy: Use the GUI connection method to obtain an interactive CLI session tunneled through the FortiGate

Each method serves distinct operational scenarios. The SSH approach facilitates scriptable access for automation frameworks. The GUI proxy method provides immediate interactive access for troubleshooting. Understanding these options enables efficient workflow design.

VLAN and Port Configuration Patterns

Managed FortiSwitch units receive VLAN assignments through the FortiGate CLI using the switch-controller hierarchy:

config switch-controller vlan     edit marketing     set color 32 end  config system interface     edit marketing     set ip 172.20.120.14 255.255.255.0 end  config switch-controller managed-switch     edit FS224D3W14000370     config ports         edit port3         set vlan marketing     end end 

This pattern separates logical network definition (VLAN creation) from physical port assignment. The color parameter provides visual distinction in the GUI but has no operational impact. Port assignments take effect immediately without requiring switch reboots, enabling dynamic network reconfiguration during maintenance windows.

Configuration Persistence and Backup Strategies

Understanding Backup Storage Locations

A frequent operational question concerns configuration backup storage. When administrators execute backup commands for managed FortiSwitch units, the resulting files download to the administrator's workstation—not to the FortiGate or FortiSwitch filesystems. This design follows infrastructure best practices: storing backups on the managed devices themselves creates single points of failure. Centralized backup repositories, whether on-premises or cloud-based, provide superior resilience and audit capabilities.

Synchronization and Firmware Management

FortiGate maintains configuration synchronization with managed FortiSwitch units through periodic polling. Administrators can trigger immediate synchronization using diagnostic commands. Firmware upgrades follow a similar pattern: the FortiGate downloads the target image, distributes it to managed switches, and coordinates reboot sequences to minimize service disruption. Pending upgrades can be canceled before distribution begins, providing a safety mechanism for staged deployments.

Frequently Asked Questions

Q: Can a single FortiGate manage FortiSwitch units across multiple geographic locations?

A: Yes, provided Layer-3 FortiLink is configured and each FortiSwitch maintains IP reachability to its managing FortiGate. Bandwidth, latency, and firewall policies between sites must accommodate CAPWAP control traffic and periodic synchronization.

Q: What happens to FortiSwitch configuration if the managing FortiGate fails?

A: Managed FortiSwitch units continue forwarding traffic based on their last synchronized configuration. However, configuration changes, monitoring, and troubleshooting capabilities remain unavailable until FortiGate connectivity is restored or a high-availability peer assumes management duties.

Q: Is direct CLI access to FortiSwitch still possible after FortiLink authorization?

A: Direct console access remains available for emergency recovery, but configuration changes made directly on the FortiSwitch may be overwritten during the next synchronization cycle. Fortinet recommends performing all configuration through the managing FortiGate to maintain consistency.

Q: How does FortiLink handle switch stacking or MCLAG topologies?

A: FortiLink supports both stacking (multiple switches managed as a single logical unit) and MCLAG (multi-chassis link aggregation). These configurations require additional planning for control-plane redundancy and must be defined before authorizing switches to the FortiGate.

Q: What diagnostic commands help troubleshoot FortiLink connectivity issues?

A: Key diagnostics include diagnose switch-controller FortiLink status for link state verification, diagnose debug application fnbamd -1 for CAPWAP protocol analysis, and get switch-controller managed-switch for authorization status. Packet captures on the FortiLink interface can isolate Layer-2 connectivity problems.