Learning Bridges - Learning Module

Loading content...

0/228

MAC Table Learning: Self-Configuring Address Discovery

The Self-Learning Network Device

Imagine joining a new company where you know no one. On your first day, you don't have a directory of names and desk locations. But as colleagues introduce themselves, you gradually build a mental map: "Sarah sits near the window, Mike is in the corner office, the accounting team is on the third floor."

Network bridges face exactly this challenge—but they must solve it completely automatically, without any human intervention. When a bridge powers on, its forwarding database is empty. It knows nothing about which MAC addresses are reachable through which ports. Yet within seconds of network activity beginning, the bridge builds an accurate map of the network topology.

This remarkable capability is called MAC address learning, and it's one of the foundational technologies that makes modern Ethernet networks practical and scalable.

What You Will Learn

By the end of this page, you will master the MAC address learning process—from the exact algorithm bridges use to update their tables, to the data structures that enable microsecond lookups, hash collision handling, table overflow scenarios, and the implications for network design. You'll understand why this simple mechanism enables plug-and-play networking.

The Learning Algorithm

The MAC address learning algorithm is elegantly simple, yet remarkably effective. Every frame that arrives at a bridge carries information about the network topology: the source MAC address tells the bridge which device sent the frame, and the receiving port tells the bridge which direction that device is located.

The Fundamental Insight

Consider this: if a frame with source address AA:BB:CC:11:22:33 arrives on Port 1, then the device with that MAC address must be reachable through Port 1. The bridge can confidently add this information to its forwarding database. Later, when a frame arrives with destination AA:BB:CC:11:22:33, the bridge knows to forward it through Port 1.

This learning happens passively—the bridge doesn't need to send any special frames or request information from hosts. It simply observes normal network traffic and extracts topology information.

Converting Mermaid diagram...

Step-by-Step Learning Process

When a frame arrives at a bridge port, the learning process follows these exact steps:

Step 1: Extract Source MAC Address

The bridge reads the 6-byte source MAC address field from the frame header. This address identifies the device that transmitted the frame.

Step 2: Search Forwarding Database

The bridge searches its forwarding database for an existing entry matching this source MAC address.

Step 3: Update or Create Entry

Three outcomes are possible:

Case A: No Entry Exists

Create a new entry associating the MAC address with the receiving port. Initialize the aging timer for this entry.

Case B: Entry Exists with Same Port

The device hasn't moved. Simply reset the aging timer to indicate the address is still active.

Case C: Entry Exists with Different Port

The device has moved to a different segment. Update the entry to reflect the new port and reset the aging timer. This situation is called a MAC move and is important for understanding dynamic topologies.

Learning from Source, Not Destination

A critical detail: bridges learn from the source address of frames, never from the destination. This may seem obvious, but understanding why is important. The destination address tells us where the frame wants to go—not where anything actually is. Only the source address represents a device that is definitely reachable through the receiving port. If we learned from destination addresses, we would populate the table with incorrect information (e.g., learning broadcast addresses as if they were regular devices).

Forwarding Database Structure

The forwarding database (FDB), also called the MAC address table or CAM table (Content Addressable Memory), is the data structure at the heart of bridge operation. Its design directly impacts lookup performance, scalability, and functionality.

Entry Components

Each entry in the forwarding database contains:

MAC Address (48 bits): The unique hardware address of a network interface
Port Number: Which bridge port leads to this MAC address
Age/Timestamp: When the entry was last refreshed (for aging)
Entry Type: Dynamic (learned) or Static (manually configured)
VLAN ID (in VLAN-aware bridges): Which VLAN this entry applies to
Flags: Additional status information (e.g., multicast, blacklisted)

Sample Forwarding Database Contents
MAC Address	Port	Type	VLAN	Age (seconds)	Status
AA:BB:CC:11:22:33	1	Dynamic	10	45	Active
AA:BB:CC:44:55:66	1	Dynamic	10	120	Active
DD:EE:FF:77:88:99	2	Dynamic	20	287	Aging soon
11:22:33:AA:BB:CC	3	Static	10		Permanent
44:55:66:DD:EE:FF	2	Dynamic	20	5	Just learned
FF:FF:FF:FF:FF:FF	All	System			Broadcast (never learned)

Implementation with Content Addressable Memory (CAM)

For hardware-based switches, the forwarding database is typically implemented using CAM or TCAM (Ternary CAM):

Binary CAM

Binary CAM allows searching by exact match in constant time O(1). The hardware compares the search key (destination MAC address) against all stored addresses simultaneously in a single clock cycle.

All entries are compared in parallel
Match found in 1 clock cycle (typically 5-15 ns)
Very fast but power-hungry and expensive
Typical capacity: 16K - 512K entries

Hash Table Alternative

Software bridges and some hardware implementations use hash tables:

Hash the MAC address to get a bucket index
Search within the bucket (typically small)
Average case O(1), worst case O(n) if poorly designed
More flexible and cost-effective
Common in software switches and low-cost hardware

fdb_lookup_algorithm.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
def fdb_lookup(fdb_table: dict, mac_address: str, vlan_id: int) -> int | None:
    """
    Look up a MAC address in the forwarding database.
    
    In real switches, this is implemented in hardware (CAM) for
    wire-speed operation. This pseudocode illustrates the logic.
    
    Args:
        fdb_table: Dictionary mapping (MAC, VLAN) -> port number
        mac_address: 48-bit destination MAC address to look up
        vlan_id: VLAN context (for VLAN-aware bridges)
        
    Returns:
        Port number if found, None if unknown (flood required)
    """
    # Normalize MAC address format (AA:BB:CC:DD:EE:FF)
    normalized_mac = mac_address.upper().replace('-', ':')
    
    # Create lookup key (MAC + VLAN for VLAN-aware bridges)
    lookup_key = (normalized_mac, vlan_id)
    
    # HARDWARE: This lookup happens in CAM in ~10 nanoseconds
    # SOFTWARE: O(1) average with hash table implementation
    if lookup_key in fdb_table:
        entry = fdb_table[lookup_key]
        
        # Check if entry has expired (software implementation detail)
        if entry.is_expired():
            del fdb_table[lookup_key]
            return None  # Unknown, must flood
            
        return entry.port
    
    # No entry found - destination unknown
    return None  # Caller must flood to all ports
 
 
def fdb_learn(fdb_table: dict, src_mac: str, port: int, vlan_id: int) -> None:
    """
    Learn a source MAC address from incoming frame.
    
    Args:
        fdb_table: The forwarding database
        src_mac: Source MAC address from received frame
        port: Port number where frame was received
        vlan_id: VLAN context
    """
    normalized_mac = src_mac.upper().replace('-', ':')
    lookup_key = (normalized_mac, vlan_id)
    
    if lookup_key in fdb_table:
        existing_entry = fdb_table[lookup_key]
        
        if existing_entry.port != port:
            # MAC has moved to different port
            print(f"MAC move detected: {src_mac} moved from port "
                  f"{existing_entry.port} to port {port}")
        
        # Update entry with new port and reset age
        existing_entry.port = port
        existing_entry.reset_age_timer()
    else:
        # New MAC address - create entry
        fdb_table[lookup_key] = FDBEntry(
            mac=normalized_mac,
            port=port,
            vlan=vlan_id,
            entry_type="dynamic"
        )

Learning Scenarios and Edge Cases

While the basic learning algorithm is straightforward, several real-world scenarios require careful handling.

Scenario 1: Network Bootstrap (Cold Start)

When a bridge first powers on or reboots:

The forwarding database is completely empty
All frames are flooded (no learned destinations)
Network appears to work, but bandwidth is wasted
Traffic patterns cause rapid learning
Within seconds, most active addresses are learned
Flooding rate decreases as table populates

This is why bridges work immediately after power-on, even without configuration. The flooding behavior ensures packets are delivered while learning catch-up occurs.

Scenario 2: MAC Address Move

•Host physically moved to different port
•Frame arrives with known MAC on different port
•Bridge must update entry to new port
•Old entry pointing to wrong port would cause black hole
•Update happens immediately upon learning
•No manual intervention required

Legitimate Move Examples

•Laptop user moves to different room
•Virtual machine migrated to different host
•Failover in high-availability configuration
•Device reconnected to different wall jack
•Network recabling during maintenance
•Topology change after STP reconvergence

Scenario 3: Duplicate MAC Addresses

While MAC addresses are supposed to be globally unique, duplicates can occur:

Manufacturing defects or counterfeiting
Virtual machine cloning without MAC regeneration
Malicious MAC spoofing attacks
Legacy systems with configurable MACs

When duplicates exist, the bridge will continuously "flap" the entry between ports as traffic arrives from both locations. This causes:

Some traffic to be misdirected
Excessive CPU load from constant table updates
Log spam from MAC move notifications
Network instability for both duplicate devices

Most switches detect rapid MAC flapping and can take action (logging, port shutdown, notification).

MAC Flapping: A Symptom of Problems

Rapid MAC address movement (flapping) is almost always a symptom of a network problem. Common causes include: (1) Duplicate MAC addresses, (2) Network loops not blocked by STP, (3) Incorrectly configured link aggregation, (4) Virtual machine migration issues. When you see MAC flapping warnings in switch logs, investigate immediately—it indicates packet delivery is unreliable.

Scenario 4: Multicast and Broadcast Addresses

Special addresses require special handling:

Broadcast (FF:FF:FF:FF:FF:FF)

Broadcast addresses are never learned because:

They don't identify a specific source device
Learning them would create a nonsensical entry
Broadcasts are always flooded by design

