MAC Address Table Explained: Read What a Switch Learned—and What It Still Does Not Know

A switch learns from the source MAC, then makes a separate forwarding decision using the destination MAC

The most useful way to understand a MAC address table is to separate two operations students often blur together. Learning asks, “Where did this source MAC come from?” Forwarding asks, “Where should this destination MAC go?” The table connects those operations, but they are not the same event.

This five-step model explains most introductory switching artifacts and prevents a common mistake: saying a switch “learned” a device because that device appeared as the destination of traffic.

Why the source MAC—not the destination MAC—is the trustworthy clue for dynamic location learning

Suppose a frame enters port Gi1/0/7 in VLAN 10 with source MAC A and destination MAC B. The switch has direct evidence about A: A's frame physically/logically arrived through Gi1/0/7. It does not gain equivalent location evidence about B merely because B's address appears in the destination field.

After learning A, the switch separately searches for B. This distinction becomes powerful in troubleshooting because generating traffic from an endpoint can deliberately cause its source address to be relearned.

A missing destination entry changes the forwarding action: the switch floods first and learns later from source traffic

If destination B is unknown, the switch cannot select one learned egress location. It normally floods the unknown unicast to eligible forwarding ports in that VLAN except the ingress port. When B eventually transmits, its source MAC can be learned and future known-unicast forwarding becomes more selective.

This explains why “the MAC is missing” does not mean “the switch drops all traffic to that host.” Unknown-unicast flooding is specifically designed to permit delivery while learning catches up.

The same MAC text is incomplete evidence until you know the VLAN context

VLAN-aware switching keeps Layer 2 forwarding domains separate. A MAC learned in VLAN 20 does not automatically satisfy the expectation that the endpoint belongs in VLAN 10. In fact, a perfectly stable MAC entry in the wrong VLAN can be some of the strongest evidence of a placement error.

For the broader placement failure, see VLAN Mismatch Symptoms.

Entry type changes how you interpret persistence and movement

A dynamic entry is learned from observed source traffic and participates in normal aging behavior. A static entry is configured or fixed through a different administrative mechanism and should not be interpreted as fresh proof that a device recently transmitted on that interface.

This creates an evidence rule: always inspect the entry type before treating presence as recent observation. Configuration state and learned state are not interchangeable.

Combine two artifacts to move from an IPv4 address to a switch location

Swipe horizontally to see the full table.

This two-artifact technique is central to duplicate IP troubleshooting: ARP can expose two MACs claiming one IP, while the switch table helps trace both claimants.

The client MAC exists on the access switch but disappears from the expected upstream VLAN path

PC-A transmits in VLAN 30. Access Switch 1 learns its MAC on Gi1/0/18, VLAN 30. The distribution switch does not learn PC-A in VLAN 30 through the expected trunk even after controlled traffic is generated. Other VLANs cross the trunk normally.

This does not yet prove the trunk cable is bad. The evidence narrows the investigation toward VLAN-30 handling between those switches: trunk allowance, VLAN existence/state, tagging expectations, or related Layer 2 configuration. The working VLANs act as controls against a total physical-link failure.

An absent printer MAC after hours of silence is not equivalent to a disconnected printer

A printer has not generated traffic for a long period and its dynamic entry has aged out. A technician checks the table and concludes the cable failed. Before replacing anything, a controlled print or other transmission is initiated. The switch immediately learns the printer MAC on the expected port and VLAN.

The original table was accurate—it showed current learned state. The mistake was interpreting absence as a permanent physical fact rather than time-sensitive evidence.

Use expected state before deciding whether a table entry is good news

Expected:
  Client MAC 00:25:96:AA:10:01
  VLAN 10
  Access port Gi1/0/14

Observed:
  VLAN 20   00:25:96:AA:10:01   dynamic   Gi1/0/14

A weak answer says, “The MAC is present, so switching works.” A stronger answer says, “The switch is receiving source frames from the expected physical port, but it is learning them in VLAN 20 rather than the intended VLAN 10. Inspect the port's access VLAN and related Layer 2 configuration.” The difference is not more jargon; it is better comparison between observed and expected state.

Use the table to bound Layer 2 uncertainty, then deliberately hand off to the next layer

The table is most valuable when it reduces uncertainty. Repeating the same lookup after its question has already been answered is not additional troubleshooting.

State the observation, its Layer 2 meaning, the contradiction or expectation, and the next discriminating artifact

Observation: “Client C's MAC is dynamically learned on Gi1/0/14 in VLAN 20.” Meaning: “The switch has recently received source traffic from that MAC through that interface in VLAN 20.” Expected state: “Client C should be in VLAN 10.” Inference: “Physical attachment may be correct, but logical VLAN placement is inconsistent with design.” Next evidence: “Inspect the access-port VLAN configuration and confirm VLAN 10 across the intended path.”

This answer stays inside the evidence boundary. It does not claim DNS, DHCP, routing, or the application is broken before those dependencies have been tested.