Table of Contents

MAC Address Table Explained: How Switches Learn MAC Addresses, Forward Frames, Flood Traffic and Age Entries

Ethernet switches can forward millions of frames without knowing IP addresses, DNS names, URLs, or applications. Their fundamental forwarding decision is much simpler:

Which switch port leads to this destination MAC address?

To answer that question efficiently, a switch maintains a MAC address table, often called a MAC table, forwarding database (FDB), or—on some platforms—a CAM table.

The basic relationship looks like this:

MAC Address                  Switch Port
AA:AA:AA:AA:AA:AA     →     Gi1/0/1
BB:BB:BB:BB:BB:BB     →     Gi1/0/8
CC:CC:CC:CC:CC:CC     →     Gi1/0/12

This table allows a switch to forward known unicast traffic only toward the port where the destination is believed to exist instead of sending every Ethernet frame everywhere.

But the mechanism becomes much more interesting when the switch does not know the destination MAC.

That is where concepts such as MAC learning, unknown unicast flooding, broadcast flooding, filtering, MAC aging, MAC moves, MAC flapping, VLAN-aware forwarding, and Layer 2 loops become essential.

This guide explains the complete process from the arrival of an Ethernet frame to the switch’s final forwarding decision.

For the surrounding concepts, start with Computer Networking Explained, Routers, Switches and Network Devices, and ARP Explained.

What Is a MAC Address Table?

A MAC address table is a Layer 2 forwarding database maintained by an Ethernet bridge or switch.

It associates learned MAC addresses with the interfaces through which those addresses can be reached.

For example:

VLAN	MAC Address	Port
10	AA:AA:AA:AA:AA	Gi1/0/1
10	BB:BB:BB:BB:BB	Gi1/0/8
20	CC:CC:CC:CC:CC	Gi1/0/12

When a frame arrives with:

Destination MAC:
BB:BB:BB:BB:BB:BB

the switch can search its forwarding database and determine:

BB:BB:BB:BB:BB:BB
        |
        v
     Gi1/0/8

It can then forward the frame toward that interface.

The table transforms Ethernet switching from indiscriminate forwarding into selective forwarding.

Why Ethernet Switches Need MAC Tables

Imagine an Ethernet switch with four connected computers:

               Switch
          +------+------+------+
          |      |      |      |
         PC-A   PC-B   PC-C   PC-D

Suppose PC-A sends a frame to PC-D.

Without learned forwarding information, the switch may need to send that frame through multiple eligible ports because it does not know where PC-D resides.

With a populated MAC table:

PC-A MAC → Port 1
PC-B MAC → Port 2
PC-C MAC → Port 3
PC-D MAC → Port 4

the decision becomes:

Destination = PC-D MAC
        |
        v
MAC table lookup
        |
        v
Port 4

Only the appropriate destination port needs the known-unicast frame.

This is a central advantage of Ethernet switching.

How Does a Switch Learn MAC Addresses?

One of the most important facts about Ethernet switching is:

A switch normally learns from the source MAC address of received frames.

Consider this frame:

Source MAC:
AA:AA:AA:AA:AA:AA

Destination MAC:
BB:BB:BB:BB:BB:BB

It arrives on:

Gi1/0/1

The switch can learn:

AA:AA:AA:AA:AA:AA
        |
        v
     Gi1/0/1

Notice what happened.

The switch learned the location of the source, not the destination.

The destination MAC is used primarily to decide where the frame should be forwarded.

This distinction is fundamental.

Source Learning Step by Step

Suppose PC-A connects to port 1:

PC-A
MAC: AA:AA:AA:AA:AA:AA
        |
        v
      Port 1
        |
      Switch

Initially, the switch has no dynamic entry for PC-A.

PC-A sends a frame.

The switch sees:

Incoming port:
Port 1

Source MAC:
AA:AA:AA:AA:AA:AA

It learns:

AA:AA:AA:AA:AA:AA → Port 1

The table now contains:

MAC Address	Port
AA:AA:AA:AA:AA	Port 1

If PC-B later sends a frame through port 2:

BB:BB:BB:BB:BB:BB → Port 2

the table becomes:

MAC Address	Port
AA:AA:AA:AA:AA	Port 1
BB:BB:BB:BB:BB	Port 2

The switch builds its forwarding knowledge dynamically from traffic.

The Complete Ethernet Switching Process

A simplified Layer 2 forwarding process can be represented as:

Frame arrives
     |
     v
Learn source MAC
     |
     v
Look up destination MAC
     |
     +--------------------------+
     |                          |
Destination known?         Destination unknown?
     |                          |
    YES                         NO
     |                          |
     v                          v
Forward toward             Flood through
known port                 eligible ports

