Fortinet FortiSwitch 7.6: FortiLink and Secure Switching

An office upgrades its access-layer switches and moves them under FortiGate control. Staff can reach the network, but conference-room phones lose voice quality during a busy meeting, one port allows an unauthorized device, and the management dashboard shows intermittent FortiLink connectivity. A switching service has several independent responsibilities: forwarding frames efficiently, preserving VLAN boundaries, granting network access appropriately and remaining manageable when links or devices fail. FortiSwitch 7.6 Administrator tests whether an engineer can reason through those layers as one operating system.

NSE5-FSW-AD-7.6 is associated with the Fortinet NSE 5 FortiSwitch 7.6 Administrator exam. Fortinet's published description covers FortiSwitchOS 7.6 and FortiOS 7.6, including FortiLink-managed and standalone operation, deployment topologies, Layer 2 protection, monitoring, and troubleshooting. This is not the same role as the historical LAN Edge Architect, whose focus included cross-platform identity and full campus design. Within Fortinet certifications, switching expertise is strongest when based on how the device handles actual frames, policy and topology changes, not on a collection of screenshots.

Start with ports, VLAN membership and traffic paths

An access port and a trunk have distinct roles. Define which client network a port belongs to, whether frames are tagged or untagged, and which VLANs are permitted on uplinks. A mismatch can make a device appear connected while its DHCP or application packets reach the wrong subnet. Examine the switch's MAC address table and interface counters alongside FortiGate policy to determine whether a packet is dropped locally, forwarded to the wrong VLAN or blocked at Layer 3. Avoid assuming the firewall can correct every Layer 2 configuration mistake.

Physical link health matters as much as the logical policy. Check speed, duplex, transceiver compatibility, PoE requirements and uplink error rates before changing application rules. A phone with inadequate power or a congested uplink may present as an intermittent application failure. Record the intended port role and connected device so that replacing a failed switch does not require reconstructing the entire configuration from discovery alone.

Build FortiLink adoption and provisioning deliberately

FortiLink enables FortiGate-managed deployment and policy coordination, but successful discovery requires network reachability and correct controller/device association. Map the intended interface or aggregate, device authorization, switch stacking and supported topologies before connecting production clients. A switch may have power and working local forwarding yet remain absent from central management because the adoption path is broken. Diagnose FortiLink separately from the customer VLAN traffic to avoid changing unrelated data-plane configuration.

After onboarding, verify that templates and per-port settings are applied to the correct hardware. A managed switch can have different transceiver inventory or interface numbering from the unit it replaces. If operating in standalone mode, identify which actions are configured locally and which centralized procedures no longer apply. Change control should record the management model so that staff do not assume a standalone device will receive FortiGate-pushed security changes. Practice recovery after a controller outage or management-link failure without disabling user access controls.

Control loops and redundancy with explicit expectations

Redundant cabling can improve resilience but also create Layer 2 loops. Spanning Tree Protocol establishes a forwarding topology and blocks redundant paths when appropriate. Understand how root selection and port state affect application traffic during convergence. Link aggregation and multichassis designs can improve capacity and availability, yet only when the peer and switch configurations agree. Misaligned aggregate membership, VLANs or control protocols can produce packet loss that looks like a firewall or server problem.

Before adding a new uplink, document the expected active paths, failure behavior and recovery time. Test one failed link at a time and measure which services remain reachable. A switch that forwards normally in the lab may fail under a large broadcast or multicast load. Use storm control and other Layer 2 protections with values appropriate to the actual environment; a control that is too aggressive can drop legitimate application traffic. The objective is predictable failure rather than simply maximizing the number of physical links.

Apply access controls at the correct layer

Port security, MAC limits, ACLs, DHCP snooping, antispoofing features and VLAN isolation solve related but different problems. A device that passes a MAC-based check may still be unauthorized at the application layer, and a correctly authenticated user can still reach an unintended network if VLAN mapping is wrong. Plan controls from endpoint role and business requirement, then verify effective forwarding and denial. Avoid treating a large guest VLAN as a trustworthy location merely because it is behind the same FortiGate.

For phones, printers and unmanaged devices, account for features and identities the hardware can actually supply. A permanent broad exception may be easier than authenticating an older device, but it creates a lateral-movement path if that device is compromised. Link each exception to a restricted segment and monitoring requirement. Switching and VLAN boundaries should remain an operationally visible part of access policy; the firewall cannot compensate for every mistaken trunk or port assignment.

