How Switches Work: MAC Learning, Flooding, and the MAC Table

A switch with an empty MAC address table behaves like a hub: the first frame it ever sees gets copied out every port. Seconds later it stops doing that, because it has started learning. By reading the source address of every frame that arrives, the switch builds a table that maps each MAC to the one port it lives behind, and from then on it forwards traffic to that single port instead of all of them. That table, how it fills, how it ages, and what the switch does when an address is missing from it, is the whole of how a switch forwards frames.

This guide walks the exact, observable behavior on real Cisco switches: how MAC learning records the source MAC and ingress port, how the aging timer expires stale entries, the forward-versus-flood decision, and how to read show mac address-table output, including the one detail the exam loves, where a host shows up in the table of a switch it is not directly connected to.

Captured every show command below on two Cisco IOSvL2 switches running IOS 15.2 in GNS3, June 2026.

If you need to move around the switch CLI first, the IOS CLI shortcuts cover the modes and filters used here, and the lab runs on the same two switches from the base device configuration.

What a MAC address table is

The MAC address table is the switch’s forwarding database. Each row maps a destination MAC address to the single egress port that reaches it, scoped to a VLAN. When a frame needs forwarding, the switch looks up the destination MAC in this table and sends the frame out only the port the table names. That one lookup is the difference between a switch and a hub: a hub has no table and floods every frame out every port, while a switch learns where things are and forwards selectively.

Every row carries four fields, and reading them in order tells you everything the switch knows about a host:

How MAC learning works

The switch learns from the SOURCE MAC of every incoming frame, never the destination. When a frame arrives on a port, the switch reads its source address, notes the port it came in on and the VLAN, and writes a dynamic entry: this MAC lives behind this port. If the entry already exists, the switch refreshes its timer instead of adding a duplicate. Destinations are only ever looked up, never learned, because the switch has no idea which port a destination is on until that device sends a frame of its own.

Here is SW1’s table after the two hosts in the lab exchanged traffic. H1 is wired to SW1’s Gi0/1, and H2 sits one switch away across the uplink on Gi0/0:

Three dynamic entries, all in VLAN 1. H1’s MAC ca01.0758.0008 sits on Gi0/1, the port it is physically plugged into. H2’s MAC ca02.0774.0008 shows up on Gi0/0, the uplink, because that is the direction H2’s frames arrive from. The third entry is SW2’s own switch MAC, learned on the uplink from the Layer 2 control traffic (such as spanning tree) the peer switch sends. The switch did not need to be told any of this; it read it off the frames.

The aging timer

Dynamic entries do not live forever. Each entry carries an aging timer, 300 seconds by default, that resets every time a frame arrives from that MAC. If a host goes quiet and no frame is seen from it for the full 300 seconds, the switch removes its entry. The next frame destined for that host will then have to be flooded again until the host speaks and gets relearned. Aging keeps the table current as devices move ports or leave the network.

The default is easy to confirm, and you can lower it per VLAN when hosts move often:

show mac address-table aging-time

SW1 reports the standard global value:

To shorten it, set the value globally or for a single VLAN:

mac address-table aging-time 120 vlan 1

A shorter timer drops idle entries sooner, which suits networks where devices move between ports often. The value can run from 10 seconds upward, and 0 disables aging entirely; the learning and forwarding behavior is otherwise unchanged.

How the switch forwards a known frame

When a frame’s destination MAC is already in the table, the decision is simple: forward it out the one port the table names, and nothing else. If the destination MAC maps to a DIFFERENT port than the one the frame arrived on, the switch forwards it out that port alone. This is unicast forwarding, and it is why a busy switched network does not drown every host in traffic meant for someone else.

There is one case where a known frame is not forwarded at all. If the destination MAC is on the SAME port the frame arrived on, the two devices are on the same segment and have already heard each other directly, so the switch silently drops the frame. This filtering keeps a frame from being echoed back onto the segment it came from.

Flooding: what happens when the destination is unknown

If the destination MAC is not in the table, the switch cannot know which port reaches it, so it floods: the frame goes out every port in the same VLAN except the one it arrived on. This is called unknown unicast flooding, and it is normal switch behavior, not a fault or an attack. The destination eventually replies, the switch learns its source MAC, and the next frame to that host is forwarded to a single port instead of flooded.

Two situations trigger flooding. The first is the unknown unicast above. The second is a broadcast frame, destination ffff.ffff.ffff, or a multicast that the switch has no specific forwarding state for; these are always sent out every port in the VLAN. Flooding is contained by the VLAN: a frame is only ever flooded to ports in its own VLAN, which is why VLANs shrink the flood domain. On a topology with redundant links and no spanning tree, that same flooding loops endlessly into a broadcast storm, which is exactly the problem the switching layer runs Spanning Tree Protocol to prevent.

MAC tables in a multi-switch topology

Each switch keeps its own independent table and learns only from the frames it personally sees. A host on the far side of an uplink is not learned on a port pointing at that host, because no such port exists; it is learned on the uplink, the direction its frames actually come from. This is the detail exam questions test most, and it is obvious once you see the two tables side by side.

Here is the lab the captures come from, two switches in one VLAN with a host on each, annotated with the port each switch learns the hosts on:

In the lab, H1 connects to SW1 on Gi0/1, H2 connects to SW2 on Gi0/2, and the two switches join on Gi0/0. Compare SW1’s table above with SW2’s:

The same two host MACs appear in both tables, but on different ports. H1’s MAC ca01.0758.0008 is on SW1’s Gi0/1 (its direct port) yet on SW2’s Gi0/0 (the uplink). H2’s MAC ca02.0774.0008 is the mirror image: direct on SW2’s Gi0/2, on the uplink at SW1’s Gi0/0. Neither switch has a port that points straight at the remote host, so each learns the remote host on the link toward the other switch. Read an exam exhibit this way and the answer is usually sitting in which port a MAC is associated with.

Clearing and verifying the table

Three commands cover day-to-day work with the table. The first lists the dynamic entries, the second counts them, and the third flushes the dynamic entries so you can watch them get relearned:

show mac address-table dynamic
show mac address-table count
clear mac address-table dynamic

After a clear, the table refills the instant traffic flows again, because learning happens on the very next frame from each source. Static entries are the exception: an address you configure by hand never ages and is not removed by clear mac address-table dynamic, so it survives both the timer and a manual flush. To narrow a busy table while troubleshooting, filter the same command by VLAN, interface, or address, for example show mac address-table dynamic interface Gi0/1 or show mac address-table address ca01.0758.0008.

MAC table command cheat card

Keep these within reach. Every one was run on the lab switches above.

Practice switching concepts

Flip the cards to lock in learning, aging, and the forward-versus-flood decision, then take the quiz, which includes the multi-switch exhibit question that the real test leans on. If a link still acts up after this, the interface troubleshooting guide reads the counters, and the full path is in the CCNA 200-301 study roadmap.