There are important exceptions and additional rules, but this model explains much of ordinary Ethernet switching.

Let’s examine each part.

Known Unicast Forwarding

Suppose the MAC table contains:

AA:AA:AA:AA:AA:AA → Port 1
BB:BB:BB:BB:BB:BB → Port 2

PC-A sends:

Source:
AA:AA:AA:AA:AA:AA

Destination:
BB:BB:BB:BB:BB:BB

The frame arrives through Port 1.

The switch first confirms or updates:

AA:AA:AA:AA:AA:AA → Port 1

It then searches for:

BB:BB:BB:BB:BB:BB

and finds:

Port 2

The forwarding decision becomes:

Port 1
  |
  | incoming frame
  v
Switch
  |
  | MAC table says destination = Port 2
  v
Port 2

The switch does not need to flood that known unicast frame through every other port.

What Is Unknown Unicast Flooding?

Now suppose PC-A wants to send a frame to PC-D, but the switch has never learned PC-D’s MAC address.

The table contains:

AA:AA:AA:AA:AA:AA → Port 1
BB:BB:BB:BB:BB:BB → Port 2

but not:

DD:DD:DD:DD:DD:DD

The frame arrives:

Source:
AA:AA:AA:AA:AA:AA

Destination:
DD:DD:DD:DD:DD:DD

The switch asks:

Where is DD:DD:DD:DD:DD:DD?

The forwarding database has no answer.

For ordinary unknown unicast forwarding, the switch typically floods the frame through eligible ports in the relevant VLAN except the incoming port.

Conceptually:

              Switch
          /      |      \
         /       |       \
      Port 2   Port 3   Port 4
        |        |        |
        v        v        v
       PC-B     PC-C     PC-D

PC-D accepts the frame because it matches its MAC address.

Other hosts normally discard it at the Ethernet layer because the destination MAC is not theirs.

This process is called:

Unknown Unicast Flooding

How the Switch Learns the Unknown Destination

The interesting part occurs when PC-D replies.

PC-D sends:

Source:
DD:DD:DD:DD:DD:DD

Destination:
AA:AA:AA:AA:AA:AA

Suppose that reply arrives on Port 4.

The switch learns:

DD:DD:DD:DD:DD:DD → Port 4

Now the table becomes:

AA:AA:AA:AA:AA:AA → Port 1
BB:BB:BB:BB:BB:BB → Port 2
DD:DD:DD:DD:DD:DD → Port 4

Future frames to PC-D can be selectively forwarded to Port 4.

So the sequence is:

Unknown destination
        |
        v
Flood
        |
        v
Destination replies
        |
        v
Learn source MAC of reply
        |
        v
Future destination known
        |
        v
Selective forwarding

This self-learning behavior is fundamental to transparent Ethernet bridging.

Unknown Unicast Is Not Broadcast

Unknown unicast flooding is often confused with broadcast traffic.

They are different.

Broadcast frame

A broadcast frame has a destination such as:

FF:FF:FF:FF:FF:FF

The frame is intentionally addressed to all hosts in the broadcast domain.

Unknown unicast frame

An unknown unicast frame contains a specific unicast destination MAC:

DD:DD:DD:DD:DD:DD

but the switch does not currently know where that MAC resides.

The switch floods the frame because of missing forwarding information—not because the destination is a broadcast address.

Traffic	Destination	Why Flooded?
Broadcast	FF:FF:FF:FF:FF	Designed for broadcast delivery
Unknown unicast	Specific unicast MAC	Destination location is unknown

This distinction matters greatly when analyzing packet captures and switch behavior.

Broadcast Forwarding

Ethernet broadcasts are deliberately sent throughout the relevant broadcast domain.

A common example is an IPv4 ARP request:

Who has 192.168.1.20?

As explained in ARP Explained, the initial request is typically encapsulated with:

Destination MAC:
FF:FF:FF:FF:FF:FF

The switch therefore floods it through eligible ports in the VLAN.

Conceptually:

                 Switch
              /    |    \
             /     |     \
           PC-B   PC-C   PC-D

ARP broadcast
      |
      +----> PC-B
      +----> PC-C
      +----> PC-D

The switch still learns from the source MAC of the broadcast frame.

Broadcast destination addressing does not prevent source learning.

What About Multicast?

Ethernet multicast introduces another forwarding category.

A simplistic switch without relevant multicast-control information may flood certain multicast traffic similarly to broadcast within the VLAN.

Managed networks can use mechanisms such as IGMP Snooping for IPv4 multicast to make multicast forwarding more selective.

The important point for this article is that Ethernet switches distinguish between several traffic categories:

Known unicast
Unknown unicast
Broadcast
Multicast