Multicast (01:xx:xx:xx:xx:xx)

Multicast addresses have the group bit set (LSB of first byte = 1). Basic handling:

Never learned (no single source location)
Flooded like unknown unicast
With IGMP snooping, forwarded only to subscribed ports

Scenario 5: Unidirectional Traffic

Some traffic is one-way only (device sends but never receives responses):

Sensor devices that only transmit data
Monitoring/logging endpoints
Multicast sources without return traffic

For these devices:

The bridge learns the source address normally
Other devices cannot respond if they never send first
May remain "unknown" and receive flooded traffic forever
Static entries may be needed for optimization

Table Capacity and Overflow

Every forwarding database has a finite capacity. Understanding what happens when this limit is reached is crucial for network design and security.

Typical Forwarding Database Sizes

Table capacity varies dramatically by device class:

Consumer switches: 1,000 - 8,000 entries
Small business switches: 8,000 - 16,000 entries
Enterprise access switches: 16,000 - 32,000 entries
Enterprise distribution switches: 64,000 - 128,000 entries
Data center switches: 128,000 - 512,000+ entries

These limits exist due to CAM hardware constraints and cost trade-offs.

MAC Address Table Capacity Guidelines
Network Segment	Typical MAC Count	Table Size Needed	Headroom Factor
Small office floor (20 desks)	40-60 MACs	1,000 entries	~15x headroom
Large office building floor	200-400 MACs	4,000 entries	~10x headroom
Campus access layer (1000 users)	2,000-4,000 MACs	16,000 entries	~4x headroom
Data center ToR switch	10,000-50,000 MACs	128,000 entries	2-10x headroom
Data center spine/aggregation	50,000-200,000 MACs	512,000 entries	2-5x headroom

What Happens During Table Overflow?

When the forwarding database is full and a new MAC address needs to be learned:

Strategy 1: Reject New Entry

The new address is simply not learned. Consequences:

Traffic to/from this device continues to be flooded
Network still functions, but less efficiently
Bandwidth waste increases
No visible error to users

Strategy 2: Replace Oldest Entry

Remove the entry with the oldest timestamp and add the new one:

Ensures active devices remain in table
Rarely-used entries are sacrificed
Can cause temporary disruption if removed entry is later needed

Strategy 3: Replace Entry Based on Usage

More sophisticated: track how often each entry is used and replace the least-used entry:

Better performance under certain traffic patterns
More complex implementation
Not commonly implemented in hardware

Security Implication: MAC Flooding Attack

A malicious actor can intentionally overflow a switch's MAC table by generating frames with thousands of fake source MAC addresses. Once the table is full, the switch cannot learn legitimate addresses and floods all traffic to all ports—including traffic intended for other devices. This effectively turns the switch into a hub, allowing the attacker to see all network traffic. Defenses include port security (limiting MACs per port), 802.1X authentication, and dynamic ARP inspection.

Monitoring Table Utilization

Network administrators should monitor MAC table usage:

switch# show mac address-table count

MAC Entries for all VLANs:
Dynamic Address Count:    12,847
Static Address Count:     142
Total MAC Addresses:      12,989
Total MAC Entries in Use: 12,989
Total MAC Addresses Available: 32,768
Percent Used: 39.6%

Alerts should trigger when utilization exceeds 70-80% to allow time for capacity planning or investigation of unusual MAC address growth.

Best Practice: Network Segmentation

The best way to manage MAC table capacity is to limit the size of Layer 2 domains:

Use VLANs to segment broadcast domains
Route between major network sections
Each VLAN/segment has independent addressing
Failures and attacks are contained to smaller scopes

VLAN-Aware Learning

Modern switches implement VLANs (Virtual LANs), which adds complexity to the learning process. A MAC address learned in one VLAN is independent of the same address in another VLAN.

Why VLANs Affect Learning

Consider a network where:

VLAN 10 (Engineering) has Host A with MAC AA:11:22:33:44:55
VLAN 20 (Accounting) has Host B with MAC AA:11:22:33:44:55 (same MAC, different VLAN)

In a VLAN-unaware bridge, these would conflict—the table could only store one location for this MAC. But in a VLAN-aware bridge:

Entry 1: (AA:11:22:33:44:55, VLAN 10) → Port 1
Entry 2: (AA:11:22:33:44:55, VLAN 20) → Port 5

These are completely independent entries. Frames in VLAN 10 destined for this MAC go to Port 1; frames in VLAN 20 with the same destination go to Port 5.

Converting Mermaid diagram...

Shared VLAN Learning (SVL) vs. Independent VLAN Learning (IVL)

IEEE 802.1Q defines two learning modes:

Independent VLAN Learning (IVL)

Each VLAN has a completely separate forwarding database. A MAC address learned in one VLAN has no effect on lookups in other VLANs.

