FortiSwitch 7.6: Loops, LAGs, and Resilient Design

A switch stack can look healthy for months and then bring down an entire floor when a technician moves one cable. The link lights remain green, the interfaces negotiate correctly, and the change seems trivial. Yet a previously blocked path may start forwarding, a loop may multiply broadcast frames, or a redundancy mechanism may have been configured without understanding its failure assumptions. For engineers preparing for the Fortinet NSE 5 FortiSwitch 7.6 Administrator exam, resilient switching is less about memorizing commands than knowing what each topology is intended to survive—and which conditions can defeat it.

The distinction matters because the exam is part of NSE 5 Secure Networking, not an invented NSE 7 FortiSwitch credential. Its current objectives include stacking-related ports, switching and routing, Spanning Tree Protocol, supported deployment topologies, and troubleshooting. Earlier articles in this FortiSwitch series cover the management modes and everyday provisioning. This one follows a narrower question: how do several interconnected switches provide useful alternate paths without turning one fault into a campus-wide outage?

Redundancy is a design claim that must be tested

Consider a small hospital with two distribution switches and a pair of uplinks from each access closet. Management wants the network to survive one device or cable failure without losing access to clinical applications. That requirement sounds straightforward, but it is incomplete. Is the second path meant to carry traffic at the same time, or remain blocked until a failure? Does the gateway sit on one distribution switch? Is the inter-switch connection itself a single point of failure? How quickly must service return, and can the attached applications tolerate brief interruption?

Two cables drawn in a diagram do not automatically provide resilience. They may terminate on the same line card, use the same conduit, or depend on a shared controller. Some failures are obvious, such as a disconnected fiber; others are partial, like a switch that continues to advertise a control relationship while dropping user packets. A useful design records the failure domain for each component and states the observable result of losing it.

The engineer should separate three kinds of continuity: physical connectivity, correct Layer 2 forwarding, and availability of the routed service beyond the switching fabric. A surviving access uplink has little value when the VLAN has no reachable gateway. Equally, a healthy route does not help an endpoint whose switch port was left in an isolated or unauthorized state. Test plans should prove the complete application path rather than celebrate an interface returning to an up state.

Understand what Spanning Tree is preventing

In an ordinary Ethernet broadcast domain, a frame without an effective loop-prevention mechanism can circulate across redundant links. Switches learn source MAC addresses from incoming frames. With an uncontrolled loop, address learning can become unstable, broadcast and unknown-unicast traffic can proliferate, and congestion can affect devices unrelated to the original cabling mistake. Spanning Tree Protocol exists to choose a loop-free active forwarding topology while retaining alternate physical paths.

Spanning Tree is therefore not a substitute for knowing the physical design. Root placement influences which ports are selected for forwarding and which alternatives remain blocked. When an unexpected switch becomes root, traffic may traverse inefficient paths or rely on a weak uplink. Before changing bridge priority, inspect the current root, port roles, and whether deliberate topology decisions were documented. A well-behaved network should make its forwarding choices understandable.

Rapid convergence helps reduce disruption, but the word rapid does not excuse failing to measure. A business-critical session can still time out when a path changes, while some applications recover unnoticed. The right operational question is how the network actually behaves during a planned link removal and whether the resulting topology matches the design. Check MAC stability, link errors, reachable gateways, and representative application transactions after convergence.

Edge-port protection adds another line of defense. An access port connected to a user’s workstation should not unexpectedly become a bridge to a second switch. BPDU Guard addresses a specific class of unexpected bridge participation where the feature is appropriately supported and configured. It must be deployed with awareness of legitimate downstream devices: a port used for a managed switch cannot be treated exactly like a single-host edge port.

Build link aggregation around one logical relationship

Link aggregation combines suitable physical interfaces into a logical bundle. Its purpose may include more aggregate capacity and continuity after a member-link failure, provided the surrounding topology supports the arrangement. LACP helps participating endpoints negotiate membership and detect certain configuration mismatches. It does not promise that one application flow will use the sum of every physical link’s bandwidth.

That last distinction regularly causes bad capacity assumptions. Many switches distribute flows using a hash of packet fields. Several large flows may land on different members; one elephant flow may remain on one member and approach that member’s line rate. When assessing throughput, examine member utilization and the application traffic mix rather than dividing an aggregate interface counter by the number of cables.

A bundle should not be a convenient hiding place for differences in speed, VLAN membership, or upstream design. Confirm that all member ports share compatible operational characteristics and that both ends agree on the logical link. A port that belongs to the wrong bundle may be disabled by a safeguard, or, under an unsafe static arrangement, may contribute to unexpected forwarding. Do not change both aggregation and VLAN policies in the same outage response unless the evidence requires it.

The failure drill is simple but illuminating. Remove one physical member while generating a legitimate workload, observe the bundle’s remaining membership, and measure application impact. Restore it and verify stable redistribution. Then test the failure of the remote device or logical peer, which may expose a completely different dependency. A maintenance test that never removes a whole switch is not proof of switch-level redundancy.

Multichassis designs need a control-plane story