Their forwarding behavior is not identical.

What Does Filtering Mean in Ethernet Switching?

Suppose a frame arrives through Port 1 and the switch’s MAC table says the destination MAC is also reachable through Port 1.

Conceptually:

Source
   |
 Port 1
   |
Switch
   |
Destination MAC lookup
   |
   v
Port 1

The switch does not need to send the frame back out the same port.

It can filter the frame from other switch ports.

This commonly occurs when multiple devices exist behind another bridge, switch, hub, virtualization layer, or similar shared downstream segment.

The forwarding database tells the switch that both communicating devices are reachable through the same interface, so forwarding the frame elsewhere would serve no purpose.

MAC Address Learning Is VLAN-Aware

Modern managed switches do not treat every port as belonging to one universal Ethernet domain.

VLANs create separate Layer 2 broadcast domains.

Suppose the switch learns:

VLAN 10
AA:AA:AA:AA:AA:AA → Port 1

The VLAN context matters.

A MAC address table can therefore conceptually contain:

VLAN	MAC Address	Port
10	AA:AA:AA:AA:AA	Gi1/0/1
10	BB:BB:BB:BB:BB	Gi1/0/2
20	CC:CC:CC:CC:CC	Gi1/0/5

The forwarding lookup is not simply:

MAC → Port

but more accurately in VLAN-aware switching:

VLAN + MAC → Port

This explains why traffic in VLAN 10 is not ordinarily forwarded into VLAN 20 merely because a destination MAC appears elsewhere.

MAC Learning Across a Trunk

Consider two switches:

PC-A
  |
Switch 1
  |
  | 802.1Q trunk
  |
Switch 2
  |
PC-B

Suppose PC-A belongs to VLAN 10.

When Switch 2 receives a VLAN 10 frame from PC-A across the trunk, it can learn:

VLAN 10
PC-A MAC
   ↓
Trunk toward Switch 1

Switch 2 does not need to know which exact access port on Switch 1 contains PC-A.

It only needs to know:

To reach this MAC, send the frame through the trunk toward Switch 1.

This hierarchical forwarding behavior allows Ethernet networks to scale across multiple interconnected switches.

MAC Address Aging Explained

Dynamic MAC entries are not normally kept forever.

Imagine a laptop disconnects from:

Port 5

and reconnects somewhere else.

If the old mapping remained permanently:

Laptop MAC → Port 5

the switch could continue sending traffic toward an obsolete location.

Dynamic MAC entries therefore have an aging mechanism.

Conceptually:

MAC learned
    |
    v
Timer/state maintained
    |
    v
Traffic refreshes learning
    |
    +---- YES → Entry remains useful
    |
    +---- NO for aging period
                |
                v
           Entry removed

The exact aging timer is platform-dependent and can often be configured.

Avoid treating one vendor’s default as a universal Ethernet rule.

What Happens After a MAC Entry Ages Out?

Suppose:

DD:DD:DD:DD:DD:DD → Port 4

expires.

Later a frame arrives for:

DD:DD:DD:DD:DD:DD

The switch no longer has a dynamic entry.

The destination becomes an unknown unicast again.

The switch may flood that frame within the appropriate VLAN.

When PC-D transmits again, the switch relearns its location.

Thus:

Learn
  ↓
Forward
  ↓
Age
  ↓
Forget
  ↓
Flood if needed
  ↓
Relearn

is normal switching behavior.

What Is a MAC Address Move?

A MAC address move occurs when the switch learns a MAC address through a different port than before.

Initially:

AA:AA:AA:AA:AA:AA → Port 1

Later, a frame arrives with the same source MAC through:

Port 5

The switch may update the forwarding information:

AA:AA:AA:AA:AA:AA → Port 5

A legitimate move can occur because of:

a laptop being physically moved;
a VM migrating between hosts;
a redundant path changing;
an HA service moving;
topology reconvergence;
a wireless client roaming through infrastructure that changes its apparent Layer 2 location.

A MAC move is therefore not automatically a fault.

Repeated rapid movement, however, deserves investigation.

What Is MAC Flapping?

MAC flapping generally describes a MAC address being learned repeatedly on different switch ports within a short period.

Example:

10:00:01
AA:AA:AA:AA:AA:AA → Gi1/0/1

10:00:02
AA:AA:AA:AA:AA:AA → Gi1/0/24

10:00:03
AA:AA:AA:AA:AA:AA → Gi1/0/1

10:00:04
AA:AA:AA:AA:AA:AA → Gi1/0/24

The switch cannot establish a stable location for the address.

Potential causes include:

Layer 2 loops;
incorrect link aggregation;
virtualization problems;
duplicated MAC addresses;
badly designed redundant links;
misconfigured bridging;
topology instability.