Maximum isolation between VLANs
Same MAC can map to different ports in different VLANs
Higher memory consumption (separate table per VLAN)
Standard behavior in most modern switches

Shared VLAN Learning (SVL)

All VLANs share a single forwarding database. If a MAC is learned in VLAN 10, it's used for forwarding in VLAN 20 as well.

Lower memory usage
Risk of misdirection if same MAC exists in multiple VLANs
Rarely used in modern implementations
Was more common in early VLAN-capable switches

IVL vs. SVL Comparison
Characteristic	Independent VLAN Learning (IVL)	Shared VLAN Learning (SVL)
MAC table scope	Per-VLAN	Global across all VLANs
Memory usage	Higher (VLANs × MACs)	Lower (single table)
Same MAC, different VLANs	Allowed (separate entries)	Conflict (single entry)
Security isolation	Strong	Weak
Modern usage	Standard	Rare/legacy only
Looking up key	(MAC, VLAN)	(MAC only)

Practical Implication

In enterprise environments, most switches use IVL by default. This means the MAC table capacity is divided among all VLANs. A switch with 32,000 entries doesn't give you 32,000 per VLAN—it gives you 32,000 total across all VLANs combined. Keep this in mind when calculating capacity requirements.

Static vs. Dynamic Entries

The forwarding database can contain two types of entries: dynamic entries learned automatically, and static entries configured manually by administrators.

Dynamic Entries

Dynamic entries are the norm in most networks:

Created automatically through the learning process
Subject to aging (expire after a configurable timeout)
Updated when MAC moves are detected
Require no administrator intervention
Form the vast majority of entries in typical networks

Static Entries

Static entries are manually configured and have different properties:

Never age out (permanent until manually removed)
Take precedence over dynamic entries
Used for specific administrative purposes
Require explicit configuration

When to Use Static Entries

•Critical servers: Prevent misdirection of server traffic, even temporarily
•Security pinning: Ensure traffic to security devices always takes expected path
•One-way transmitters: Devices that only send will never age out
•MAC filtering: Block specific MACs from the network
•Default gateway: Ensure gateway MAC is always known
•Testing/troubleshooting: Force traffic patterns for diagnosis

When to Avoid Static Entries

•Mobile devices: Static entries break when devices move
•Virtual machines: VMs may migrate between hosts
•Large-scale networks: Manual configuration doesn't scale
•Dynamic environments: Changes require reconfiguration
•When not needed: Adds complexity with no benefit
•Without documentation: Creates troubleshooting nightmares

Configuration Example

Creating a static entry on a Cisco switch:

switch(config)# mac address-table static aaaa.bbbb.cccc vlan 10 interface gigabitethernet0/1

This creates a permanent entry:

MAC address AA:AA:BB:BB:CC:CC → GigabitEthernet0/1 in VLAN 10
Entry will not age out
Takes precedence over any dynamic learning

Static Entry for Filtering

Static entries can also be used to block traffic:

switch(config)# mac address-table static aaaa.bbbb.cccc vlan 10 drop

Any frame with this source MAC will be dropped, and frames destined for this MAC will be discarded rather than flooded.

Port Security as an Alternative

Instead of creating static entries manually, consider using port security features. Port security can automatically learn and lock MAC addresses on a per-port basis, combining the benefits of automatic learning with the security of static entries. It can also limit the number of MACs per port, protecting against MAC flooding attacks.

Learning Rate and Performance

While learning seems instantaneous, there are performance considerations that affect how quickly a network converges to optimal forwarding.

Learning Rate Limits

Switches may impose limits on how quickly new entries can be added:

Why Rate Limiting?

Prevent CPU overload from processing many learning events
Defend against MAC flooding attacks
Ensure control plane remains responsive
Protect hardware resources

Typical Limits

Enterprise switches: 100-500 new MACs per second per port
High-performance switches: 1,000+ new MACs per second per port
Data center switches: 10,000+ new MACs per second total

These limits rarely impact legitimate traffic but provide protection against attacks and misbehaving devices.

Learning Performance Metrics
Metric	Typical Value	Impact of Poor Performance
Initial learning time	1-10 ms per entry	Delayed initial connectivity
Table update time	0.1-1 ms	Temporary misdirection after moves
Hash collision handling	1-10 additional lookups	Slower lookups in overloaded buckets
CAM lookup time	10-50 ns	Direct impact on frame latency
Max learning rate	100-10,000 entries/sec	Flood duration during bursts

Convergence Time After Events

Different network events cause different learning requirements:

Network Bootstrap

After a switch reboot, all entries must be relearned:

Time to learn = f(number of active MACs, traffic patterns)
For 1,000 active MACs with regular traffic: 5-30 seconds
During this time, excessive flooding occurs

Topology Change

After STP topology change:

Some or all entries may be flushed
Bridges in changed portion must relearn
Traffic temporarily flooded
Recovery time: 1-15 seconds typically

Single Device Move

When one device moves:

Old entry becomes stale (packets to old port fail)
First packet from new location triggers update
Subsequent traffic works normally
Recovery time: 0-5 seconds (depends on when device transmits)

Learning Is Passive, Not Active

A critical point often overlooked: bridges learn only when they observe traffic. If a device never transmits, it's never learned. This has implications for devices that only receive (e.g., monitoring systems). Traffic to such devices remains flooded until they transmit something, at which point their responses trigger learning throughout the path.

Summary: MAC Table Learning

We've thoroughly explored how bridges build and maintain their forwarding databases. Let's consolidate the essential concepts:

Key Takeaways

•Learning uses source addresses — Bridges learn by observing the source MAC of incoming frames, associating it with the receiving port.
•Three outcomes for each frame — New entry creation, existing entry refresh, or entry update (MAC move detection).
•CAM enables wire-speed lookup — Hardware-based Content Addressable Memory allows parallel search of thousands of entries in nanoseconds.
•VLAN-aware bridges use compound keys — The lookup key is (MAC address, VLAN ID), enabling the same MAC to exist in different VLANs.
•Table overflow causes flooding — When capacity is reached, unknown destinations increase; MAC flooding attacks exploit this.
•Static entries override learning — Manual entries take precedence and don't age, useful for critical infrastructure.

What's Next: Forwarding vs. Filtering

Now that we understand how the forwarding database is built, the next page examines how it's used. We'll dive deep into the forwarding and filtering decisions—exactly how the bridge determines whether to send a frame out a specific port, discard it entirely, or flood it everywhere. This is where learning translates into action.

Page Complete

You now understand the MAC address learning mechanism—how bridges automatically build their forwarding databases, handle edge cases like MAC moves and table overflow, implement VLAN-aware learning, and balance dynamic vs. static configuration. This knowledge is fundamental for understanding switching behavior and troubleshooting Layer 2 networks.

MAC Table Learning: Self-Configuring Address Discovery

The Self-Learning Network Device

This remarkable capability is called MAC address learning, and it's one of the foundational technologies that makes modern Ethernet networks practical and scalable.

What You Will Learn

The Learning Algorithm

The Fundamental Insight

This learning happens passively—the bridge doesn't need to send any special frames or request information from hosts. It simply observes normal network traffic and extracts topology information.

Converting Mermaid diagram...

Step-by-Step Learning Process

When a frame arrives at a bridge port, the learning process follows these exact steps:

Step 1: Extract Source MAC Address

The bridge reads the 6-byte source MAC address field from the frame header. This address identifies the device that transmitted the frame.

Step 2: Search Forwarding Database

The bridge searches its forwarding database for an existing entry matching this source MAC address.

Step 3: Update or Create Entry

Three outcomes are possible:

Case A: No Entry Exists

Create a new entry associating the MAC address with the receiving port. Initialize the aging timer for this entry.

Case B: Entry Exists with Same Port

The device hasn't moved. Simply reset the aging timer to indicate the address is still active.

Case C: Entry Exists with Different Port

Learning from Source, Not Destination

Forwarding Database Structure

Entry Components

Each entry in the forwarding database contains:

MAC Address (48 bits): The unique hardware address of a network interface
Port Number: Which bridge port leads to this MAC address
Age/Timestamp: When the entry was last refreshed (for aging)
Entry Type: Dynamic (learned) or Static (manually configured)
VLAN ID (in VLAN-aware bridges): Which VLAN this entry applies to
Flags: Additional status information (e.g., multicast, blacklisted)

Sample Forwarding Database Contents
MAC Address	Port	Type	VLAN	Age (seconds)	Status
AA:BB:CC:11:22:33	1	Dynamic	10	45	Active
AA:BB:CC:44:55:66	1	Dynamic	10	120	Active
DD:EE:FF:77:88:99	2	Dynamic	20	287	Aging soon
11:22:33:AA:BB:CC	3	Static	10		Permanent
44:55:66:DD:EE:FF	2	Dynamic	20	5	Just learned
FF:FF:FF:FF:FF:FF	All	System			Broadcast (never learned)

Implementation with Content Addressable Memory (CAM)

For hardware-based switches, the forwarding database is typically implemented using CAM or TCAM (Ternary CAM):

Binary CAM

Binary CAM allows searching by exact match in constant time O(1). The hardware compares the search key (destination MAC address) against all stored addresses simultaneously in a single clock cycle.

All entries are compared in parallel
Match found in 1 clock cycle (typically 5-15 ns)
Very fast but power-hungry and expensive
Typical capacity: 16K - 512K entries

Hash Table Alternative

Software bridges and some hardware implementations use hash tables:

Hash the MAC address to get a bucket index
Search within the bucket (typically small)
Average case O(1), worst case O(n) if poorly designed
More flexible and cost-effective
Common in software switches and low-cost hardware

fdb_lookup_algorithm.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
def fdb_lookup(fdb_table: dict, mac_address: str, vlan_id: int) -> int | None:
    """
    Look up a MAC address in the forwarding database.
    
    In real switches, this is implemented in hardware (CAM) for
    wire-speed operation. This pseudocode illustrates the logic.
    
    Args:
        fdb_table: Dictionary mapping (MAC, VLAN) -> port number
        mac_address: 48-bit destination MAC address to look up
        vlan_id: VLAN context (for VLAN-aware bridges)
        
    Returns:
        Port number if found, None if unknown (flood required)
    """
    # Normalize MAC address format (AA:BB:CC:DD:EE:FF)
    normalized_mac = mac_address.upper().replace('-', ':')
    
    # Create lookup key (MAC + VLAN for VLAN-aware bridges)
    lookup_key = (normalized_mac, vlan_id)
    
    # HARDWARE: This lookup happens in CAM in ~10 nanoseconds
    # SOFTWARE: O(1) average with hash table implementation
    if lookup_key in fdb_table:
        entry = fdb_table[lookup_key]
        
        # Check if entry has expired (software implementation detail)
        if entry.is_expired():
            del fdb_table[lookup_key]
            return None  # Unknown, must flood
            
        return entry.port
    
    # No entry found - destination unknown
    return None  # Caller must flood to all ports
 
 
def fdb_learn(fdb_table: dict, src_mac: str, port: int, vlan_id: int) -> None:
    """
    Learn a source MAC address from incoming frame.
    
    Args:
        fdb_table: The forwarding database
        src_mac: Source MAC address from received frame
        port: Port number where frame was received
        vlan_id: VLAN context
    """
    normalized_mac = src_mac.upper().replace('-', ':')
    lookup_key = (normalized_mac, vlan_id)
    
    if lookup_key in fdb_table:
        existing_entry = fdb_table[lookup_key]
        
        if existing_entry.port != port:
            # MAC has moved to different port
            print(f"MAC move detected: {src_mac} moved from port "
                  f"{existing_entry.port} to port {port}")
        
        # Update entry with new port and reset age
        existing_entry.port = port
        existing_entry.reset_age_timer()
    else:
        # New MAC address - create entry
        fdb_table[lookup_key] = FDBEntry(
            mac=normalized_mac,
            port=port,
            vlan=vlan_id,
            entry_type="dynamic"
        )

Learning Scenarios and Edge Cases

While the basic learning algorithm is straightforward, several real-world scenarios require careful handling.

Scenario 1: Network Bootstrap (Cold Start)

When a bridge first powers on or reboots:

The forwarding database is completely empty
All frames are flooded (no learned destinations)
Network appears to work, but bandwidth is wasted
Traffic patterns cause rapid learning
Within seconds, most active addresses are learned
Flooding rate decreases as table populates

This is why bridges work immediately after power-on, even without configuration. The flooding behavior ensures packets are delivered while learning catch-up occurs.

Scenario 2: MAC Address Move

•Host physically moved to different port
•Frame arrives with known MAC on different port
•Bridge must update entry to new port
•Old entry pointing to wrong port would cause black hole
•Update happens immediately upon learning
•No manual intervention required

Legitimate Move Examples

•Laptop user moves to different room
•Virtual machine migrated to different host
•Failover in high-availability configuration
•Device reconnected to different wall jack
•Network recabling during maintenance
•Topology change after STP reconvergence

Scenario 3: Duplicate MAC Addresses

While MAC addresses are supposed to be globally unique, duplicates can occur:

Manufacturing defects or counterfeiting
Virtual machine cloning without MAC regeneration
Malicious MAC spoofing attacks
Legacy systems with configurable MACs

When duplicates exist, the bridge will continuously "flap" the entry between ports as traffic arrives from both locations. This causes:

Some traffic to be misdirected
Excessive CPU load from constant table updates
Log spam from MAC move notifications
Network instability for both duplicate devices

Most switches detect rapid MAC flapping and can take action (logging, port shutdown, notification).

MAC Flapping: A Symptom of Problems

Scenario 4: Multicast and Broadcast Addresses

Special addresses require special handling:

Broadcast (FF:FF:FF:FF:FF:FF)

Broadcast addresses are never learned because:

They don't identify a specific source device
Learning them would create a nonsensical entry
Broadcasts are always flooded by design

Multicast (01:xx:xx:xx:xx:xx)

Multicast addresses have the group bit set (LSB of first byte = 1). Basic handling:

Never learned (no single source location)
Flooded like unknown unicast
With IGMP snooping, forwarded only to subscribed ports

Scenario 5: Unidirectional Traffic