Use QoS and LLDP-MED to protect real-time services

Voice traffic often suffers before ordinary file transfers when uplinks become congested. Traffic classification, priority queues and markings can help when configured consistently across switches, gateways and the application. LLDP-MED can assist with voice-device information and network policy delivery in supported environments. However, marking every packet as high priority defeats the usefulness of QoS. Define which applications actually require low latency and verify whether upstream links respect the same policy.

During a voice-quality complaint, measure packet loss, jitter, uplink utilization and client/device port health. Compare busy and quiet periods, and check whether the problem began after a port-profile or VLAN change. A high-rate speed test may be successful while a sensitive real-time call performs badly. The goal is to preserve the application's quality requirements through controlled classification and capacity planning rather than applying priority settings without evidence.

Monitor and troubleshoot at the switch boundary

Use interface status, MAC learning, LLDP neighbor information, logs and packet captures where supported to locate the failure point. A host reporting a DHCP failure may have a misconfigured access VLAN, a blocked uplink, a rogue DHCP source or an unavailable server. Diagnose in an order that follows the packet path. When a port enters an error state, record its reason and change history before clearing it. Repeatedly resetting the port can hide a recurring cable or security-control fault.

For centrally managed switches, compare the configuration pushed from FortiGate with local behavior and the expected port role. If management is unavailable, determine whether the data plane is functioning and whether a safe local recovery is documented. Limit collection of endpoint-sensitive information and retain just enough evidence to explain the issue. A reliable incident record allows a second engineer to reproduce observations, not merely see that 'switch restarted' was the temporary fix.

Plan replacement and recovery without unexpected VLAN exposure

Switch replacement is a useful test of whether the network design is actually maintainable. An access switch may fail after years of local exceptions, changed port descriptions and moves that never reached the central documentation. Before replacing it, inventory its logical role: management relationship, FortiLink uplinks, VLAN membership, trunk or access port roles, QoS settings, endpoint identity policy, aggregate links and PoE needs. A replacement with different interface numbering or hardware capabilities cannot always receive the old profile without adjustment. The recovery plan should distinguish essential service restoration from temporary compromise of security policy.

Stage the new device with management connectivity and a known-good software version, then apply approved configuration in a test context. Verify one representative client in each protected network, a voice endpoint, and an intentionally unauthorized device. Observe whether the same VLAN and firewall rule are selected as on the original device; do not accept 'the link is up' as a sufficient test. If the switch becomes unreachable after adoption, use the defined recovery procedure rather than factory-resetting it repeatedly while users remain connected. Finally, update the asset inventory and record which exceptions were intentionally retained or retired. This process proves that FortiLink centralization and access controls can survive routine hardware failures without making operators rebuild the trust model from memory.

When a FortiSwitch stack carries both user data and voice, physical redundancy does not guarantee service reliability. Model the consequences of one failed uplink and verify how aggregation, spanning tree and VLAN reachability behave during the transition. A trunk that comes up without the voice VLAN can make phones register intermittently while ordinary laptop traffic appears healthy. LLDP-MED and PoE state provide different evidence from IP-layer availability; inspect both before blaming the voice application. Schedule a maintenance test that disconnects one member, measures convergence and checks whether management reachability survives. If the backup path crosses a different policy boundary, verify that the failover does not broaden access. Save the intended configuration and a port-to-device record so a replacement switch can restore correct roles promptly. The goal is not just to keep ports lit, but to preserve the authorized application experience through a real fault.

Practice a multi-site change that needs rollback

Create a lab with two FortiSwitch devices, a FortiGate management path, a voice or priority-marked client, and multiple VLANs. Onboard the switches, verify FortiLink health, assign protected access ports and create a redundant uplink with a documented forwarding path. Introduce a mis-tagged trunk, an incorrect port-security limit and a failing PoE or transceiver condition one at a time. Predict which observations will change, then verify with counters, discovery information and a representative application flow.

Finally push a controlled template revision and practice returning to the known-good configuration if one target reacts differently. FortiSwitch administration is about connecting operational facts to a stable topology and policy state. The NSE5 7.6 scope expects familiarity with both centralized and standalone management; practical readiness means being able to explain exactly why a client was connected, blocked, or degraded and how to correct it without damaging the rest of the LAN.