MAC flapping is an important diagnostic signal because it often points to a problem deeper than the forwarding table itself.

Why Layer 2 Loops Are Dangerous

Ethernet frames do not have an IP-style TTL field that decrements at every Layer 2 switch hop.

A physical or logical Layer 2 loop can therefore allow frames to circulate repeatedly.

Consider:

        Switch A
        /      \
       /        \
Switch B ------ Switch C

If redundant links are forwarding without a loop-prevention mechanism, broadcast and unknown-unicast frames can be replicated around the topology.

Potential consequences include:

Broadcast storms
MAC table instability
MAC flapping
High link utilization
High switch CPU usage
Severe packet loss
Network outage

This is one reason loop-prevention technologies such as the Spanning Tree Protocol family are so important in traditional switched Ethernet designs.

How a Loop Causes MAC Table Instability

Suppose a frame from PC-A legitimately enters Switch 1 through Port 1.

The switch learns:

PC-A MAC → Port 1

Because of a Layer 2 loop, a copy of the same frame may return through Port 24.

The switch now observes:

PC-A MAC → Port 24

Another copy may return through Port 1.

The table changes again.

Conceptually:

Port 1
   |
   | PC-A source MAC
   v
Switch
   |
   | frame loops through network
   v
Port 24
   |
   | same source MAC appears
   v
Switch

The result can be continuous MAC movement.

Therefore, MAC flapping alerts should never be treated merely as cosmetic logging.

MAC Address Table vs ARP Table

This is one of the most important distinctions in networking.

ARP/Neighbor Table

Maps:

IPv4 address
      ↓
MAC address

Example:

192.168.1.20
→ BB:BB:BB:BB:BB:BB

Switch MAC Address Table

Maps:

MAC address
      ↓
Switch port

Example:

BB:BB:BB:BB:BB:BB
→ Gi1/0/8

Together:

192.168.1.20
      |
      | ARP
      v
BB:BB:BB:BB:BB:BB
      |
      | MAC table
      v
Gi1/0/8

That chain is a powerful troubleshooting model.

Table	Mapping	Main Purpose
ARP/neighbor table	IPv4 → MAC	Find local next-hop link-layer address
MAC/FDB table	MAC → Switch port	Forward Ethernet frames
Routing table	IP prefix → next hop/interface	Route IP packets

For the first mapping in detail, read ARP Explained.

MAC Address Table vs Routing Table

A routing table answers questions such as:

Where should traffic for 10.20.0.0/16 go?

A MAC table answers:

Through which Layer 2 interface can I reach
AA:AA:AA:AA:AA:AA?

A router may decide:

Destination network:
10.20.0.0/16

Next hop:
192.168.1.1

The device may then need ARP to determine the next hop’s MAC address.

The Ethernet switch then uses its MAC table to deliver the resulting frame.

The complete process can therefore involve:

Routing Table
      |
      v
Next-hop IP
      |
      | ARP
      v
Next-hop MAC
      |
      | Switch FDB
      v
Physical/logical port

This is why understanding only one table is insufficient for serious network troubleshooting.

End-to-End Example: PC-A Sends Traffic to PC-B

Suppose:

PC-A
IP:  192.168.1.10
MAC: AA:AA:AA:AA:AA:AA
Port: Gi1/0/1

PC-B
IP:  192.168.1.20
MAC: BB:BB:BB:BB:BB:BB
Port: Gi1/0/8

Both hosts are in the same subnet and VLAN.

PC-A needs to communicate with PC-B.

Step 1 — PC-A Resolves PC-B

PC-A broadcasts an ARP request.

The switch receives the frame on Gi1/0/1 and learns:

AA:AA:AA:AA:AA:AA → Gi1/0/1

Because the frame is broadcast, it floods the request within the appropriate VLAN.

Step 2 — PC-B Replies

PC-B responds.

The reply arrives through Gi1/0/8.

The switch learns:

BB:BB:BB:BB:BB:BB → Gi1/0/8

Step 3 — Future Traffic Is Selective

The table now contains:

AA:AA:AA:AA:AA:AA → Gi1/0/1
BB:BB:BB:BB:BB:BB → Gi1/0/8

Subsequent known-unicast frames between the hosts can be forwarded directly between those ports.

This shows how ARP and MAC learning complement each other without being the same process.

End-to-End Example: Traffic to the Internet

Now PC-A wants to reach a remote server.

Configuration:

PC-A:
192.168.1.10

Gateway:
192.168.1.1

Remote server:
203.0.113.50

Because the server is remote, PC-A does not normally resolve the remote server’s MAC.

Instead:

203.0.113.50
      |
      | Routing decision
      v
