What is MAC Address Table? How Switches Learn and Forward Data

 A switch out of the box knows nothing about your network. It has no configuration describing which device sits where, and nobody tells it.

Within seconds of being connected, it knows the location of every active device. It learns this by listening to conversations it is not part of — and then forgets everything it learned within about five minutes unless it hears from each device again.

That cycle of learning and forgetting is the MAC address table, and understanding it explains a surprising amount of switch behaviour that otherwise looks arbitrary.

How Learning Works

Every Ethernet frame carries two hardware addresses: where it came from, and where it is going.

When a frame arrives on a port, the switch examines the source address and records a simple association: this address is reachable through this port. That single observation is the entire learning mechanism.

It is worth pausing on the elegance of this. The switch does not ask anything, does not probe, and does not need configuring. It derives a complete map of device locations purely from traffic that was going to pass through it anyway.

Each entry contains the MAC address, the port it was learned on, the VLAN it belongs to, and how it was learned — dynamically, or configured statically by an administrator.

How Forwarding Works

With learning handled, forwarding is a lookup.

When a frame arrives, the switch reads the destination address and consults the table:

• Address found, on a different port. Forward the frame out that one port only. This is the normal case and the reason switches outperform hubs.
• Address found, on the same port it arrived on. Discard the frame. The sender and receiver are both reachable through the same port, so the switch has nothing useful to do — a situation called filtering.
• Address not found. Flood the frame out every port in that VLAN except the one it arrived on.
• Broadcast address. Flood, always. Broadcasts are addressed to everyone by definition.
• Multicast address. Flood, unless the switch is running IGMP snooping and knows which ports have interested listeners.

Unknown Unicast Flooding Deserves Attention

That third case — flooding traffic for an unknown destination — is normal, temporary, and occasionally a symptom of something wrong.

It happens legitimately when a device has been silent long enough for its entry to age out while another device still wants to reach it. The switch floods, the target replies, the switch learns from that reply, and subsequent frames are forwarded normally. The whole episode lasts one frame.

It becomes a problem when it persists. Sustained unknown unicast flooding means the switch keeps failing to learn an address, and the traffic is being delivered to every port on the segment — which is both a performance cost and a security concern, since every device receives traffic intended for one.

Causes worth investigating:

• Asymmetric traffic flow, where a device receives a great deal and sends almost nothing, so the switch rarely hears from it.
• An aging timer shorter than the conversation gap between devices.
• Topology changes repeatedly flushing the table.
• A device using one address to send and another to receive, which occurs in some load-balancing and clustering configurations.

The Aging Timer

Entries do not persist indefinitely. Each carries a timer, refreshed whenever the switch hears from that address again, and removed when it expires. The common default is 300 seconds — five minutes.

The timer exists for good reasons:

• Devices move. A laptop unplugged from one desk and connected at another would otherwise have traffic sent to the wrong port indefinitely.
• Tables are finite. Without expiry they would fill with addresses of devices that left long ago.
• Stale entries cause silent failure, where traffic is confidently forwarded to a port where nothing is listening.

Five minutes is a reasonable compromise. Shorter values cause more flooding as entries expire between conversations. Longer values leave stale entries around after devices move.

One related behaviour worth knowing: when spanning tree detects a topology change, switches flush their tables — either entirely or partially, depending on the implementation — because the topology change may have altered where devices are reachable. This produces a brief burst of flooding afterwards, which is normal and self-correcting. Repeated topology changes producing repeated flushes, however, indicate an unstable link somewhere and are worth chasing down.

Tables Are Per-VLAN

An important detail: the table is maintained separately for each VLAN.

The same MAC address can legitimately appear in two VLANs — a router interface handling several VLANs will be learned in each of them. Flooding is confined to the VLAN in which the frame arrived, which is precisely the isolation VLANs exist to provide.

When reading table output, always check the VLAN column. An address appearing where you did not expect it usually indicates a VLAN misconfiguration rather than anything more exotic.

What a MAC Address Actually Contains

Since the entire mechanism revolves around these addresses, it is worth knowing what they are made of.

