Verify the campus, not just the link state.
Networking Foundations covered MAC learning and VLAN/trunk concepts. Now interpret forwarding and redundancy evidence across a multi-switch campus, including STP, EtherChannel membership and change impact.
Need a packet-path evidence refresh? Review Applied Phase 01 →
JUMP TO SECTIONChoose a lesson section
Use the MAC table to reconstruct the path.
Assume you already know source-MAC learning. In an incident, compare learned MAC/VLAN/port tuples on access, distribution and upstream devices. A MAC that repeatedly moves between ports, ages out unexpectedly or appears in the wrong VLAN is a clue about topology, teaming or misconfiguration—not an automatic diagnosis.
It is evidence of a source observed on a port in a VLAN, not proof that the destination host, gateway, DNS or application is reachable. MAC learning can also age out or move when a device changes location.
Broadcast traffic also remains within the relevant Layer 2 broadcast domain. A broadcast frame does not cross into an unrelated VLAN without another service or gateway being explicitly involved.
Verify a VLAN end to end, not just locally.
Given an approved campus design, trace each relevant VLAN from the client access port through the trunk allowed/active/STP-forwarding lists toward its routed gateway. A correct local VLAN assignment can coexist with an unreachable remote gateway.
Verify the actual connected port, operational switchport mode, and approved assigned VLAN.
Only approved allowed and forwarding VLANs should traverse the uplink.
A routed interface or SVI must provide Layer 3 forwarding and appropriate security policy.
VLAN membership must be supported by the network design and available end-to-end. Creating the same VLAN number independently on two switches is insufficient if the interconnecting trunk excludes it.
A trunk can be up and still carry the wrong VLANs.
IEEE 802.1Q tagging normally identifies VLAN context on a trunk. A native VLAN can be carried untagged depending on configuration and platform, so mismatched native VLAN assumptions deserve investigation. Do not treat dynamic trunk negotiation or allowed VLAN defaults as a substitute for an approved configuration.
Compare both endpoints using show interfaces trunk. Notice how allowed, active, and STP-forwarding VLAN lists can differ. Missing VLAN 20 in the allowed list is stronger evidence than the link LED.
If approved to add VLAN 20 to an existing allowed list, prefer an additive change that preserves VLANs 10 and 30. A replacement list containing only 20 may restore Finance while breaking unrelated services. Check syntax and actual device behavior before executing any production command.
STP discarding isn't automatically a failure.
Parallel Layer 2 paths can create a forwarding loop. Broadcast and unknown-unicast traffic may circulate, and the forwarding database may become unstable. Spanning Tree Protocol establishes a loop-free forwarding topology and selects which redundant ports should forward or discard for the relevant instance.
With Rapid STP, an alternate port may legitimately stay in the discarding state while another route is available. Root selection, path cost, and port roles determine the active topology. Depending on the implementation, behavior may be per VLAN, per spanning-tree instance, or over a common tree.
Compare observed root bridge IDs, STP roles, port costs, and the intended topology. An unexpectedly elected root may warrant an approved design correction; a standby alternate link may be working exactly as planned.
EtherChannel and LACP need consistency.
EtherChannel groups compatible physical interfaces into a logical port-channel. LACP can negotiate bundling where enabled. The intended benefit is resilient aggregate forwarding—not a guarantee that every member will always carry the same individual flow or that traffic doubles in speed on one conversation.
Members must have compatible attributes for the platform and mode: for example, consistent trunk/access behavior and VLAN settings. A channel can be partly operational even if an intended member is suspended or unbundled. Verify both the port-channel and each member.
Compare show etherchannel summary, LACP neighbor information, operational switchport mode, member status, and interface logs. Summary flags are vendor and release specific; do not apply Cisco flags blindly to another switch OS.
Know exactly what your check tells you.
| Observation | What it supports | What it does not prove |
|---|---|---|
| Interface shows connected | Physical/link-state observation | The VLAN, routed path or user service is working |
| VLAN exists in show vlan brief | VLAN configured locally, access ports listed | That an interswitch trunk carries the VLAN |
| Trunk is operational | Port operates as a trunk | That every VLAN is allowed, active and STP-forwarding |
| MAC table has a destination | Switch learned a source MAC on that VLAN/port | That the endpoint's application is healthy |
| STP reports discarding | Port is not forwarding for the relevant instance | That the port is broken or should be forced to forward |
| EtherChannel is up | Logical interface is reported operational | That every intended member is bundled and consistent |
Switch and routing diagnostics become useful when combined. Document expected VLAN membership, both ends of any interswitch link, STP forwarding state, learned MAC locations, the gateway path, and the actual service failure. Preserve before-and-after evidence where a change has been authorized.
show interfaces statusConfirm port link and access VLAN placement.
show vlan briefConfirm local VLAN existence and access-port assignment.
show mac address-table dynamic vlan 20Identify learned MACs and their current ports within VLAN 20.
show interfaces trunkCompare allowed, active, and STP-forwarding VLAN lists on trunks.
show interfaces Gi1/0/48 switchportCheck operational versus administrative switchport mode and access/native VLANs.
show spanning-tree vlan 20Identify root, cost, port role, and forwarding/discarding state.
show etherchannel summaryInspect the logical channel and whether expected members are bundled.
show lacp neighborReview LACP partner information where supported.
Commands above illustrate Cisco IOS/IOS XE style syntax and depend on device platform and permissions. These are read-only observations, not an invitation to execute changes without a ticket and approval.
Four incidents. Twelve engineering decisions.
Investigate a missing trunk VLAN, an STP standby path, an inconsistent EtherChannel, and a moving MAC. Each case asks you to defend an evidence-based next action. Try to predict the answer before selecting it, and repeat any case you miss.
What does the evidence actually prove?
Investigate four fictional switch incidents. You can revisit any decision. Commands are illustrative read-only checks, not an active CLI.
Finance VLAN 20 works on SW-A but fails for users behind SW-B. The interswitch link is up.
Confirm the fault domain
SW-B: show vlan brief → VLAN 20 active; user port Gi1/0/7 assigned to VLAN 20. show interfaces status → Gi1/0/7 connected.Read-only check: show interfaces trunk
A corrected switch config is not a verified incident resolution.
Before proposing a configuration change, identify affected sites, ports and VLANs, check your organization's maintenance and approval requirements, capture the current approved baseline, and define a rollback that can actually restore service. Avoid broad shutdowns, blanket VLAN allowances, or disabling STP as generic fixes.
Which users, services and VLANs fail? Which paths still work?
Keep before-state interface, trunk, STP, and channel evidence.
Keep unrelated VLANs, redundancy and policies intact.
Test the reported user workflow, plus neighboring services and rollback criteria.
Even a correct Layer 2 adjustment does not rule out DNS, routing, ACL, or application failures. Record what was verified and what remains unknown. That's how a technician investigation becomes a defensible change record.
Now investigate a campus switch problem.
Complete the original Campus Evidence Review Practice, then try the optional Missing VLAN Lab. You can also use Troubleshooter to work through a VLAN/trunk investigation and produce structured ticket notes.
Finish the lesson before testing campus switching decisions. Then apply the evidence in Practice and an optional Lab.