Default gateway
192.168.1.1
      |
      | ARP
      v
Gateway MAC
00:11:22:33:44:55

The switch then performs:

00:11:22:33:44:55
      |
      | MAC table
      v
Port toward gateway

The IP destination remains the remote server, while the Ethernet destination on the local LAN is the gateway.

This distinction is covered in greater detail in TCP/IP Explained.

Does a Switch Need an IP Address to Forward Ethernet Frames?

A basic Layer 2 switch does not need an IP address merely to learn MAC addresses and forward ordinary Ethernet frames.

The switch’s management IP is used for functions such as:

SSH
HTTPS management
SNMP
Telemetry
Monitoring
Configuration

but Layer 2 forwarding is based primarily on Ethernet information.

This distinction is useful when troubleshooting a switch whose management interface is unreachable while user traffic continues flowing.

The management plane and data-plane forwarding functions are related operationally but not identical.

What Is a CAM Table?

The term CAM table is frequently used as a synonym for a switch’s MAC address table, especially in vendor training and operational discussions.

CAM stands for:

Content Addressable Memory

Traditional switching hardware can use specialized lookup mechanisms to find forwarding entries quickly.

However, from a network administrator’s perspective, these terms are often encountered as:

MAC address table
MAC table
CAM table
Forwarding database
FDB

The exact hardware implementation differs across platforms.

For troubleshooting and architecture discussions, MAC address table or forwarding database is usually the clearest vendor-neutral terminology.

Dynamic vs Static MAC Entries

Most endpoint MAC addresses are learned dynamically.

Example:

VLAN 10
AA:AA:AA:AA:AA:AA
Gi1/0/1
Dynamic

Some platforms also support static MAC entries.

A static mapping conceptually says:

This MAC belongs on this port/VLAN
until configuration changes it.

Static entries can be useful for specialized requirements but create operational responsibility.

If a device moves and the static configuration does not, forwarding can break.

Dynamic learning is therefore the normal behavior for most user endpoints.

MAC Table Capacity

A switch cannot necessarily store an unlimited number of forwarding entries.

Hardware has finite resources.

Depending on the platform, a switch may support thousands, tens of thousands, hundreds of thousands, or more entries.

Capacity matters especially in:

data centers;
large Layer 2 domains;
service-provider networks;
virtualization environments;
environments with many containers or virtual machines.

When the forwarding database cannot retain needed entries, unknown-unicast flooding may increase and network behavior can degrade.

Always consult the specific switch vendor’s capacity documentation rather than assuming every platform has the same limit.

MAC Flooding as a Security Concept

Do not confuse:

unknown-unicast flooding

with:

MAC table flooding attacks.

Unknown-unicast flooding is normal switch behavior when the destination location is unknown.

A MAC-table flooding attack attempts to overwhelm forwarding resources with many fabricated source addresses, potentially causing undesirable behavior depending on the switch and its protections.

Modern managed switches can provide controls such as:

port security;
MAC-address limits;
sticky MAC mechanisms;
authentication and NAC;
storm control;
vendor-specific forwarding protections.

For broader network defense concepts, see Network Security Basics and Network Access Control (NAC).

Port Security and MAC Learning

Port security can restrict which or how many MAC addresses may appear on a switch port.

For example, an access port intended for a single workstation might be configured according to policy to allow only a limited number of learned addresses.

Conceptually:

Port Gi1/0/10
       |
       v
Allowed MAC count
       |
   +---+---+
   |       |
Valid   Violation

Possible violation behavior is platform-dependent.

Port-security controls can help protect edge ports, but they must be designed carefully for environments involving:

IP phones with attached PCs;
virtualization;
downstream switches;
wireless access points;
hypervisors;
docking stations.

A port legitimately carrying multiple devices should not be treated like a single-host desktop port.

MAC Address Tables and Virtualization

Virtualization makes MAC-table analysis especially important.

Consider:

          Physical Switch
                 |
                 |
             Hypervisor
            /    |     \
           /     |      \
         VM-A   VM-B    VM-C

The physical switch may learn several VM MAC addresses through the same physical interface:

VM-A MAC → Gi1/0/20
VM-B MAC → Gi1/0/20
VM-C MAC → Gi1/0/20

This is completely normal.

The physical switch only needs to know that those MAC addresses are reachable through the hypervisor.

A virtual switch inside the hypervisor performs the next Layer 2 forwarding decision.

Thus, one physical switch port can legitimately have many MAC addresses.

MAC Tables in Multi-Switch Networks

Suppose:

PC-A
 |
Switch A
 |
Switch B
 |
Switch C
 |
Server

Switch C does not need a complete physical map showing exactly where PC-A connects.

