An Ethernet switch is a Layer 2 device, which means it makes every forwarding decision based on MAC addresses, entirely unaware of what protocol is actually carried inside the frame’s payload, whether that’s an IPv4 packet, an IPv6 packet, or something else entirely. This guide covers exactly how a switch builds and uses its MAC address table, what happens to frames it can’t immediately forward, and the different methods Cisco switches use to actually move a frame from one port to another.
Switches vs. Hubs: Why the MAC Address Table Matters
An Ethernet hub simply repeats every incoming bit out every port except the one it arrived on, with no intelligence about where a frame should actually go. A switch works completely differently: it consults a MAC address table, sometimes called a content addressable memory (CAM) table, to make an individual forwarding decision for every single frame it receives. This is the fundamental architectural difference that makes switches dramatically more efficient than hubs, since a switch only sends a frame out the port where its actual destination lives, rather than flooding it everywhere by default.
How a Switch Learns MAC Addresses
A switch builds its MAC address table automatically, without any manual configuration, simply by examining the source MAC address of every frame it receives on any port. This learning process happens continuously:
- New source address: If a frame’s source MAC address isn’t already in the table, the switch adds it, along with the port number the frame arrived on.
- Existing source address, same port: If the source MAC address is already in the table on the same port, the switch simply refreshes that entry’s aging timer. By default, most Ethernet switches age out an unused entry after 5 minutes (300 seconds).
- Existing source address, different port: If a MAC address that’s already in the table suddenly appears on a different port, the switch updates the entry to reflect the new port. This can happen legitimately, when a device physically moves to a different switch port, but a MAC address flapping rapidly between ports can also indicate a network loop or, in some cases, an active spoofing attempt.
How a Switch Forwards Frames
Once a switch has built up entries in its MAC address table, it uses that table to decide what to do with each incoming frame’s destination MAC address. There are three possible outcomes:
- Forward: If the destination MAC address matches an entry in the table, the switch sends the frame out only that specific port, ignoring every other port entirely.
- Flood: If the destination MAC address isn’t in the table yet, sometimes called unknown unicast flooding, the switch sends the frame out every port except the one it arrived on, essentially falling back to hub-like behavior for that one frame until it learns where the destination actually is.
- Filter: If the destination MAC address is on the same port the frame arrived on, meaning the source and destination are already on the same physical segment, the switch simply discards the frame, since forwarding it back out the same port it came in on would serve no purpose.
Broadcast and multicast frames follow a different rule entirely: a switch never looks them up in its MAC address table at all, since a broadcast address (FF:FF:FF:FF:FF:FF) isn’t a specific device’s address to look up. Broadcast frames are always flooded out every port except the incoming one, by design, and multicast frames are flooded as well unless the switch has multicast-aware features like IGMP snooping specifically configured to limit their scope.
Frame Forwarding Methods on Cisco Switches
Beyond deciding where a frame goes, a switch also has to decide how to actually process and move it. Cisco switches support several distinct forwarding methods, each trading off speed against error checking differently.
Store-and-Forward Switching
In store-and-forward mode, the switch copies the entire incoming frame into memory before doing anything else. While the frame is buffered, the switch computes a Cyclic Redundancy Check (CRC) against the frame’s trailer to check for transmission errors. If the CRC check fails, the switch drops the frame immediately; if it passes, the switch forwards the complete frame out the correct port.
This thoroughness comes at a cost: computing the CRC for every single frame takes time and is the most processor-intensive of the forwarding methods, introducing more latency than the alternatives. In exchange, store-and-forward guarantees that no corrupted frame ever gets forwarded further into the network, which matters enough that it’s a requirement for any switch implementing Quality of Service (QoS), since QoS decisions need to examine the full frame’s contents anyway.
Cut-Through Switching
Cut-through switching takes the opposite approach: the switch reads only the destination MAC address, located in the first 6 bytes of the frame following the preamble, looks it up in the MAC address table, and starts forwarding immediately, without waiting for the rest of the frame to arrive or checking for errors at all.
This makes cut-through significantly faster than store-and-forward, but it comes with a real tradeoff: since the switch never checks the frame for errors, it can and does forward corrupted frames. Responsibility for discarding a bad frame falls entirely to the receiving device at the other end. Cut-through is the predominant switching method used on Cisco switches specifically because of this speed advantage, with two notable variants.
Fast-forward switching is the purest, lowest-latency form of cut-through: the switch starts forwarding as soon as it’s read the destination MAC address, without waiting for anything else. Latency is measured from the first bit received to the first bit transmitted, and while this occasionally means a faulty frame gets relayed, the destination device’s own error checking catches and discards it on arrival.
Fragment-free switching is a deliberate compromise between fast-forward’s speed and store-and-forward’s reliability. It waits for the first 64 bytes of the frame, the collision window, to arrive before forwarding, since the overwhelming majority of collisions and transmission errors occur within that first 64 bytes. This specifically prevents forwarding “runt” frames, frames smaller than the valid 64-byte minimum, which are a telltale sign of a collision-damaged transmission. Fragment-free performs a small amount of error checking on just that first 64 bytes, improving on fast-forward’s reliability without taking on store-and-forward’s full latency cost.
Adaptive Switching
Some switches support a configurable, adaptive mode on a per-port basis: the port operates in cut-through mode by default, but automatically switches to store-and-forward once a configured error threshold is reached on that port. Once the error rate drops back below the threshold, the port automatically reverts to cut-through. This gives a network the speed benefit of cut-through switching under normal conditions while automatically prioritizing reliability specifically on ports experiencing real problems.
Comparing the Forwarding Methods
| Method | Error Checking | Relative Latency | Forwards Errored Frames? |
|---|---|---|---|
| Store-and-forward | Full CRC check on entire frame | Highest | No |
| Cut-through (general) | None | Lowest | Yes |
| Fast-forward | None | Lowest of all | Yes |
| Fragment-free | Partial (first 64 bytes only) | Moderate | Rarely (catches runt frames) |
Troubleshooting Switching Issues
A MAC address keeps flapping between two different ports in the table. This often indicates a physical network loop, where the same device or a redundant path is creating a cycle without Spanning Tree Protocol properly blocking it. It can also indicate MAC spoofing in a security-sensitive environment, so it’s worth ruling out both possibilities rather than assuming a benign cause immediately.
Unusually high broadcast traffic across the network. Since switches always flood broadcast frames regardless of MAC table contents, a large flat network without VLAN segmentation can accumulate significant broadcast traffic as it grows. Segmenting the network into smaller broadcast domains with VLANs is the standard fix once this becomes a measurable problem.
Intermittent frame corruption reaching end devices. If a switch is running in cut-through or fast-forward mode, it won’t catch corrupted frames itself; that responsibility falls to the receiving device. If corruption is a recurring, measurable problem, switching the affected ports to store-and-forward, or enabling adaptive switching if supported, trades some latency for the error protection that’s clearly needed.
A Worked Example: A Frame’s First Few Milliseconds on a Switch
It helps to trace exactly what happens when a brand-new device sends its very first frame on a switched network. Say Device A, freshly connected to port 3 of a switch, sends a frame destined for Device B, which the switch has never seen traffic from before.
The switch first examines the frame’s source MAC address, Device A’s, and learns it: an entry is added to the MAC address table associating Device A’s MAC address with port 3. Next, the switch checks the frame’s destination MAC address, Device B’s, against its table. Since Device B has never sent traffic through this switch, there’s no entry for it yet, so the switch floods the frame out every port except port 3.
If Device B is connected to port 7, it receives the flooded frame and, assuming it needs to reply, sends a response back. That response frame arrives at the switch with Device B’s MAC address as the source, on port 7, and the switch learns that mapping too. From this point forward, any frame addressed to Device B gets forwarded directly and only to port 7, rather than flooded, since the switch now has a confirmed table entry for it.
This entire learning process happens automatically and essentially instantaneously, without any administrator configuration required, which is exactly why plugging a new device into a switch just works without manual setup. It’s a good example of how much of a switch’s core behavior is genuinely self-configuring, in sharp contrast to the router configuration typically required elsewhere on the same network.
Frequently Asked Questions
What’s the difference between a switch and a hub?
A hub repeats every incoming bit out every port except the one it arrived on, with no awareness of destinations at all. A switch builds and uses a MAC address table to make an individual forwarding decision for each frame, sending it only out the port where the actual destination device lives, which is dramatically more efficient and also eliminates the shared-collision-domain problem hubs have.
What happens when a switch receives a frame for a MAC address it hasn’t learned yet?
The switch floods the frame out every port except the one it arrived on, a behavior called unknown unicast flooding. Once the actual destination device responds, the switch learns its MAC address and port from that response, and future frames to that address get forwarded directly rather than flooded.
Does a switch look up broadcast frames in its MAC address table?
No, broadcast and multicast frames are never looked up in the MAC address table at all, since they don’t represent a single device’s address. They’re flooded out every port except the incoming one by default, unless multicast-aware features like IGMP snooping are configured to limit multicast flooding specifically.
Which switching method is fastest: store-and-forward or cut-through?
Cut-through, and specifically its fast-forward variant, is the fastest, since the switch starts forwarding a frame as soon as it reads the destination MAC address rather than waiting for the entire frame and checking it for errors. Store-and-forward is slower but guarantees no corrupted frame gets forwarded, since it fully buffers and CRC-checks every frame before sending it on.
Why would a network use fragment-free switching instead of fast-forward?
Fragment-free offers a middle ground, catching the “runt” frames that result from collisions, which occur almost entirely within a frame’s first 64 bytes, without taking on the full latency cost of checking an entire frame’s CRC the way store-and-forward does. It’s a practical compromise for networks that want better reliability than pure fast-forward without sacrificing as much speed as store-and-forward requires.
How long does a switch keep a MAC address table entry before removing it?
Most Ethernet switches use a default aging timer of 5 minutes (300 seconds), removing any entry that hasn’t seen matching traffic within that window. This keeps the table from filling up with stale entries for devices that are no longer actually connected or communicating.