A MAC address is 48 bits, usually written as six pairs of hexadecimal digits. It divides into two halves:

• The first 24 bits identify the manufacturer, assigned by the IEEE and known as the organisationally unique identifier.
• The last 24 bits are assigned by that manufacturer to the individual device.

The practical use of the first half: given an unfamiliar address in a table, a manufacturer lookup frequently tells you what the device is. An address registered to a printer manufacturer appearing on a port that should have a workstation is immediately informative.

Two special cases worth recognising in table output:

• All Fs — ff:ff:ff:ff:ff:ff — is the broadcast address, which is why it never appears as a learned entry.
• Locally administered addresses are set in software rather than burned into hardware, and are common on virtual machines and on phones using randomised addressing for privacy.

That last point has a practical consequence. Modern mobile devices generate a different MAC address for each wireless network by default, and rotate it periodically. Any mechanism that depends on a stable address — DHCP reservations, port security, access control lists based on hardware address — will behave unpredictably with those devices unless the feature is disabled for your network.

Reading the Table

The command on most switch platforms:

show mac address-table

Useful variations:

• show mac address-table address 00:1A:2B:3C:4D:5E to locate one specific device.
• show mac address-table interface GigabitEthernet0/5 to list everything learned on one port.
• show mac address-table vlan 10 to filter by VLAN.
• show mac address-table count to see how full the table is.

The practical application that justifies learning this: finding where a device is physically connected.

Suppose you have an IP address from a log and need to locate the machine. Ping it to ensure it is active, then check the ARP table on the router to obtain its MAC address. Then look that address up in the switch's MAC table to find the port. Then read the port description, or follow the cable.

That sequence takes two minutes and replaces an afternoon of walking around with a laptop.

MAC Flapping

If the same address appears repeatedly on different ports, the switch will usually log a message about it. This is called flapping, and it always indicates a genuine problem.

The causes:

• A network loop. The same frames are arriving by two paths, so the switch sees the address from both directions. This is the most common cause and the most urgent.
• Two devices configured with the same MAC address, which happens with cloned virtual machines and occasionally with cheap hardware.
• A device with multiple active interfaces in an unsupported configuration.
• A failed or misconfigured link aggregation, where bonded ports are not correctly grouped.

Flapping messages should never be ignored. A loop that is currently intermittent will eventually become constant, and at that point the segment stops working entirely.

The Overflow Attack and Port Security

The table has a finite size — commonly several thousand entries, depending on the platform.

An attacker can exploit this. By flooding the switch with frames carrying thousands of fabricated source addresses, they fill the table completely. With no room to learn legitimate addresses, the switch floods all traffic out every port — effectively turning itself into a hub and letting the attacker capture traffic intended for others.

The mitigation is port security, which limits how many addresses a port may learn:

• Set a maximum number of addresses per port, often one or two for desk connections.
• Define the action on violation: shut the port down, restrict traffic, or simply log.
• Optionally use sticky learning, where the first address learned is retained as if configured statically.

Configured sensibly, this also solves an everyday administrative problem: it prevents people connecting unauthorised switches and consumer routers to wall sockets.

Configured carelessly, it generates support calls every time someone legitimately swaps a computer. Choose the violation action deliberately, and prefer restricting over shutting down in areas where devices change frequently.

Checking Table Capacity

Worth monitoring in larger environments. show mac address-table count reports current usage against capacity.

A table approaching its limit causes constant flooding as entries are evicted to make room, which degrades performance across the whole segment and is difficult to diagnose without knowing to look.

If you find a table full in an ordinary office network, something is wrong — either a loop generating fabricated addresses, or an attack. A legitimate office does not produce thousands of MAC addresses.

The Summary Worth Keeping

The MAC address table is one of the simplest mechanisms in networking and one of the most useful diagnostically. A switch learns from source addresses, forwards based on destination addresses, floods when it does not know, and forgets after five minutes.

Everything else — flooding storms, port security, loop symptoms, locating a device physically — follows from those four behaviours. It is worth knowing properly, because the command that displays it answers more questions in daily work than almost anything else available on a switch.