It may simply learn:

PC-A MAC
   ↓
Port toward Switch B

Switch B may learn:

PC-A MAC
   ↓
Port toward Switch A

Switch A knows the final access port.

Each switch makes a local forwarding decision.

This distributed behavior is what allows Ethernet switching to work without every switch holding a global topology map for every endpoint.

Troubleshooting a Missing MAC Address

Suppose you expect:

AA:AA:AA:AA:AA:AA

on:

Gi1/0/10

but the switch has no entry.

Do not immediately assume the switch is defective.

Remember:

A switch normally learns from source traffic.

If the endpoint has not transmitted recently, its dynamic entry may have aged out.

Generate legitimate traffic from the endpoint, then check again.

If the entry still does not appear, investigate:

Physical link
Port state
VLAN
NIC
Cabling
Authentication
Port security
STP state

Troubleshooting a MAC on the Wrong Port

Suppose you expect:

AA:AA:AA:AA:AA:AA → Gi1/0/10

but see:

AA:AA:AA:AA:AA:AA → Gi1/0/24

First determine what Gi1/0/24 represents.

It may be:

An uplink
A trunk
Another switch
A hypervisor
An access point
A legitimate new location

The MAC appearing on an uplink is not necessarily wrong.

Trace it hop by hop.

Example:

Switch A:
MAC → Gi1/0/24
       |
       v
Switch B

Switch B:
MAC → Gi1/0/7
       |
       v
Endpoint

This is one of the most useful Layer 2 troubleshooting techniques.

How to Trace a MAC Address Through a Network

The general workflow is:

Known MAC
   |
   v
Check current switch FDB
   |
   v
Which port?
   |
   +---- Access port → likely endpoint
   |
   +---- Trunk/uplink
             |
             v
       Go to next switch
             |
             v
       Search same MAC
             |
             v
       Repeat until edge

This can help locate:

unknown devices;
servers;
printers;
IP phones;
wireless infrastructure;
incorrectly connected switches;
devices causing duplicate addressing.

If you start only with an IPv4 address, first use ARP to determine the MAC, then trace that MAC through the switching topology.

That produces the powerful sequence:

IP address
    |
    | ARP
    v
MAC address
    |
    | FDB lookup
    v
Switch port
    |
    v
Physical/logical device

Cisco MAC Address Table Commands

On many Cisco IOS/IOS XE platforms, a common command is:

show mac address-table

You can search for a specific MAC address using platform-appropriate syntax such as:

show mac address-table address aaaa.aaaa.aaaa

or inspect a VLAN:

show mac address-table vlan 10

Typical output conceptually contains:

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
10      aaaa.aaaa.aaaa    DYNAMIC     Gi1/0/1
10      bbbb.bbbb.bbbb    DYNAMIC     Gi1/0/8

Exact commands and output vary by platform and software release, so use the vendor documentation for production devices.

Cisco’s switching documentation provides additional detail about MAC address table configuration and management.

Linux Bridge FDB Commands

Linux bridges also maintain forwarding databases.

A useful command is:

bridge fdb show

The bridge utility is part of the Linux iproute2 networking suite.

Example conceptual output:

aa:aa:aa:aa:aa:aa dev eth1 master br0
bb:bb:bb:bb:bb:bb dev eth2 master br0

The Linux bridge behaves as a software Layer 2 bridge, so many concepts from physical switching remain applicable:

Learning
Forwarding
Flooding
FDB aging
VLAN awareness

This becomes important in virtualization, containers, Linux networking labs, and software-defined infrastructure.

Practical Troubleshooting Workflow

When Layer 2 connectivity fails, use a structured process.

1. Verify physical/interface state

Confirm the endpoint and switch port are operational.

Check:

Link up?
Correct speed?
Unexpected errors?
Port administratively enabled?

2. Verify VLAN membership

Confirm the source and expected destination are in the intended VLAN.

3. Identify the destination MAC

For IPv4 local communication, inspect ARP/neighbor information.

Linux:

ip neigh

Windows:

arp -a

4. Search the switch MAC table

Find where that MAC is learned.

5. Follow trunks if necessary

If the MAC points to an uplink, move to the next switch and repeat.

6. Check for MAC flapping

Determine whether the address constantly changes ports.

7. Check spanning-tree state

Ensure the topology is not experiencing a loop or unexpected STP transition.

8. Capture traffic

If the forwarding information looks correct but connectivity still fails, capture packets and inspect what actually crosses the interfaces.

Troubleshooting Decision Tree

Endpoint unreachable
        |
        v
Physical link up?
     /       \
   NO         YES
   |           |
   v           v
