A switch makes a local forwarding decision every time an Ethernet frame arrives
Switching becomes much easier when you stop treating the switch as a box that “connects devices” and instead follow the frame. The switch receives a frame on one port, learns from the source, identifies the VLAN context, looks up the destination MAC, and then decides whether to forward, flood, or filter.
To check source learning separately from destination forwarding, use the AP Networking Switching, VLANs, and Ethernet Practice Test. Its MAC-table and VLAN-path questions explain why a source is learned on arrival, why an unknown destination floods only within the relevant domain, and when routing is still required.
This sequence is also a troubleshooting model. If the source MAC never appears where expected, investigate before jumping to routing. If the source is learned correctly but the destination is unknown, flooding behavior becomes relevant. If both endpoints are in different VLANs, the packet must eventually cross a Layer 3 boundary.
MAC learning answers “where did this source come from?”—not “where is the destination?”
Suppose a frame from source MAC 00:11:22:33:44:55 enters port Gi1/0/7 in VLAN 30. The switch can learn that this source is reachable through Gi1/0/7 in VLAN 30. The destination MAC is then used for a separate forwarding lookup.
VLAN MAC Address Type Port 30 0011.2233.4455 DYNAMIC Gi1/0/7 30 00aa.bbcc.ddee DYNAMIC Gi1/0/18
If the next frame is destined for 00aa.bbcc.ddee, the table supports forwarding toward Gi1/0/18. The table does not prove the endpoint application is healthy, its IP configuration is correct, or the return path works. It is Layer 2 location evidence captured at a particular switch and time.
A MAC table is learned state, so capture timing matters
Dynamic entries can age out. An endpoint can move. A topology change can cause a MAC to be learned through a different port. That means “the MAC is missing” and “the MAC is on port 12” are observations that need time and topology context.
Before clearing a MAC table or bouncing a port, capture the failing state. Then generate traffic from the endpoint and watch whether the expected source MAC is learned. That before/after comparison is more informative than resetting the switch first and losing the evidence.
Known unicast, unknown unicast, broadcast, and same-port filtering produce different behavior
| Frame situation | Typical switch action | Diagnostic meaning |
|---|---|---|
| Known unicast | Forward toward the learned destination port in the VLAN | The table contains a location for that destination. |
| Unknown unicast | Flood to eligible ports in the VLAN except ingress | The destination has not been learned in the current table context. |
| Broadcast | Flood within the VLAN except ingress | The frame intentionally targets the Layer 2 broadcast domain. |
| Destination learned on ingress port | Filter rather than send it back out that port | The switch already believes the destination is reachable through the incoming segment. |
Swipe horizontally to see the full table.
Unknown unicast flooding is not the same as broadcasting. The destination MAC is still a specific unicast address; the switch simply lacks a learned location and therefore replicates the frame within the VLAN to find it.
VLAN membership controls where Layer 2 flooding is allowed to spread
A broadcast arriving in VLAN 10 is not normally flooded into VLAN 20. This is why two ports on the same physical switch can behave as if they belong to separate Layer 2 networks. VLANs create logical broadcast domains independent of the chassis holding the ports.
This gives VLAN evidence real diagnostic value. If an endpoint intended for VLAN 40 receives DHCP information belonging to VLAN 90, the lease is more than an addressing clue—it may reveal that the endpoint entered the wrong logical broadcast domain. See VLAN Mismatch Symptoms for the full diagnostic pattern.
An access port is a logical placement decision, not merely a physical jack
An ordinary endpoint can be physically connected, have link, and send Ethernet frames while still being placed into the wrong VLAN by switch configuration. That produces one of the most useful switching contradictions: physical connectivity succeeds while logical network placement is wrong.
If a printer is intended for VLAN 40 but its access port belongs to VLAN 90, the switch can learn the printer's MAC perfectly and DHCP can even succeed—just in the wrong broadcast domain. A “valid IP address” therefore does not prove correct VLAN placement.
Use VLAN Explained when you need the broader segmentation model.
A trunk preserves VLAN identity while multiple VLANs share one physical link
IEEE 802.1Q tagging allows VLAN-aware infrastructure to distinguish traffic for different VLANs on a shared trunk. The physical cable can be healthy while one VLAN fails because the failure is logical rather than physical.
This creates a powerful control test. If VLAN 10 works across a switch-to-switch link but VLAN 25 does not, the working VLAN supports the conclusion that the physical link can carry at least some traffic. The next evidence should become VLAN-specific: allowed-VLAN state, tagging expectations, VLAN existence, endpoint placement, and MAC learning on both sides.
One working VLAN can eliminate a broad “trunk is down” hypothesis
Expected across trunk: VLANs 10, 20, 25, 40 Switch A allowed: 10, 20, 25, 40 Switch B allowed: 10, 20, 40 Observed: VLAN 10 hosts communicate across the link. VLAN 25 hosts communicate locally but not across the link.
The evidence fits a selective VLAN-25 trunk problem far better than total physical-link failure. Switch B's allowed set omits VLAN 25, while VLAN 10 provides a working control across the same link.
The repair should be narrow: correct the intended VLAN allowance rather than rebuilding unrelated routes or changing host IP addresses. Verification should retest VLAN 25 across the trunk and confirm that other VLAN behavior remains as intended.
Read a MAC table as a map of observed Layer 2 source locations
Expected MAC, expected port
Supports the assumed Layer 2 attachment at capture time. It does not prove higher-layer success.
Expected MAC, wrong port
Challenges the assumed topology and can point toward cabling, an intermediate switch, endpoint movement, or another attachment path.
Expected MAC, wrong VLAN
Supports a logical-placement mismatch and can explain unexpected DHCP or segmentation behavior.
MAC absent
Check whether the endpoint generated traffic, whether the port/VLAN is correct, whether the entry aged out, and whether you are inspecting the right switch.
MAC moves repeatedly
Investigate topology changes, redundancy behavior, loops, or unusual endpoint arrangements before assuming a stable attachment.
Many MACs on one uplink
This can be completely normal when that port leads toward another switch containing many endpoints.
For deeper artifact practice, use MAC Address Table Explained.
Same-subnet communication and inter-VLAN communication cross different boundaries
Two hosts that correctly believe they share a local subnet can communicate through switching without sending the traffic to a router. They resolve a local Layer 2 destination and exchange frames through the switched domain. If they are in different VLANs/subnets, a Layer 3 device must route between those networks.
This distinction prevents wasted troubleshooting. If two intended VLAN-30 peers cannot communicate, changing a remote route may do nothing because the failure can occur before routing is involved. If VLAN 30 can reach its gateway but cannot reach VLAN 40, then inter-VLAN routing or policy becomes relevant.
ARP evidence and MAC-table evidence answer related but different questions
For IPv4, ARP maps a local IPv4 address to a MAC address. A switch MAC table maps observed source MAC addresses to switch ports within VLAN context. Pairing the two can connect an IP-layer identity to a Layer 2 location, but neither artifact alone proves the entire chain.
If Host A's ARP cache says 10.30.0.25 maps to MAC X, and the switch learns MAC X on the expected VLAN-30 access port, the artifacts reinforce one another. If the MAC appears in VLAN 90 instead, the contradiction becomes valuable evidence.
Redundant links improve resilience only when Layer 2 loop behavior is controlled
At Layer 3, TTL or Hop Limit eventually limits packets caught in a routing loop. Ordinary Ethernet switching does not provide an equivalent per-frame Layer 2 TTL. In an active switching loop, broadcast and unknown-unicast traffic can be replicated and circulate repeatedly.
Symptoms can include rapidly increasing broadcast traffic, severe network degradation, unstable MAC learning, and repeated MAC movement. These are clues, not proof by themselves. Correlate them with topology and spanning-tree evidence.
See Network Loop and Broadcast Storm for focused failure analysis.
Spanning Tree can intentionally stop a redundant Layer 2 path from forwarding
Spanning Tree Protocol and related variants create a loop-free active topology by preventing every redundant path from forwarding simultaneously. A physical link can therefore be connected and operational while its current spanning-tree role keeps it from forwarding ordinary user traffic.
That state is not automatically a fault. The path may exist specifically as redundancy and become useful after another path fails and the topology reconverges. Troubleshooting should distinguish an intentionally non-forwarding redundant path from a port that should be forwarding but is not.
A valid DHCP lease can expose the wrong VLAN instead of proving the switch configuration is correct
Observed: Link is up. Printer receives 10.90.6.44/24 with gateway 10.90.6.1. Switch learns the printer MAC on access VLAN 90.
The strongest explanation is not “DHCP is broken.” DHCP succeeded in a way that is consistent with VLAN 90. The endpoint's lease and the switch's MAC/VLAN evidence independently point toward the same logical placement.
The next action is to compare the access-port configuration with the intended design. After correcting placement, renew or reacquire configuration as appropriate and verify that the printer receives VLAN-40 addressing and that the required service works.
When two local peers fail, prove the Layer 2 path before inventing a routing problem
Host B: 10.30.5.20/24, intended VLAN 30.
Observed: A cannot resolve B's MAC; switch learns A in VLAN 30 but learns B in VLAN 50.
Both host IP addresses look like local /24 peers, but the switch evidence shows they occupy different Layer 2 broadcast domains. A's local ARP request in VLAN 30 will not simply be flooded into VLAN 50. That explains why the hosts can classify each other as local yet still fail to establish the expected Layer 2 adjacency.
Changing a default route would not repair this mechanism. Correct the VLAN mismatch, then verify ARP/neighbor resolution and the original peer communication.
The shape of the outage tells you which switching evidence deserves priority
| Scope | High-value switching evidence | Why |
|---|---|---|
| One endpoint | Port state, access VLAN, MAC learning, endpoint config | Shared infrastructure may be healthy for peers. |
| One VLAN on one switch | VLAN existence, access assignments, local MAC learning | The failure is logically scoped. |
| One VLAN across switches | Trunk allowance/tagging, MAC learning on each side | Working VLANs can serve as controls. |
| Many VLANs across one link | Physical/uplink state, trunk state, topology | A shared path becomes more plausible. |
| Widespread instability | STP/topology, MAC movement, broadcast load | Loop or topology-change hypotheses gain value. |
Swipe horizontally to see the full table.
Six switching observations that students commonly overclaim
“Link is up.”
Supports physical/link-layer state, not correct VLAN, IP, routing, DNS, or application behavior.
“MAC is learned.”
Shows observed source location in VLAN context, not end-to-end application health.
“VLAN 10 works.”
Useful control for shared infrastructure, but does not prove VLAN 25 is allowed or configured correctly.
“Trunk is up.”
Does not prove every intended VLAN crosses it.
“STP blocks a path.”
Can be intentional loop prevention rather than a failure.
“DHCP succeeded.”
Does not prove the lease came from the intended VLAN/subnet.
24 network switching evidence flashcards
Use these as reasoning cards rather than vocabulary cards. Before revealing the answer, identify the frame behavior or artifact involved and state one conclusion that would go beyond the evidence.
Use expected placement → observed learning → forwarding boundary → next discriminating test
Start with the design expectation: which VLAN and port path should contain the endpoint? Then inspect observed state: link, access/trunk configuration, MAC learning, and relevant host addressing. Identify the first boundary where expected and observed behavior diverge.
If the endpoint MAC is learned in the wrong VLAN, investigate placement before routing. If local learning is correct but the MAC never appears across the expected trunk, inspect VLAN-specific trunk behavior. If Layer 2 evidence is correct through the gateway and the destination is remote, move the investigation to Layer 3 rather than continuing to change switching state.
This approach fits the broader AP Networking Troubleshooting Guide: preserve known-good evidence and choose the next test that separates the remaining explanations.
Keep MAC/VLAN forwarding and IP-prefix forwarding in separate mental models
A switch normally forwards an Ethernet frame using destination MAC information inside a VLAN. A router forwards an IP packet using a destination IP prefix in a routing table. When a host sends to a remote network, the IP destination can remain the remote server while the first Ethernet frame is addressed to the local default gateway's MAC.
The switch does not need the remote server's route to deliver that first frame to the gateway. Likewise, the router's route table does not identify the client's original access switch port. Each artifact belongs to a different forwarding boundary.
Continue with Routing for AP Networking when the packet crosses that Layer 3 boundary.
A switching repair should restore the failed path without silently changing segmentation
Verification should reproduce the original requirement, not stop when a configuration screen looks correct. After correcting an access VLAN, verify the endpoint appears in the intended VLAN, receives or retains appropriate addressing, resolves required local neighbors, and reaches the intended service.
After changing a trunk, verify the affected VLAN crosses the link and confirm that unrelated VLANs still behave correctly. After a loop or spanning-tree change, verify stable forwarding and expected redundancy behavior. In segmented networks, also confirm that traffic intended to remain isolated is still isolated.
Build answers from observation → Layer 2 mechanism → bounded inference → next evidence
Observation: “VLAN 10 communicates across the inter-switch link, but VLAN 25 does not; Switch B's allowed-VLAN list omits 25.” Mechanism: “A trunk can carry some VLANs while excluding another.” Bounded inference: “The evidence supports a VLAN-25-specific trunk mismatch rather than total link failure.” Next action: “Compare the intended trunk configuration, correct the VLAN-25 allowance if justified, and retest VLAN 25 while preserving other VLAN behavior.”
That is stronger than “the switch is broken” because it explains the selective symptom and respects what the working control proves.