Trunks, LACP and STP: A Campus Switching Lab
Trunks, LACP and STP: A Campus Switching Lab
A campus outage after a switch replacement is not always a routing fault. The router may be healthy while one VLAN is missing from a trunk, an EtherChannel member is not bundled, or spanning tree has correctly blocked a redundant path. A strong CCNA switching exercise forces these possibilities apart using forwarding evidence rather than a habit of shutting and reopening ports.
The lab uses three switches, two client VLANs and a redundant uplink. It tests 802.1Q tagging, LACP negotiation and Rapid PVST+ behavior in a controlled topology. Where Cisco IOS commands vary by model or software release, confirm the syntax in the lab’s own running configuration. Never disable loop prevention as a shortcut in a production switched network; a broadcast storm can turn a local experiment into a larger outage.
| Suspected layer | Useful command or observation |
|---|---|
| Trunk and VLAN | show interfaces trunk; show interfaces switchport |
| Port-channel and LACP | show etherchannel summary and member compatibility |
| Spanning tree | show spanning-tree vlan [id] and expected root/path |
| Client forwarding | Gateway reachability, path for each affected VLAN |
Draw a loop on purpose, then explain why it is safe
Connect access switches SW2 and SW3 to distribution switch SW1, then add a link between SW2 and SW3. With correct spanning-tree operation, the physical topology contains redundancy but the forwarding topology should remain loop-free for each spanning-tree instance or VLAN. Mark the expected root bridge and the alternate path on paper before checking device output. This teaches why a blocked port can be a normal protective state rather than evidence of broken cabling.
Assign VLAN 10 to staff clients and VLAN 20 to test devices. Choose which ports are access and which should carry multiple VLANs. Verify with hosts in the same VLAN first, then test routed communication through an authorized Layer 3 interface. Do not diagnose a trunk until you know what traffic it is supposed to transport. A successful management ping to the switch does not prove the staff VLAN is present on every uplink.
Use trunk output to verify actual VLAN transport
On many Catalyst IOS platforms, show interfaces trunk identifies trunking interfaces, their encapsulation where relevant, and the VLANs allowed and active on those trunks. show interfaces switchport can reveal the administrative and operational access/trunk mode of an interface. Compare both ends of an uplink; a native VLAN mismatch or an omitted VLAN may produce selective reachability, and a link that has negotiated access mode might not carry tagged client traffic as planned.
Introduce a fault by excluding VLAN 20 from the allowed list on one uplink while keeping VLAN 10 working. The observation matters: one group of clients reaches its gateway while the other cannot. The corrective action is to reconcile the intended trunk policy, not to add a global default route. Document which output proved VLAN 20 was missing and which post-fix test confirmed both VLANs could reach their designated gateway.
EtherChannel is a logical bundle, not merely two active cables
LACP lets compatible switches negotiate link aggregation; active and passive modes affect whether the protocol initiates negotiation. Two links can both report physical up while only one participates in the intended logical port-channel. The switch may isolate or suspend a member because of mismatched speed, duplex, trunk settings or other bundle compatibility requirements. Treat the port-channel as a separate operational object whose state must be verified.
Use show etherchannel summary to inspect the port-channel and member status. On supported platforms, member flags indicate whether each interface is bundled or suspended. A physical cable that is up but not bundled should trigger a comparison of both sides’ channel group, LACP mode and Layer 2 configuration. Do not assume that adding a second link necessarily doubles one application’s throughput; hashing distributes conversations according to configured fields and traffic patterns.
Make an LACP negotiation failure reproducible
Begin with two parallel switch links correctly bundled in one port-channel, carrying VLANs 10 and 20. Verify the intended protocol and member ports. Then misconfigure one end of a member so it no longer matches the bundle’s requirements. Observe whether the interface becomes suspended or otherwise excluded according to the platform. Record the difference between physical link state, port-channel state and the VLAN forwarding result.
Repair the smallest mismatched setting and verify that all intended members rejoin the bundle. Check that spanning tree sees the port-channel as the logical path and that client reachability remains stable. The same test on each VLAN catches errors concealed by a management-only ping. For operational repeatability, save the initial and corrected show etherchannel summary outputs alongside the relevant configuration snippet rather than writing “EtherChannel fixed.”
Spanning tree chooses paths to prevent loops
In a redundant Layer 2 topology, spanning tree elects a root and decides which path forwards for each relevant instance. Rapid PVST+ uses roles and states to converge while avoiding simultaneous forwarding around a loop. Inspect show spanning-tree vlan 10 and the equivalent output for VLAN 20 to see the elected root, designated paths and alternate or discarding paths. The output should be interpreted against the drawn topology rather than memorized as a list of flags.
Deliberately change bridge priority on an appropriate lab switch and observe how the root and alternate paths move. A different path for VLAN 20 is not automatically wrong; it can reflect per-VLAN root selection and design intent. What matters is whether the chosen forwarding tree remains loop-free and supports the client traffic. The distinction is explained in broader terms in VLANs, spanning tree and campus resilience.
One practical check compares the spanning-tree root ID shown on SW2 and SW3 for the same VLAN. If both switches believe they see different roots in a supposedly shared Layer 2 domain, the topology may be partitioned or tags may not be reaching both sides. That is more informative than guessing which cable is primary. Restore the intended VLAN carriage, verify that the root IDs agree, and then test whether the alternate link takes over after a controlled failure. This connects trunk health and spanning-tree state without treating them as the same feature.
Do not “fix” a blocked port by disabling protection
A common novice reaction to seeing a non-forwarding redundant port is to disable spanning tree or force the port to forward. That can create a Layer 2 loop and rapid amplification of broadcast and unknown-unicast traffic. In the lab, first prove that the port is an intended alternate. Then fail the primary uplink and observe whether the alternate becomes forwarding. The correct success condition is continuous or recovered service without a forwarding loop, not all links forwarding simultaneously.
Features such as PortFast and BPDU Guard have specific intended edge-port use. They are not generic commands to improve convergence on arbitrary switch-to-switch links. When a port is err-disabled, inspect the actual reason and the surrounding topology; do not clear the condition without fixing the unsafe connection or policy mismatch. Record the root cause that explains why protection activated.
Three similar symptoms, three different causes
Set up a controlled troubleshooting round. Case one: staff clients lose service because VLAN 10 is not allowed on one trunk. Case two: throughput or redundancy appears abnormal because one LACP member is excluded from the port-channel. Case three: a redundant uplink is intentionally blocked by spanning tree and becomes active only after the primary path fails. Do not identify the cause from a single disconnected command line.
Require the learner to compare show interfaces trunk, show etherchannel summary and show spanning-tree vlan with the expected diagram. Each output answers a different question: are VLAN tags passing, are physical links actually bundled, and which Layer 2 path is permitted to forward? The exercise is passed when the learner can explain why two of the three observations are not the root cause in each case.
Verify forwarding after every intended change
A corrected trunk should carry precisely the intended VLANs—not indiscriminately all available VLANs. A repaired LACP bundle should show the expected member state and restore its designed resiliency. A spanning-tree adjustment should preserve a loop-free forwarding structure and failover behavior. Check end-to-end traffic before and after, including each affected VLAN, and compare switch state rather than relying on a link light.
This discipline applies whether the exam is based on current CCNA v1.1 or the revised version scheduled for February 2027. Cisco has signaled more practical troubleshooting in the future syllabus, but there is no need to wait for a version refresh to practice evidence-led switching. A clean lab record contains topology, intended VLAN paths, actual port-channel membership, elected root, observed fault, constrained correction and proven client reachability.
Extend the lab only when the base is stable
After demonstrating basic VLAN, trunk and STP behavior, introduce a routed interface for inter-VLAN communication, then deliberately remove a return route or apply a narrow ACL. This extension shows why an access-layer symptom can coexist with a correct trunk and an incorrect Layer 3 policy. Do not collapse these into the same problem: verification of the switching fabric should come before changing routes.
The final outcome should be a campus topology that survives one planned uplink failure and forwards only the VLANs authorized by the design. The time spent proving that result is more valuable than adding dozens of switches with undocumented behavior. Readers preparing for a networking role should be able to explain why the redundant path was blocked, when it should become active and how a mismatch is detected without trial-and-error port changes.
- Category: Certifications Cisco