Fix Layer 1  Correct VLAN?
             /       \
           NO         YES
           |           |
           v           v
        Fix VLAN    ARP resolves?
                     /       \
                   NO         YES
                   |           |
                   v           v
              Check L2/ARP   Get MAC
                               |
                               v
                       Search MAC table
                               |
                     +---------+---------+
                     |                   |
                 Not learned           Learned
                     |                   |
                     v                   v
               Generate source     Correct port?
               traffic/check L2       /    \
                                    NO      YES
                                    |        |
                                    v        v
                              Trace/inspect Check higher
                              MAC movement   layers

This prevents a common troubleshooting mistake: jumping immediately to DNS, applications, or firewalls before verifying Layer 2 delivery.

Common Problem: MAC Entry Keeps Moving

Symptoms:

MAC learned on Port 1
MAC learned on Port 24
MAC learned on Port 1
MAC learned on Port 24

Investigate:

Layer 2 loops;
duplicated MAC addresses;
bad link aggregation;
virtualization;
HA architecture;
topology changes.

If many unrelated MAC addresses flap between the same ports, a Layer 2 loop or topology issue becomes especially suspicious.

Common Problem: Excessive Unknown Unicast Flooding

Possible causes include:

FDB entries aging too quickly
One-way traffic patterns
MAC-table resource pressure
Topology instability
MAC learning disabled/restricted
Unusual overlay/virtualization behavior

Do not assume unknown-unicast traffic automatically means an attack.

First determine why the destination is not present in the forwarding database.

Common Problem: Host Can Reach Gateway but Not Another Local Host

If both devices should be in the same VLAN, investigate:

VLAN assignment
Private VLAN / isolation
Port security
Endpoint firewall
ARP resolution
MAC learning
Wireless client isolation

A working default gateway does not prove every Layer 2 peer is reachable.

Common Problem: ARP Entry Exists but Traffic Still Fails

Suppose the host knows:

192.168.1.20
→ BB:BB:BB:BB:BB:BB

That confirms a neighbor mapping exists.

It does not guarantee that the switch currently has the correct forwarding location.

Check:

BB:BB:BB:BB:BB:BB
→ Which switch port?

Then trace the forwarding path.

This is precisely why ARP and MAC tables must be investigated together.

Common Problem: MAC Address Appears on a Trunk

This is often completely normal.

If the endpoint is connected to another switch, the local switch should learn the MAC through the trunk or uplink leading toward that switch.

Do not assume:

MAC on trunk = configuration error

Instead ask:

Does this trunk lead toward the device’s actual location?

Topology context determines whether the entry is correct.

Common Problem: MAC Table Is Empty After a Reboot

Dynamic forwarding information is learned from traffic.

After a switch reboot, dynamic entries may need to be learned again.

Initially:

MAC table mostly empty

As endpoints transmit:

Source MACs observed
       |
       v
FDB populated

A newly booted switch therefore does not need a preconfigured dynamic MAC table before ordinary learning can begin.

Switching, Routing and ARP: The Complete Model

Consider communication with a remote server.

The host starts with:

Destination IP

Its routing logic determines:

Next-hop IP

ARP determines:

Next-hop MAC

The switch determines:

Output Layer 2 port

Conceptually:

Application
    |
    v
Destination IP
    |
    v
Routing table
    |
    v
Next-hop IP
    |
    v
ARP / Neighbor table
    |
    v
Next-hop MAC
    |
    v
Switch MAC table
    |
    v
Output port
    |
    v
Ethernet frame transmitted

This is one of the most useful mental models for troubleshooting traditional IPv4 Ethernet networks.

For the routing layer, see TCP/IP Explained.

Best Practices for Stable MAC Learning

Good Layer 2 design reduces forwarding instability.

Useful practices include:

keep VLAN boundaries intentional;
prevent accidental Layer 2 loops;
configure STP appropriately;
document trunks and link aggregation;
monitor MAC flapping;
investigate unexpected MAC moves;
use port security where appropriate;
avoid unnecessarily huge Layer 2 domains;
monitor forwarding-table resource utilization on large networks;
verify virtualization and HA designs;
distinguish normal unknown-unicast flooding from abnormal flooding;
correlate ARP, MAC tables, and topology during troubleshooting.

Most importantly:

A MAC table tells you where a switch currently believes an Ethernet address is reachable.

Treat that information as evidence about the Layer 2 topology.

Frequently Asked Questions

What is a MAC address table?

A MAC address table is a forwarding database used by an Ethernet switch or bridge to associate MAC addresses with Layer 2 interfaces.

What is another name for a MAC address table?

Common terms include MAC table, forwarding database (FDB), forwarding table, and CAM table, although implementation terminology can vary.

How does a switch learn MAC addresses?