Some traffic is one-way only (device sends but never receives responses):

Sensor devices that only transmit data
Monitoring/logging endpoints
Multicast sources without return traffic

For these devices:

The bridge learns the source address normally
Other devices cannot respond if they never send first
May remain "unknown" and receive flooded traffic forever
Static entries may be needed for optimization

Table Capacity and Overflow

Every forwarding database has a finite capacity. Understanding what happens when this limit is reached is crucial for network design and security.

Typical Forwarding Database Sizes

Table capacity varies dramatically by device class:

Consumer switches: 1,000 - 8,000 entries
Small business switches: 8,000 - 16,000 entries
Enterprise access switches: 16,000 - 32,000 entries
Enterprise distribution switches: 64,000 - 128,000 entries
Data center switches: 128,000 - 512,000+ entries

These limits exist due to CAM hardware constraints and cost trade-offs.

MAC Address Table Capacity Guidelines
Network Segment	Typical MAC Count	Table Size Needed	Headroom Factor
Small office floor (20 desks)	40-60 MACs	1,000 entries	~15x headroom
Large office building floor	200-400 MACs	4,000 entries	~10x headroom
Campus access layer (1000 users)	2,000-4,000 MACs	16,000 entries	~4x headroom
Data center ToR switch	10,000-50,000 MACs	128,000 entries	2-10x headroom
Data center spine/aggregation	50,000-200,000 MACs	512,000 entries	2-5x headroom

What Happens During Table Overflow?

When the forwarding database is full and a new MAC address needs to be learned:

Strategy 1: Reject New Entry

The new address is simply not learned. Consequences:

Traffic to/from this device continues to be flooded
Network still functions, but less efficiently
Bandwidth waste increases
No visible error to users

Strategy 2: Replace Oldest Entry

Remove the entry with the oldest timestamp and add the new one:

Ensures active devices remain in table
Rarely-used entries are sacrificed
Can cause temporary disruption if removed entry is later needed

Strategy 3: Replace Entry Based on Usage

More sophisticated: track how often each entry is used and replace the least-used entry:

Better performance under certain traffic patterns
More complex implementation
Not commonly implemented in hardware

Security Implication: MAC Flooding Attack

Monitoring Table Utilization

Network administrators should monitor MAC table usage:

switch# show mac address-table count

MAC Entries for all VLANs:
Dynamic Address Count:    12,847
Static Address Count:     142
Total MAC Addresses:      12,989
Total MAC Entries in Use: 12,989
Total MAC Addresses Available: 32,768
Percent Used: 39.6%

Alerts should trigger when utilization exceeds 70-80% to allow time for capacity planning or investigation of unusual MAC address growth.

Best Practice: Network Segmentation

The best way to manage MAC table capacity is to limit the size of Layer 2 domains:

Use VLANs to segment broadcast domains
Route between major network sections
Each VLAN/segment has independent addressing
Failures and attacks are contained to smaller scopes

VLAN-Aware Learning

Modern switches implement VLANs (Virtual LANs), which adds complexity to the learning process. A MAC address learned in one VLAN is independent of the same address in another VLAN.

Why VLANs Affect Learning

Consider a network where:

VLAN 10 (Engineering) has Host A with MAC AA:11:22:33:44:55
VLAN 20 (Accounting) has Host B with MAC AA:11:22:33:44:55 (same MAC, different VLAN)

In a VLAN-unaware bridge, these would conflict—the table could only store one location for this MAC. But in a VLAN-aware bridge:

Entry 1: (AA:11:22:33:44:55, VLAN 10) → Port 1
Entry 2: (AA:11:22:33:44:55, VLAN 20) → Port 5

These are completely independent entries. Frames in VLAN 10 destined for this MAC go to Port 1; frames in VLAN 20 with the same destination go to Port 5.

Converting Mermaid diagram...

Shared VLAN Learning (SVL) vs. Independent VLAN Learning (IVL)

IEEE 802.1Q defines two learning modes:

Independent VLAN Learning (IVL)

Each VLAN has a completely separate forwarding database. A MAC address learned in one VLAN has no effect on lookups in other VLANs.

Maximum isolation between VLANs
Same MAC can map to different ports in different VLANs
Higher memory consumption (separate table per VLAN)
Standard behavior in most modern switches

Shared VLAN Learning (SVL)

All VLANs share a single forwarding database. If a MAC is learned in VLAN 10, it's used for forwarding in VLAN 20 as well.

Lower memory usage
Risk of misdirection if same MAC exists in multiple VLANs
Rarely used in modern implementations
Was more common in early VLAN-capable switches

