FortiGate HA Failover<\/a> provides the firewall-cluster side; switch-management continuity must be tested during the same failover exercise.<\/p>\nFortiGate model limits determine switch scale<\/h3>\n Fortinet publishes the maximum number of supported managed FortiSwitch units by FortiGate model.<\/p>\n
That limit varies substantially from small branch models to large chassis\/VM tiers.<\/p>\n
Design should include future switch growth rather than choosing a FortiGate that meets today\u2019s count with no headroom for redundant or expanded access layers.<\/p>\n
FortiLink is not supported in FortiGate transparent mode<\/h3>\n Current FortiSwitch documentation explicitly notes that FortiLink management is not supported when FortiGate operates in transparent mode.<\/p>\n
This matters for designs where the firewall is inserted as a Layer 2 security device.<\/p>\n
Choose routing\/NAT mode, access-switch management model, and network architecture together rather than discovering the incompatibility after hardware deployment.<\/p>\n
VLAN and inter-VLAN routing ownership should be explicit<\/h3>\n FortiSwitch can switch frames locally while FortiGate commonly provides Layer 3 gateways, inter-VLAN policy, DHCP, NAC integration, or security inspection according to design.<\/p>\n
Document where each VLAN terminates and whether routing occurs on FortiGate or another Layer 3 platform.<\/p>\n
Ambiguous gateway ownership can create asymmetric traffic and security-policy bypass.<\/p>\n
Zero-touch authorization should still be controlled<\/h3>\n FortiLink can discover and automatically authorize compatible switches depending on configuration.<\/p>\n
Automation reduces branch deployment effort but should not allow unknown hardware to join a production management domain without inventory and physical\/network controls.<\/p>\n
Use device authorization, naming, firmware policy, and switch inventory so new units become known managed assets.<\/p>\n
FortiLink design succeeds when management redundancy and forwarding resilience are both tested<\/h3>\n The mature topology has known control\/data paths, loop-safe split or MCLAG design, HA-aware cabling, supported switch counts, documented VLAN\/routing ownership, and recovery tests for FortiGate, switch, link, and peer failure.<\/p>\n
FortiLink should simplify operations by centralizing management\u2014not create a hidden single failure domain around the FortiGate\/switch relationship.<\/p>\n
FortiLink management traffic should have a clear addressing and DHCP strategy. Managed FortiSwitch units need predictable control-plane reachability to FortiGate, and accidental overlap with user VLANs can make troubleshooting difficult. Keep FortiLink networks dedicated to management\/control use according to the selected topology.<\/p>\n
Inter-switch links should be sized for east-west traffic as well as FortiLink management. A switch stack can continue to be managed while one oversubscribed ISL degrades user traffic severely. Capacity planning should consider VLAN locality, uplink speed, PoE edge density, and failure cases that push more traffic over remaining links.<\/p>\n
Spanning Tree remains relevant even in centrally managed designs. FortiLink\/MCLAG reduces some loop risks, but access ports, third-party switches, unmanaged extensions, and mispatched cables can still create Layer 2 loops. Define STP root\/guard behavior and monitor topology changes.<\/p>\n
MCLAG peer links and keepalive\/control dependencies need dedicated monitoring. The design should define what happens if one inter-chassis link fails, one peer reboots, or the FortiGate uplink on one side is lost. Test partial failures rather than only powering off a whole switch.<\/p>\n
Firmware lifecycle should be coordinated between FortiGate and managed FortiSwitch units. Feature support and FortiLink compatibility vary by FortiOS\/FortiSwitchOS version and switch model. Use the FortiSwitch feature matrix and validated upgrade paths before enabling new FortiLink features fleet-wide.<\/p>\n
PoE operations can become part of incident response. FortiGate-managed switching can reset or control PoE on supported ports, which is useful for phones, cameras, and AP recovery. Automation should be scoped carefully because cycling the wrong access port can disrupt critical devices.<\/p>\n
Switch authorization and naming should map to physical inventory. Record serial, location, rack\/closet, role, uplinks, and expected FortiGate so a discovered switch cannot be mistaken for an approved replacement. Zero-touch deployment is strongest when physical and logical inventory agree.<\/p>\n
Monitoring should distinguish FortiLink control health from downstream switching health. A FortiSwitch can remain authorized and visible while one access VLAN, ISL, PoE domain, or MCLAG path fails. Service dashboards should include topology, port\/link state, VLAN path, and user\/application impact alongside management connectivity.<\/p>\n
HA topology should avoid shared power and cabling dependencies. Two FortiGate members connected to two FortiSwitch peers still share a failure domain if both switches or firewalls depend on one power circuit, one rack, or one upstream fiber path. Physical resilience must match the logical MCLAG\/split-interface design.<\/p>\n
FortiLink topology should be documented visually and kept synchronized with actual LLDP\/topology discovery. Moves\/adds\/changes in closets can create unexpected ISL paths that still forward traffic but no longer match the tested failure design. Periodic topology reconciliation catches this drift.<\/p>\n
Access-port profiles and VLAN assignments should be centrally standardized. If every managed switch uses ad hoc per-port configuration, FortiLink provides central visibility without central consistency. Templates or switch-controller profiles can make edge policy repeatable across sites.<\/p>\n
FortiLink management should also be included in FortiManager design where supported. If FortiManager centrally manages FortiGate\/Switch Controller configuration, teams need one clear source of truth for switch objects, FortiLink settings, and deployment state rather than mixing local FortiGate edits with manager-driven changes.<\/p>\n
Upgrade testing should include switch-controller behavior after FortiGate failover or reboot. Managed switches may continue forwarding user traffic while control-plane management is temporarily unavailable. Operators should understand which access changes can or cannot be made during that period and how long reconnection normally takes.<\/p>\n
Failure tests should cover the management\/control plane separately from user forwarding. Disconnect the active FortiLink, fail a switch peer, reboot the FortiGate primary, and verify which traffic continues locally, which management functions pause, and how quickly the topology reconverges. This turns topology diagrams into measured resilience.<\/p>\n
Configuration backups should include the FortiGate switch-controller state and enough FortiSwitch information to rebuild the managed topology after hardware replacement. A replacement workflow should restore VLANs, port profiles, trunking, MCLAG\/ISL behavior, and switch authorization without relying on manual recreation from memory.<\/p>\n
The strongest FortiLink design centralizes policy and management while keeping Layer 2 behavior transparent: topology is documented, redundancy is loop-safe, scale limits are respected, switch software is compatible, and operators can distinguish a control-plane problem from an access-port or data-path problem quickly.<\/p>\n
FortiLink operational standards should include a supported-topology matrix by site type. A small branch, campus closet, data-center edge, and HA\/MCLAG location can use different reference designs while still sharing common naming, VLAN, firmware, and monitoring practices. Reference designs reduce one-off cabling and configuration patterns that are difficult to support consistently.<\/p>\n
Keep the topology current and tested.<\/p>\n
Keep failover and scale assumptions measurable.<\/p>\n
Design reviews should include both management-plane failure and forwarding-plane failure. Losing one FortiLink path, one switch, or one controller connection should produce an expected topology and recovery sequence, not an improvised response during an outage.<\/p>\n","protected":false},"excerpt":{"rendered":"
FortiLink lets a FortiGate manage FortiSwitch units as part of an integrated Fortinet access architecture. In FortiLink mode, FortiGate provides the switch-management control plane while FortiSwitch handles Layer 2 forwarding and the broader topology can include direct links, switch stacks, inter-switch links, split interfaces, FortiGate HA pairs, and MCLAG-based designs. Within Fortinet Security Operations, FortiLink […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19857","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t