FortiSwitch Troubleshooting and Monitoring
What this domain tests
Troubleshooting and Monitoring tests a layered method: confirm physical link and PoE, confirm FortiLink discovery/authorization, verify VLAN and MAC learning, then check identity and policy. It also tests the FortiGate and FortiSwitch diagnostic commands and the logs/topology data you use to prove where a fault sits.
Core rules
- Start at the bottom. Check port status, speed/duplex, SFP compatibility, and PoE budget before changing VLANs. A PoE port that cannot deliver the requested class may deny power or reset the device; link state alone does not prove the power budget.
- On the FortiGate, the
diagnose switch ...command family exposes physical ports, VLANs, the MAC address table, and LLDP neighbors;execute switch-controller ...handles authorization, firmware upgrade, and PoE reset actions. Use these before guessing at configuration. - On the FortiSwitch itself, use
get switch status,diagnose switch physical-ports,diagnose switch vlan,diagnose switch mac-address-table,diagnose switch lldp,diagnose switch stp,diagnose switch trunk, and the DHCP snooping/802.1X/port-security diagnostics.diagnose sys topand crashlog reads help with resource or daemon issues. - MAC table evidence: a MAC appearing on an unexpected port suggests a loop, a mispatched cable, or a downstream switch. A missing MAC suggests the frame never arrived or was dropped before learning.
- FortiLink checks: authorization state, firmware compatibility, FortiLink trunk allowed VLANs, and native VLAN. A switch can be up but unmanaged.
- Logs and telemetry: FortiGate switch-controller event logs, FortiSwitch syslog, SNMP polling/traps, and LLDP topology. Use them to correlate the time of failure with a configuration change.
Worked example
Users on VLAN 20 lose DHCP after a switch replacement. The port is up and the PC has link. On the FortiGate, the replacement switch is discovered but not authorized. After authorization, the MAC table shows the PC on the expected port, but DHCP still fails. The uplink is a trunk with native VLAN 99, and VLAN 20 is missing from the allowed list. Adding VLAN 20 to the FortiLink and the uplink restores DHCP. The reasoning: link, then management, then VLAN propagation, then L2 learning, then DHCP.
Traps that cost marks
- Troubleshooting only on the FortiGate and never checking the switch's local port/VLAN state.
- Ignoring a native VLAN mismatch because the link is up.
- Forgetting that an unauthorized or deauthorized switch will not take FortiLink policy.
- Assuming a MAC table entry proves end-to-end forwarding; it only proves learning.
- Overlooking PoE class/budget when a device does not boot.