A switched topology is a forwarding system, not just a drawing of cables
The most useful way to study switching is to follow one Ethernet frame at a time. Ask where the frame enters, which VLAN it belongs to, what source MAC the switch learns, whether the destination MAC is known, which links are eligible to carry the frame, and where the Layer 2 domain ends. This turns topology diagrams into operational evidence instead of memorization.
The switch learns where senders are
When a frame arrives, the switch records the source MAC address on the ingress port for the relevant VLAN. That learning is dynamic. If the device moves and transmits from another port, the switch can update the entry. If the device disappears long enough, the entry can age out.
A learned destination narrows the forwarding path
If the destination MAC already exists in the MAC table for that VLAN, the switch forwards the frame toward the associated port rather than sending it everywhere. That is the normal selective-forwarding behavior that distinguishes a switch from a hub.
Flooding is how a switch handles a destination it has not learned
If the destination MAC is unknown, the switch floods the frame through eligible ports in the same VLAN except the ingress port. When the destination replies, switches along the path learn the return source MAC, so later traffic can become known unicast.
A VLAN defines the Layer 2 broadcast boundary
Ethernet broadcast frames such as ARP requests are delivered throughout the VLAN, not across unrelated VLANs. This is one reason VLANs are useful for segmentation: they create separate Layer 2 broadcast domains even when devices share the same physical switch infrastructure.
An access port places an ordinary endpoint into one VLAN
In a common access-port design, the endpoint sends ordinary untagged Ethernet frames. The switch associates those frames with the configured access VLAN. A wrong access VLAN can therefore produce a completely healthy physical link while the host receives the wrong DHCP scope or cannot reach expected peers.
One physical link can carry several VLANs
A trunk allows multiple VLANs to cross the same inter-switch or switch-to-router infrastructure link. VLAN tagging commonly preserves the logical network identity while frames travel over the shared cable.
Access link
Usually one endpoint VLAN.
Trunk
Several VLANs over one link.
Key evidence
A working VLAN proves the physical trunk can carry traffic.
One VLAN can fail while the trunk itself remains up
The shared link is already proven operational for VLANs 10 and 20. The stronger branch is VLAN 30 allowance, VLAN existence, or tagging—not a dead cable.
The same switch keeps logical forwarding contexts separated
MAC-table entries should be read with VLAN context. Seeing a host MAC on the expected physical port but under the wrong VLAN can be direct evidence of logical misplacement.
The cable and port may be fine. The logical placement is wrong.
Predict forwarding before looking at a command output
If Switch A knows BB is reachable through port 24, it forwards only to the trunk. Switch B then forwards only to port 8. If Switch A does not yet know BB, it floods the frame inside the VLAN, including the trunk, until learning occurs from the reply.
One exchange can teach both switches
Two Layer 2 paths can create a forwarding loop
Redundancy is valuable, but arbitrary Layer 2 forwarding across parallel paths is dangerous. Ethernet broadcasts and unknown unicasts can circulate because Ethernet frames do not have an IP-style TTL that naturally stops them after a set number of hops.
STP keeps physical redundancy while creating a loop-free forwarding topology
Spanning Tree Protocol and related mechanisms prevent Layer 2 loops by placing redundant links or ports into non-forwarding states when necessary. If the active path fails, a previously blocked path can transition according to protocol behavior.
Rapid MAC movement can expose an unexpected Layer 2 path
If the endpoint is not intentionally moving, rapid alternation between infrastructure ports can indicate a loop, miswired connection, duplicate bridging path, or another topology problem.
One slow application is not enough to diagnose a switching loop
Broadcast storms usually have broad scope. Look for abnormal broadcast or multicast rates, rapidly increasing interface utilization, widespread loss, unstable MAC learning, topology events, and multiple affected hosts. The scope should match a shared Layer 2 failure.
Failure scope follows shared components
In a star, each endpoint connects to a central switch. An endpoint cable failure affects one endpoint, while failure of the central switch affects all attached devices. In a hierarchical star, a shared uplink or distribution device can affect multiple downstream access segments.
Use the diagram to predict the failure domain before testing
If one access switch loses upstream connectivity while neighboring access switches remain healthy, investigate that switch's uplink or local path. If several access switches behind the same distribution device fail together, the shared distribution or upstream dependency becomes stronger.
Local same-switch traffic works, but remote-switch traffic fails
Local switching is proven. Inspect the inter-switch path, trunk state, VLAN allowance, and whether the remote switch has the VLAN defined and forwarding.
VLAN 10 crosses the uplink but VLAN 20 does not
This is one of the highest-information switching signatures. The uplink cannot be completely dead if VLAN 10 is using it successfully. The next inspection should be specific to VLAN 20.
Same-VLAN traffic works, but inter-VLAN traffic fails
If hosts communicate within VLAN 20 but cannot reach VLAN 30, the switch may already be forwarding Layer 2 traffic correctly. Move upward to the default gateway, SVI/router interface, route table, and firewall/policy.
A host is missing from the MAC table after expected transmission
If an endpoint is known to be transmitting but the access switch never learns its source MAC, inspect the endpoint link, interface state, access VLAN, cabling, NIC behavior, and whether traffic actually reaches that switch port.
The MAC appears upstream, but not where you expected
The upstream MAC location can reveal an unintended path, wrong physical attachment, loop, or topology mismatch. MAC tables can therefore be used as a path-tracing artifact, not just as a local switch table.
Tagged VLANs can work while untagged traffic fails
If trunk endpoints disagree about the native or untagged VLAN, tagged VLANs may continue to pass while untagged frames land in different logical networks. That creates a partial failure that can be misread as a generic trunk problem.
MAC and topology artifacts prove Layer 2 facts—not the entire application path
| Artifact | What it proves | What it does not prove |
|---|---|---|
| MAC learned on access port | Source traffic arrived there | Gateway or application works |
| MAC learned toward trunk | Source traffic came through that trunk path | Destination service works |
| VLAN 10 crosses trunk | Physical trunk can carry traffic | VLAN 20 is correctly allowed |
| Same-VLAN peer works | Local Layer 2 forwarding works | Inter-VLAN routing/policy works |
| STP blocks a port | Port is intentionally non-forwarding | Physical link is bad |
Swipe horizontally to see the evidence boundaries.
Trace the first failed Layer 2 boundary
- Confirm physical/admin link state.
- Confirm access VLAN or dynamic VLAN placement.
- Confirm source MAC learning on the expected port and VLAN.
- Confirm the VLAN exists and is carried across required trunks.
- Use a working VLAN as a control for the shared trunk.
- Check loop-prevention state on redundant links.
- Move to the gateway only after Layer 2 forwarding is proven.
- Verify the original failed path and a known-good control after changes.
Predict the path before you read the MAC table
When A first sends to B, both switches learn A's source location. Because B is unknown, the frame floods only in VLAN 10. Host C in VLAN 20 should not receive the frame. B's reply teaches the reverse location, after which A-to-B forwarding becomes selective.
Now remove VLAN 10 from the trunk. A and B cannot exchange frames across switches, but Host C's VLAN 20 path can remain healthy if VLAN 20 is still permitted. That is a logical partial failure, not a total uplink failure.
A switching fix must restore the failed VLAN without damaging known-good paths
If you add VLAN 20 to a trunk, confirm VLAN 20 cross-switch communication now works and VLAN 10 still works. If you correct an access VLAN, confirm the endpoint receives the intended subnet and can reach expected same-VLAN peers. If you change STP or redundancy, verify loop-free forwarding and failover behavior according to the design.
Strong answers describe the forwarding mechanism
Instead of saying “the trunk is broken,” say: “VLAN 10 crosses the trunk successfully, so the shared physical link is operational. VLAN 20 works locally but is absent from the trunk allowed set, making VLAN 20 trunk carriage the first failed boundary.”
24 Switching Topologies digital flashcards
Practice MAC learning, known and unknown unicast, VLAN broadcast domains, access ports, trunks, partial failures, STP, loops, MAC flapping, topology scope, evidence boundaries, and verification.