FortiSwitch deployments may use multichassis link aggregation group, or MCLAG, designs. Their attraction is clear: a connected device can have links to separate chassis while using a supported logical relationship. But distributing a logical function across hardware changes what must be coordinated. The operator has to understand peer connectivity, consistency of relevant settings, and how a failure is recognized by both devices.

A sensible MCLAG design specifies which links are peer connections, which carry downstream aggregates, what state is expected when one peer disappears, and how the environment avoids dual-active behavior. The temptation is to treat any pair of switches as interchangeable simply because both have uplinks. They are not interchangeable unless the documented topology and product support actually permit that deployment. Consult the FortiSwitchOS 7.6 and FortiLink documentation before copying configuration patterns from a different software or hardware generation.

Separate the common failure cases. If one downstream member fails, the logical connection may continue over the other member. If a whole switch fails, a surviving peer may preserve a path subject to the supported design. If the peer interconnection fails while both chassis stay powered, the implications can be more complicated than a plain cable failure. A robust operational design avoids assuming that all three conditions produce the same safe result.

The test should also cover restoration. When the failed peer returns, which device becomes authoritative for state? Can a stale configuration cause an unexpected port transition? Is the change visible through the current management system? Recovery is not finished when traffic passes once; stability after reintegration matters. Document observed behavior and keep a tested rollback so responders are not forced to improvise under pressure.

VLANs determine where continuity must be preserved

An alternate physical route helps only when the required VLANs remain available over that route. 802.1Q tagging permits multiple Layer 2 segments to cross suitable trunk links, but an allowed-VLAN list that differs between redundant paths can produce intermittent failures. A user may retain access to one application while losing another, making the symptom look like a routing or firewall problem.

In a design review, draw the path for each important class of traffic: ordinary user access, voice, device management, and any dedicated building systems. Note where tags are inserted or removed, which links carry the segment, and where traffic crosses into routed policy. Do not use the mere presence of a VLAN name as evidence that the entire path exists. Tagged frames must travel across every intermediate connection that needs them.

Be cautious with native or untagged VLAN assumptions. A mismatched untagged assignment can connect traffic to an unintended segment without presenting itself as an obvious physical fault. Keep access-port behavior explicit, audit changes to trunk membership, and confirm the endpoint’s expected address, gateway, and DNS path after a topology change. Segmentation is a design decision, not merely a visual organization tool in a switch interface.

There is a security dimension as well. A redundant topology that unintentionally bypasses the intended inter-VLAN enforcement point is not successful simply because traffic keeps flowing. Draw the trust boundaries alongside the alternate physical paths. A path-resilient network must remain policy-consistent when its topology changes; availability and control should be tested together.

Distinguish a layer-two storm from a routing fault

Suppose a distribution upgrade produces widespread slow connections, erratic voice calls, and high CPU consumption on several switches. It is tempting to assume the upstream firewall is overloaded. First look for the shape of the problem. Do interface error counters rise? Do MAC addresses repeatedly appear on different ports? Are broadcast rates abnormal? Did the issue follow the addition of a redundant link? Those observations make a loop or topology instability plausible, though they do not prove it alone.

A route failure has a different signature. Hosts may reach their own subnet while failing to reach the default gateway or distant networks, or the device may show a valid local forwarding table but an incorrect next hop. Confirm layer-by-layer evidence. Avoid indiscriminately disabling ports because the first one with a high counter may merely be carrying the effects of trouble elsewhere.

Use observation tools carefully. Where supported and authorized, port mirroring can help capture the types of frames and protocol messages crossing a relevant interface. Combine captures with STP state, LACP membership, event logs, and recent change records. A packet capture that omits the peer-side context may be as misleading as a single interface statistic.

When FortiGate manages the switch through FortiLink, compare what the controller reports with what the switch is doing locally. A FortiLink management issue can coexist with a healthy data path, and a forwarding problem may occur while the management relationship looks normal. The relevant skills for the NSE 5 FortiSwitch exam include troubleshooting captures and topology interpretation precisely because these planes can disagree.

Make resilience measurable before the maintenance window

A short acceptance plan is worth more than an elaborate, untested diagram. Identify the link and chassis failures the design claims to survive. For each one, record expected forwarding changes, maximum acceptable interruption, endpoints and applications to test, and the evidence that indicates policy remained enforced. Build a separate recovery step for returning a failed component to service.

Change control should include dependencies that engineers cannot infer from link lights: voice VLAN provisioning, authentication dependencies, monitoring reachability, transceiver compatibility, and the gateway location. If a test reveals that two uplinks actually use one upstream power domain, update the design rather than merely recording a passed port check. Failure testing is valuable because it challenges the diagram’s assumptions with physical evidence.

The central lesson for FortiSwitch 7.6 is that resilience involves controlled alternate behavior. Spanning Tree prevents dangerous Layer 2 loops, aggregation manages member links, supported multichassis arrangements coordinate separate devices, and VLAN design preserves intended service and trust boundaries. Treat each control as an answer to a specific failure, then prove that answer in a test. That is more useful than memorizing every feature name, and much safer than treating a spare cable as a complete high-availability strategy.