IVL vs. SVL Comparison
Characteristic	Independent VLAN Learning (IVL)	Shared VLAN Learning (SVL)
MAC table scope	Per-VLAN	Global across all VLANs
Memory usage	Higher (VLANs × MACs)	Lower (single table)
Same MAC, different VLANs	Allowed (separate entries)	Conflict (single entry)
Security isolation	Strong	Weak
Modern usage	Standard	Rare/legacy only
Looking up key	(MAC, VLAN)	(MAC only)

Practical Implication

Static vs. Dynamic Entries

The forwarding database can contain two types of entries: dynamic entries learned automatically, and static entries configured manually by administrators.

Dynamic Entries

Dynamic entries are the norm in most networks:

Created automatically through the learning process
Subject to aging (expire after a configurable timeout)
Updated when MAC moves are detected
Require no administrator intervention
Form the vast majority of entries in typical networks

Static Entries

Static entries are manually configured and have different properties:

Never age out (permanent until manually removed)
Take precedence over dynamic entries
Used for specific administrative purposes
Require explicit configuration

When to Use Static Entries

•Critical servers: Prevent misdirection of server traffic, even temporarily
•Security pinning: Ensure traffic to security devices always takes expected path
•One-way transmitters: Devices that only send will never age out
•MAC filtering: Block specific MACs from the network
•Default gateway: Ensure gateway MAC is always known
•Testing/troubleshooting: Force traffic patterns for diagnosis

When to Avoid Static Entries

•Mobile devices: Static entries break when devices move
•Virtual machines: VMs may migrate between hosts
•Large-scale networks: Manual configuration doesn't scale
•Dynamic environments: Changes require reconfiguration
•When not needed: Adds complexity with no benefit
•Without documentation: Creates troubleshooting nightmares

Configuration Example

Creating a static entry on a Cisco switch:

switch(config)# mac address-table static aaaa.bbbb.cccc vlan 10 interface gigabitethernet0/1

This creates a permanent entry:

MAC address AA:AA:BB:BB:CC:CC → GigabitEthernet0/1 in VLAN 10
Entry will not age out
Takes precedence over any dynamic learning

Static Entry for Filtering

Static entries can also be used to block traffic:

switch(config)# mac address-table static aaaa.bbbb.cccc vlan 10 drop

Any frame with this source MAC will be dropped, and frames destined for this MAC will be discarded rather than flooded.

Port Security as an Alternative

Learning Rate and Performance

While learning seems instantaneous, there are performance considerations that affect how quickly a network converges to optimal forwarding.

Learning Rate Limits

Switches may impose limits on how quickly new entries can be added:

Why Rate Limiting?

Prevent CPU overload from processing many learning events
Defend against MAC flooding attacks
Ensure control plane remains responsive
Protect hardware resources

Typical Limits

Enterprise switches: 100-500 new MACs per second per port
High-performance switches: 1,000+ new MACs per second per port
Data center switches: 10,000+ new MACs per second total

These limits rarely impact legitimate traffic but provide protection against attacks and misbehaving devices.

Learning Performance Metrics
Metric	Typical Value	Impact of Poor Performance
Initial learning time	1-10 ms per entry	Delayed initial connectivity
Table update time	0.1-1 ms	Temporary misdirection after moves
Hash collision handling	1-10 additional lookups	Slower lookups in overloaded buckets
CAM lookup time	10-50 ns	Direct impact on frame latency
Max learning rate	100-10,000 entries/sec	Flood duration during bursts

Convergence Time After Events

Different network events cause different learning requirements:

Network Bootstrap

After a switch reboot, all entries must be relearned:

Time to learn = f(number of active MACs, traffic patterns)
For 1,000 active MACs with regular traffic: 5-30 seconds
During this time, excessive flooding occurs

Topology Change

After STP topology change:

Some or all entries may be flushed
Bridges in changed portion must relearn
Traffic temporarily flooded
Recovery time: 1-15 seconds typically

Single Device Move

When one device moves:

Old entry becomes stale (packets to old port fail)
First packet from new location triggers update
Subsequent traffic works normally
Recovery time: 0-5 seconds (depends on when device transmits)

Learning Is Passive, Not Active

Summary: MAC Table Learning

We've thoroughly explored how bridges build and maintain their forwarding databases. Let's consolidate the essential concepts:

Key Takeaways

•Learning uses source addresses — Bridges learn by observing the source MAC of incoming frames, associating it with the receiving port.
•Three outcomes for each frame — New entry creation, existing entry refresh, or entry update (MAC move detection).
•CAM enables wire-speed lookup — Hardware-based Content Addressable Memory allows parallel search of thousands of entries in nanoseconds.
•VLAN-aware bridges use compound keys — The lookup key is (MAC address, VLAN ID), enabling the same MAC to exist in different VLANs.
•Table overflow causes flooding — When capacity is reached, unknown destinations increase; MAC flooding attacks exploit this.
•Static entries override learning — Manual entries take precedence and don't age, useful for critical infrastructure.

What's Next: Forwarding vs. Filtering

Page Complete