A switch normally learns a MAC address from the source MAC address of a frame arriving on an interface.

Does a switch learn from the destination MAC?

The destination MAC is primarily used for the forwarding lookup. Dynamic source learning normally uses the source address of received frames.

What happens when a switch knows the destination MAC?

For an ordinary known unicast frame, the switch can forward the frame toward the interface associated with that destination.

What happens when a switch does not know the destination MAC?

The destination is treated as unknown unicast, and the frame is typically flooded through eligible ports in the relevant VLAN except the ingress port.

What is unknown unicast flooding?

It is the process of flooding a frame with a specific unicast destination because the switch does not currently know where that destination MAC is located.

Is unknown unicast the same as broadcast?

No. A broadcast intentionally uses a broadcast destination address. Unknown unicast has a specific destination MAC whose location is absent from the forwarding database.

What is MAC address aging?

Dynamic forwarding entries are removed after a platform-defined period of inactivity or according to the device’s forwarding logic, allowing obsolete mappings to disappear.

What happens when a MAC entry expires?

If traffic later arrives for that destination before it is relearned, the switch may treat the frame as unknown unicast and flood it within the appropriate VLAN.

What is MAC flapping?

MAC flapping occurs when the same MAC address is repeatedly learned through different ports, often indicating topology instability, loops, misconfiguration, virtualization behavior, or duplicate MAC addresses.

What is the difference between a MAC table and an ARP table?

An ARP table associates IPv4 addresses with link-layer addresses. A switch MAC table associates MAC addresses with Layer 2 interfaces.

What is the difference between a MAC table and a routing table?

A MAC table supports Layer 2 Ethernet forwarding. A routing table supports Layer 3 IP forwarding.

Can the same MAC appear in different VLANs?

Forwarding databases are VLAN-aware on VLAN-capable switches, and MAC learning is interpreted in the appropriate Layer 2 forwarding context.

Can multiple MAC addresses exist on one switch port?

Yes. This is normal for trunks, downstream switches, wireless access infrastructure, hypervisors, IP phones with attached devices, and other multi-device environments.

Does a Layer 2 switch need an IP address?

Not for basic Ethernet frame forwarding. An IP address is typically needed for IP-based management and other Layer 3 functions.

Why is a MAC address learned on an uplink?

The endpoint may reside behind another switch or Layer 2 device. The local switch only needs to know which next Layer 2 interface leads toward the destination.

What is a CAM table?

CAM table is a term frequently used for the hardware forwarding table that stores MAC forwarding information on certain switching platforms.

What is an FDB?

FDB stands for Forwarding Database. It is a common vendor-neutral term for Layer 2 forwarding information.

Can a Layer 2 loop cause MAC flapping?

Yes. Frames circulating through a loop can cause the same source MAC to appear repeatedly on different interfaces.

How can I find which switch port a device uses?

Determine its MAC address, search the switch’s forwarding database, and follow uplink/trunk ports across switches until you reach the access port or final Layer 2 location.

Conclusion

The MAC address table is at the heart of Ethernet switching.

Its basic function can be summarized as:

Source MAC
    |
    | Learn
    v
MAC Address Table
    |
    | Destination lookup
    v
Forwarding decision

When the destination is known:

Destination MAC
      |
      v
MAC table match
      |
      v
Known output port
      |
      v
Forward

When it is unknown:

Destination MAC
      |
      v
No FDB entry
      |
      v
Unknown unicast
      |
      v
Flood within relevant VLAN

As traffic continues, the switch learns the network dynamically:

Receive
   ↓
Learn source
   ↓
Look up destination
   ↓
Forward / Flood / Filter
   ↓
Age dynamic information
   ↓
Relearn when necessary

The most important troubleshooting relationship is:

IP address
     |
     | ARP
     v
MAC address
     |
     | Switch FDB
     v
Switch port

If an IP endpoint is unreachable, ARP Explained can tell you whether the expected IPv4-to-MAC relationship exists.

The MAC address table then tells you where the Layer 2 network believes that MAC address resides.

From there, you can determine whether the problem is:

Physical connectivity
VLAN membership
Switch forwarding
MAC instability
Layer 2 loop
ARP
Routing
Firewall
Endpoint

This makes MAC-table analysis one of the most valuable practical skills in network troubleshooting.

Continue with Routers, Switches and Network Devices for the broader switching architecture, ARP Explained for IPv4-to-MAC resolution, TCP/IP Explained for Layer 3 forwarding, and Network Security Basics for network-layer and access-security fundamentals.

For Linux software bridges, the official bridge manual documents bridge and forwarding-database administration. For Ethernet bridging standards, the IEEE 802.1 Working Group maintains the standards family underlying modern bridged networks.