NSE5 FortiSwitch 7.6 common mistakes
NSE5 FortiSwitch 7.6 · Understand the traps and how to avoid them.
Assuming a FortiSwitch is managed by FortiLink the moment it is cabled to a FortiGate, and answering that no further authorisation is needed.
Candidates confuse physical connectivity with authorisation. A discovered switch stays in an unauthorised state until it is authorised on the FortiGate, and the exam tests that ordering explicitly.
What to do instead
Memorise the sequence: switch is discovered on the FortiLink interface, then authorised (manually or via auto-authorise), only then does it receive its managed configuration. State in answers that an unauthorised switch forwards as a standalone device with its local config.
Treating the FortiLink interface as an ordinary routed port and describing inter-VLAN routing as happening on the FortiSwitch.
Many candidates come from a campus-switching background where the Layer 3 gateway lives on the switch stack, so they default to that mental model instead of the FortiGate-as-gateway design.
What to do instead
Anchor on the design: VLAN interfaces with IP addresses are created on the FortiGate, the FortiSwitch carries Layer 2 only, and the FortiLink aggregate is the trunk. When a question mentions a gateway address, ask which device owns it before answering.
Mixing up the native VLAN of a FortiLink trunk with the VLANs allowed across it, and describing untagged FortiLink traffic as if it were a tagged management VLAN.
The FortiLink management traffic is untagged on the native VLAN while user VLANs are tagged, and candidates memorise 'trunk' without memorising which traffic is tagged.
What to do instead
Write out the trunk explicitly in your notes: native VLAN carries FortiLink control/management untagged, additional VLANs are tagged members. Practise predicting what happens when the native VLAN is changed on both ends versus one end.
Configuring a port as a member of multiple VLANs without specifying tagged versus untagged, then expecting client traffic to work.
The GUI presents VLAN membership as a list, and candidates forget that a port can carry only one untagged VLAN while all others must be tagged.
What to do instead
Before answering, classify the peer device: an access port to an endpoint has one untagged VLAN; an uplink to another switch or a hypervisor has one native/untagged VLAN plus tagged VLANs. Verify with 'diagnose switch vlan assignment' style checks and by reading the port's VLAN table.
Confusing a static VLAN assignment with a dynamic (802.1Q-based or MAC-based) assignment and expecting the dynamic entry to appear as a permanent port member.
Dynamic VLANs are learned and can be lost on link flap or re-authentication, and candidates treat all VLAN membership as configuration rather than as state.
What to do instead
Learn which mechanisms produce dynamic membership (MAC-based VLAN, LLDP-based, RADIUS/802.1X assigned) and note that dynamic entries age out. In troubleshooting answers, check both configured and dynamic membership before concluding the VLAN is missing.
Describing 802.1X, MAB and captive portal as interchangeable and selecting the wrong one for a scenario such as a printer with no supplicant.
All three are 'port security' features in the same GUI area, and candidates memorise the names without the prerequisites of each.
What to do instead
Build a decision table: 802.1X needs a supplicant; MAB uses the MAC address as the credential for devices without one; captive portal intercepts web traffic. For any scenario, first ask whether the endpoint can run a supplicant.
Forgetting that a port-security violation action must be chosen, and assuming the default is to shut the port down.
Candidates assume the harshest action is the default, but the violation action is a configured choice and the effective behaviour depends on what was set.
What to do instead
Memorise the available violation actions and what each does to the port and to logging, then state the configured action explicitly in your answer rather than assuming shutdown.
Answering that a DHCP snooping problem is fixed by adding the server's VLAN as trusted on the wrong side, or by trusting the client port.
The trust direction is the whole point of DHCP snooping, and candidates remember 'trusted port' without remembering that it applies to the port facing the legitimate DHCP server or uplink.
What to do instead
State the rule: trust the uplink/server-facing port, never the access port facing clients. For a client that cannot get a lease, check whether its port is untrusted and whether the server-facing port is trusted before touching anything else.
Diagnosing a 'switch offline' alert by rebooting the switch instead of checking FortiLink reachability, authorisation state and the management VLAN path.
Rebooting feels decisive, but the usual causes are a broken FortiLink path or a switch that lost authorisation, neither of which a reboot fixes.
What to do instead
Follow a layered order: link state on the FortiGate FortiLink interface, then switch authorisation status, then the untagged management path, then firmware compatibility. Only after those are cleared do you consider the device itself.
Ignoring firmware version mismatch between the FortiGate and the managed FortiSwitch when explaining missing features or failed provisioning.
FortiLink capabilities depend on a supported FortiGate/FortiSwitch firmware pairing, and candidates troubleshoot configuration while the real cause is version skew.
What to do instead
Always check the FortiGate and FortiSwitch firmware versions and the supported matrix before deeper troubleshooting, and note that an unsupported combination can leave the switch partially managed. Include the version check as an explicit first step in any provisioning-failure answer.