FCSS LAN Edge 7.6 common mistakes
FCSS LAN Edge 7.6 · Understand the traps and how to avoid them.
Treating FortiLink as a generic 802.1Q uplink and configuring the FortiSwitch-to-FortiGate port as a normal access or trunk port on the FortiGate side, then wondering why the switch never appears in the managed-switch list.
FortiLink is a dedicated management channel; the FortiGate port must be authorized as a FortiLink interface (and on some platforms the interface type set to FortiLink), and the switch must be in FortiLink mode with the correct management VLAN. Candidates who learned VLAN trunking first assume any trunk will do.
What to do instead
Memorize the FortiLink bring-up sequence: set the FortiGate port role to FortiLink, authorize the switch (or pre-authorize by serial), confirm the switch is in FortiLink mode, verify the management VLAN matches on both ends, and check that the FortiLink interface has an IP and DHCP/management access. Practise the exact GUI path and the CLI equivalents (config switch-controller managed-switch, config system interface with type fortilink).
Assuming a FortiSwitch will be discovered automatically with no configuration on the switch itself, then spending the lab time troubleshooting the FortiGate when the switch is still in standalone mode.
The default state of a FortiSwitch depends on model and firmware image; many ship standalone and must be switched to FortiLink mode, and the management port versus the FortiLink port distinction is easy to miss. Candidates conflate 'connected' with 'managed'.
What to do instead
Before touching the FortiGate, verify the switch's current mode and management interface from the switch console, switch it to FortiLink mode if needed, and confirm link state and LLDP visibility. Build a mental checklist: physical link, switch mode, FortiLink authorization, management VLAN, then FortiGate-side configuration.
Configuring FortiAP registration by manually entering IP addresses and static entries instead of using the wireless controller discovery path, then failing to get APs to appear as authorized.
FortiAPs discover the controller via DHCP option 138, broadcast/multicast on the local subnet, or static AC IP configuration. Candidates often skip the DHCP option and then blame the FortiGate firewall policy or the AP firmware.
What to do instead
Know all discovery methods and when each applies: DHCP option 138 for routed deployments, broadcast for flat L2, and the AP's own AC IP list for remote cases. Confirm the AP can reach the FortiGate's management IP on the expected ports, then authorize the AP under the wireless controller. Test the discovery method that matches the topology rather than defaulting to one.
Mixing up tunnel-mode and bridge-mode SSIDs when designing a VLAN plan, then applying the wrong firewall policy or VLAN assignment.
In tunnel mode the AP sends client traffic to the FortiGate over CAPWAP and the FortiGate owns the client VLAN; in bridge mode the AP bridges locally and the VLAN must exist on the FortiSwitch. Candidates design one model and configure the other.
What to do instead
Before configuring, write down for each SSID: mode, client VLAN location, DHCP server location, and which device enforces policy. Then verify the FortiSwitch port the AP is on is configured to allow the bridge-mode VLANs (native VLAN plus allowed VLANs) and that the tunnel-mode SSID maps to the intended FortiGate interface.
Creating a firewall policy for wireless clients but forgetting the intra-VLAN or FortiSwitch-related policy, so clients on the same SSID cannot reach each other or reach a local resource even though internet works.
Traffic between clients on the same VLAN may not traverse the FortiGate in bridge mode, and intra-VLAN blocking is a separate setting; candidates test only internet access and declare success.
What to do instead
Build a test matrix per SSID: client-to-internet, client-to-client same SSID, client-to-wired host, client-to-internal server. Check the SSID's intra-VLAN blocking setting and the relevant firewall policies for each path. Verify with actual pings or a capture rather than assuming the policy covers all flows.
Deploying a FortiSwitch or FortiAP without validating PoE budget and port power requirements, then diagnosing 'dead' APs that are actually power-starved.
PoE budget is shared across ports; a switch with a 370 W budget and multiple high-power APs or cameras can exceed it, and the AP may boot-loop or not boot. Candidates focus on configuration and ignore the physical layer.
What to do instead
Check the switch model's PoE budget and each device's power draw before deployment, and verify the port's PoE status and delivered wattage in the GUI or CLI. Know the fallback: a PoE injector or a higher-budget switch. Include power verification in every AP bring-up checklist.
Ignoring firmware compatibility between FortiGate, FortiSwitch, and FortiAP, then chasing phantom bugs in configuration.
FortiLink and the wireless controller support specific switch and AP firmware ranges; a mismatched switch image can fail to be managed or lose features. Candidates assume any firmware works with any FortiOS 7.6 build.
What to do instead
Consult the FortiOS 7.6 release notes and the FortiLink compatibility matrix before upgrading, and use the FortiGate's managed-switch upgrade path rather than flashing manually. Record the supported image versions for your lab hardware and verify after each upgrade with the managed-switch and managed-AP status pages.
Misreading the order of operations for VLAN and interface configuration on the FortiGate side of FortiLink, creating VLAN interfaces on the wrong parent or before the FortiLink interface exists.
VLANs for tunnel-mode SSIDs and switch management must be created on the FortiLink interface (or as switch VLANs), and the parent interface must exist and be up first. Candidates create VLANs on the physical port instead.
What to do instead
Practise the correct sequence: FortiLink interface up, then VLAN interfaces or switch VLANs on the correct parent, then DHCP and policies. Verify with 'diagnose netlink interface list' and by checking that the VLAN appears under the FortiLink interface, not the physical port.
Treating troubleshooting as guesswork: changing multiple settings at once, or rebooting devices before collecting logs and packet captures.
Under time pressure candidates toggle settings and lose the evidence trail; FortiGate, FortiSwitch, and FortiAP each have separate logs and debug commands, and the failing layer must be isolated first.
What to do instead
Adopt a layered method: physical link and PoE, then L2 (LLDP, VLAN, FortiLink state), then L3 (IP, DHCP, routing), then control plane (CAPWAP, switch authorization), then policy. Use the specific tools: 'diagnose wireless-controller wlac -c wtp', 'diagnose switch-controller ...', packet capture on the FortiLink interface, and the AP/switch event logs. Change one variable at a time.
Assuming LAN Edge security features (port security, DHCP snooping, dynamic VLAN assignment, NAC/802.1X) are enabled by default or work identically on all switch models.
Many of these features are model- and firmware-dependent and require explicit configuration on both the FortiGate profile and the switch port; candidates configure one side and expect enforcement.
What to do instead
For each security feature, verify the supported models and required settings on both the FortiGate (switch controller profile) and the switch port, then test the enforcement path with a real client (wrong credentials, rogue DHCP, MAC violation). Document which features your lab hardware supports before the exam.