Computer NetworksLearning Bridges

Learning Bridges: Intelligent LAN Interconnection

LevelIntermediate

Duration90 mins

TopicLearning Bridges

4 / 5

Aging Entries: Managing Forwarding Database Lifecycle

The Problem of Stale Information

Networks are dynamic. Devices power off, laptops move to different desks, virtual machines migrate between hosts, and cables get unplugged. If a bridge's forwarding database never forgot anything, these changes would cause serious problems.

Imagine this scenario:

Host A (MAC AA:11:22:33:44:55) is connected to Port 1
The bridge learns: AA:11:22:33:44:55 → Port 1
Host A is moved to Port 3 (but the bridge doesn't know yet)
Host B tries to reach Host A
Bridge forwards to Port 1 (wrong port!)
Traffic is black-holed until Host A transmits and triggers re-learning

Without a mechanism to remove stale entries, moved devices would experience prolonged outages, unplugged devices would consume table space indefinitely, and the forwarding database would eventually fill with garbage.

The solution is entry aging—a timer-based mechanism that automatically removes entries that haven't been refreshed by recent traffic.

What You Will Learn

By the end of this page, you will understand the aging mechanism in detail—including timer operation, default values and configuration, the relationship between aging and topology changes, how aging interacts with STP, and best practices for tuning aging timers in various network environments.

The Aging Mechanism

Every dynamic entry in the forwarding database has an associated age—either a timestamp of last update or a countdown timer. The bridge uses this age to determine when entries should be removed.

How Aging Works

1. Entry Creation

When a new MAC address is learned, a timer is initialized. This can be implemented as:

A timestamp recording when the entry was created/updated
A countdown timer set to the aging time

2. Entry Refresh on Traffic

Every time a frame is received with this MAC as the source address:

Timestamp-based: Update timestamp to current time
Countdown-based: Reset timer to full aging time

This keeps active entries alive indefinitely.

3. Periodic Aging Check

The bridge periodically examines all entries:

Timestamp-based: Remove entries where (current_time - timestamp) > aging_time
Countdown-based: Decrement timers, remove entries that reach zero

4. Entry Removal (Aging Out)

When an entry ages out:

It's removed from the forwarding database
Future traffic to this destination will be flooded
If the device is still present, it will be re-learned when it transmits

Converting Mermaid diagram...

Default Aging Time

The IEEE 802.1D standard specifies a default aging time of 300 seconds (5 minutes). This value represents a balance between:

Responsiveness: Shorter times mean faster adaptation to topology changes
Stability: Longer times mean less flooding during idle periods

Most network equipment uses 300 seconds as the default, but this is configurable.

Why 300 Seconds?

The 5-minute default was chosen based on typical network behavior patterns:

Most devices transmit at least once every 5 minutes (ARP, DHCP renewals, keepalives)
Long enough to ride out brief transmission pauses without unnecessary flooding
Short enough that moved/removed devices don't persist too long
Aligned with ARP cache timeout defaults in many operating systems

This value made sense for networks of the 1990s. Modern networks may benefit from adjustment.

Static Entries Never Age

It's critical to understand that aging only applies to dynamic entries (those learned automatically). Static entries configured by administrators never age out—they remain in the table until manually removed. This is by design: static entries are for critical addresses that must always be known.

Configuring Aging Timers

Aging time is a tunable parameter on virtually all managed switches. Understanding when and how to adjust it is an important network administration skill.

Configuration Commands

Cisco IOS:

! Global configuration
switch(config)# mac address-table aging-time 120

! Per-VLAN configuration (some platforms)
switch(config)# mac address-table aging-time 120 vlan 10

! Verify configuration
switch# show mac address-table aging-time
Global Aging Time:  120
Vlan    Aging Time
----    ----------
  10          120
  20          300

Juniper Junos:

[edit ethernet-switching-options]
set mac-table-aging-time 120

HP/Aruba:

switch(config)# mac-age-time 120

Linux Bridge:

# Set aging time to 120 seconds
ip link set br0 type bridge ageing_time 12000
# Note: Linux uses centiseconds (12000 = 120 seconds)

Aging Time Recommendations by Environment
Environment	Suggested Aging Time	Rationale
Stable data center	300-600 seconds	Devices rarely move; fewer timeouts, less flooding
Office with mobile users	120-300 seconds	Laptops move between ports; faster adaptation
High-change VM environment	60-120 seconds	VMs migrate frequently; need quick path updates
Industrial control network	600-1200 seconds	Devices extremely stable; minimize any disruption
Public WiFi/guest network	60-120 seconds	Clients come and go; table space matters
After STP topology change	15-30 seconds (temporary)	Accelerated flush to quickly relearn correct paths

Trade-offs When Adjusting Aging Time

Shorter Aging Time (< 300 seconds)

Pros:

Faster adaptation to topology changes
Quicker recovery from misconfigured paths
Less table space consumed by inactive devices

Cons:

More flooding during idle periods
Higher CPU utilization checking entries more frequently
May impact devices with irregular traffic patterns (e.g., printers)

Longer Aging Time (> 300 seconds)

Pros:

Less flooding; better bandwidth efficiency
Accommodates devices with infrequent traffic
More stable forwarding paths

Cons:

Slower adaptation to moves/failures
Stale entries persist longer
Table may fill with inactive MACs

Disable Aging (Aging Time = 0)

Setting aging time to 0 disables aging—entries never expire. This is rarely appropriate because moved devices will be permanently black-holed until they transmit. However, it might be used in extremely static networks (embedded systems, industrial control) where no device ever moves and table space is ample.

Aging and Spanning Tree Protocol

The interaction between MAC aging and Spanning Tree Protocol (STP) is critical for understanding network convergence behavior.

The Problem: Topology Changes

When STP reconverges due to a link failure or addition:

The active topology changes
Paths that were valid are now invalid
New paths become optimal
The forwarding database contains entries pointing to the old paths

If we wait for normal aging (5 minutes), traffic will be misdirected for up to 5 minutes—unacceptable for modern networks.

The Solution: Accelerated Aging on TCN

When STP detects a Topology Change, bridges take special action:

Topology Change Notification (TCN) is propagated through the network
Bridges receiving TCN reduce their aging time to the forward delay (default 15 seconds)
This accelerated aging persists for max_age + forward_delay seconds
Most/all dynamic entries age out during this period
Traffic floods briefly, relearning occurs, correct paths are established

Converting Mermaid diagram...

Parameters Involved

Several STP parameters affect aging behavior during topology changes:

Forward Delay (default: 15 seconds)

Becomes the temporary aging time during TC
Entries older than this age out immediately

Max Age (default: 20 seconds)

How long TC-triggered accelerated aging persists
After max_age + forward_delay, normal aging resumes

Topology Change Time = max_age + forward_delay = 35 seconds

Duration of accelerated aging period

Rapid Spanning Tree (RSTP) Improvements

RSTP (802.1w) improves on classic STP:

Topology changes are detected faster
TCN propagation is immediate (per-port, not just root-bound)
Affected ports flush entries immediately, not just accelerate aging
Recovery time drops from 30+ seconds to sub-second in many cases

Topology Change Storms

Frequent topology changes cause repeated table flushes, leading to constant flooding and poor network performance. Common causes include: flapping links (intermittent physical issues), misconfigured port fast settings, and aggressive STP parameters. Monitor for excessive Topology Change Notifications in switch logs.

Aging Implementation Details

Understanding how aging is actually implemented helps explain some edge cases and performance characteristics.

Timestamp-Based Aging

The most common implementation:

Entry Structure:
{
    mac_address: 48 bits,
    port: port_id,
    last_seen: 32-bit timestamp (seconds since epoch),
    type: static | dynamic
}

Aging Process (runs periodically, e.g., every second):
    current_time = get_current_time()
    for each entry in fdb:
        if entry.type == dynamic:
            if (current_time - entry.last_seen) > aging_time:
                remove(entry)

Pros:

Simple implementation
Easy to query age of any entry
Debugging-friendly (can see exact last-seen time)

Cons:

Requires periodic scan of entire table
Timestamp comparison for every entry
CPU overhead scales with table size

aging_simulation.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
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
from dataclasses import dataclass
from time import time
from typing import Dict, Optional
 
@dataclass
class FDBEntry:
    """Forwarding Database Entry with aging support"""
    mac_address: str
    port: int
    last_seen: float
    entry_type: str = "dynamic"  # "dynamic" or "static"
    
    def age(self, current_time: float) -> float:
        """Return age in seconds"""
        return current_time - self.last_seen
    
    def is_expired(self, current_time: float, aging_time: float) -> bool:
        """Check if entry has exceeded aging time"""
        if self.entry_type == "static":
            return False  # Static entries never expire
        return self.age(current_time) > aging_time
 
 
class ForwardingDatabase:
    """Simulates bridge forwarding database with aging"""
    
    def __init__(self, aging_time: float = 300.0):
        self.entries: Dict[str, FDBEntry] = {}
        self.aging_time = aging_time
        
    def learn(self, mac: str, port: int) -> None:
        """Learn or update a MAC address"""
        current_time = time()
        
        if mac in self.entries:
            entry = self.entries[mac]
            if entry.entry_type == "static":
                return  # Don't overwrite static entries
            
            if entry.port != port:
                print(f"MAC move: {mac} moved from port {entry.port} to {port}")
            
            entry.port = port
            entry.last_seen = current_time
        else:
            self.entries[mac] = FDBEntry(
                mac_address=mac,
                port=port,
                last_seen=current_time,
                entry_type="dynamic"
            )
            print(f"Learned: {mac} on port {port}")
    
    def lookup(self, mac: str) -> Optional[int]:
        """Look up destination port for a MAC address"""
        if mac not in self.entries:
            return None  # Unknown - must flood
        
        entry = self.entries[mac]
        return entry.port
    
    def run_aging(self) -> int:
        """Remove expired entries, return count of removed entries"""
        current_time = time()
        expired = []
        
        for mac, entry in self.entries.items():
            if entry.is_expired(current_time, self.aging_time):
                expired.append(mac)
        
        for mac in expired:
            print(f"Aged out: {mac} (age: {self.entries[mac].age(current_time):.0f}s)")
            del self.entries[mac]
        
        return len(expired)
    
    def set_aging_time(self, seconds: float) -> None:
        """Adjust aging time (e.g., during STP topology change)"""
        self.aging_time = seconds
        print(f"Aging time set to {seconds} seconds")
 
 
# Example usage demonstrating aging
if __name__ == "__main__":
    fdb = ForwardingDatabase(aging_time=10)  # Short aging for demo
    
    # Simulate learning
    fdb.learn("AA:BB:CC:11:22:33", 1)
    fdb.learn("DD:EE:FF:44:55:66", 2)
    
    # Wait and run aging (in real code, this runs periodically)
    import time as t
    t.sleep(12)
    
    removed = fdb.run_aging()
    print(f"Removed {removed} aged entries")

Hardware Accelerated Aging

In high-performance switches, aging may be implemented in hardware:

CAM entries include age bits that are automatically cleared when matched
Hardware periodically scans and removes entries with cleared age bits
Scanning happens in parallel with normal forwarding
No CPU involvement for routine aging

Aging Granularity

Most implementations have aging granularity of 1 second—entries may persist up to 1 second longer than the configured aging time. This is the resolution at which the aging process runs and is generally acceptable.

Some implementations have coarser granularity (5-10 seconds) to reduce CPU overhead. This is transparent to administrators but may cause slight timing variations.

Manual Entry Management

While aging handles routine maintenance automatically, administrators sometimes need to manually intervene with forwarding database entries.

Clearing the Entire FDB

For troubleshooting or recovery, you may need to flush all learned entries:

Cisco IOS:

! Clear all dynamic entries
switch# clear mac address-table dynamic

! Clear entries for specific interface
switch# clear mac address-table dynamic interface gigabitethernet0/1

! Clear entries for specific VLAN
switch# clear mac address-table dynamic vlan 10

! Clear specific MAC address
switch# clear mac address-table dynamic address aaaa.bbbb.cccc

When to Manually Clear

After physical topology changes: Cables moved, ports reassigned
During troubleshooting: Clear and observe relearning
Security incidents: Force re-authentication of devices
Lab/testing: Reset to clean state between tests

When to Clear FDB Manually

•Persistent traffic black holes
•MAC address conflicts confirmed
•After major cabling changes
•Post-security incident cleanup
•Troubleshooting STP issues
•Testing/validation scenarios

When NOT to Clear FDB

•Routine maintenance (aging handles this)
•Suspected network issues (investigate first)
•High-traffic production periods
•Without understanding consequences
•On core switches without preparation
•As a 'fix everything' attempt

Impact of Manual Clear

Clearing the FDB causes immediate flooding:

All destinations become "unknown"
Traffic floods to all ports until relearned
Brief bandwidth spike and possible congestion
Security monitoring may trigger on flooding behavior
Normal operation resumes within seconds as learning catches up

Viewing FDB and Entry Ages

To understand what's happening with aging:

! View table with ages
switch# show mac address-table

! View specific entry detail
switch# show mac address-table address aaaa.bbbb.cccc

! View table statistics
switch# show mac address-table count

Some platforms show the exact age of each entry; others only show whether entries are dynamic or static. For detailed age tracking, check platform-specific documentation.

Production Impact

Clearing the FDB on a core or distribution switch affects all traffic passing through that switch. The resulting flood can overwhelm links and trigger congestion on connected switches. In production, clear selectively (by VLAN, port, or MAC) rather than clearing everything if possible.

Aging Edge Cases and Behaviors

Several situations reveal interesting aspects of aging behavior that are important for advanced troubleshooting.

Edge Case 1: Receive-Only Devices

Some devices only receive traffic and never transmit (or transmit very rarely):

Network monitoring sensors
Passive logging servers
Sniffer/IDS systems

For these devices:

They're never learned (no source frames to observe)
Traffic to them is always flooded
This is actually correct behavior—flooding ensures delivery
Can waste bandwidth; IGMP snooping helps for multicast cases

Solution: Create static entries for receive-only devices if bandwidth is a concern.

Edge Case 2: Infrequent Transmitters

Devices that transmit less often than the aging time:

Printers (may sit idle for hours)
IoT sensors (transmit periodically, e.g., every 10 minutes)
Backup systems (active only during backup windows)

These devices may age out between transmissions, causing their traffic to be flooded.

Solutions:

Increase aging time if network is stable
Create static entries for known critical devices
Use SNMP/keepalive to refresh entries (some systems support this)
Accept flooding as occasional cost of simplicity

Device Categories and Aging Considerations
Device Type	Traffic Pattern	Aging Risk	Recommendation
Desktop PC	Regular, bidirectional	Low—constant traffic refreshes	Default aging works well
Laptop (wired)	Variable, may move	Medium—mobility, idle periods	Shorter aging if many mobile
Server	Heavy, constant	Very low—always active	Default or longer aging
Network printer	Bursty, long idle periods	High—may age out frequently	Static entry or longer aging
IoT sensor	Periodic, one-way	Very high—may never be learned	Static entry typically required
Virtual machine	Variable, may migrate	Variable—depends on migration	Shorter aging for VMware/etc.

Edge Case 3: Link Down Events

When a port goes down, what happens to entries learned on that port?

Most implementations: Entries are immediately flushed when the port link status changes to down. This is proactive—we know those paths are invalid, so why wait for aging?

Some implementations: Entries persist and age normally. This can cause delays in reconvergence.

Check your switch vendor's behavior:

switch# show mac address-table interface gigabitethernet0/1
! Unplug the cable
! Wait a moment
switch# show mac address-table interface gigabitethernet0/1
! If empty, entries were flushed on link-down

Edge Case 4: VLAN Changes

When a port's VLAN assignment changes:

Entries learned on the old VLAN become invalid
Port-based VLAN changes should flush entries for that port
Trunks with dynamic VLAN additions may behave differently

Always verify that VLAN changes properly update the FDB—stale cross-VLAN entries can cause subtle connectivity issues.

Per-VLAN vs. Global Aging

Some switches allow configuring aging time per-VLAN, while others only support a global setting. Per-VLAN aging is useful when you have VLANs with different mobility characteristics—e.g., a static server VLAN might use longer aging than a mobile user VLAN.

Monitoring and Troubleshooting

Effective monitoring of aging behavior helps identify network issues before they impact users.

Key Metrics to Monitor

1. Table Size Over Time

Track how many entries are in the FDB:

Gradual growth: Normal as devices are discovered
Sudden spikes: Possible MAC flooding attack or loop
Sudden drops: Mass aging event or manual clear
Constant churn: Unstable topology or flapping

2. Aging Events Rate

How often entries age out:

Low rate: Stable network with active devices
High rate: Possible idle devices or short aging time
Correlated spikes: May indicate topology changes

3. Unknown Unicast Flood Rate

How often flooding occurs:

Low baseline: Well-learned network
Spikes: New devices, topology changes, or attacks
Sustained high rate: Possible table overflow or aggressive aging

Troubleshooting FDB Issues
Symptom	Possible Cause	Investigation Steps
Traffic black-holed to specific destination	Stale FDB entry pointing wrong port	Check FDB for destination MAC; verify port; clear if wrong
Excessive flooding in network	Table overflow, aggressive aging, or attack	Check table utilization; verify aging config; look for flood source
MAC keeps appearing on different ports	MAC flapping due to loop or attack	Check STP status; investigate loop; enable storm control
Device works intermittently	Ages out between transmissions	Check aging time; add static entry if needed
New device can't communicate	Not learned yet, depends on flooding	Wait for transmission; check port config
Post-topology-change flooding	Normal STP TC behavior	If prolonged, check for STP issues

Useful Commands for Troubleshooting

View complete FDB state:

switch# show mac address-table
switch# show mac address-table count
switch# show mac address-table aging-time

Track specific MAC:

switch# show mac address-table address aaaa.bbbb.cccc

Debug learning/aging (use carefully):

switch# debug mac-address-table
! Warning: Can generate massive output in busy networks

SNMP Monitoring:

Standard MIBs provide FDB access:

dot1dTpFdbTable (802.1D bridge MIB)
dot1qTpFdbTable (802.1Q VLAN MIB)

These can be polled to track:

Total entry count
Entry churn rate
Specific MAC presence
Age of entries (implementation-dependent)

Proactive Monitoring Baseline

Establish a baseline of normal FDB behavior: typical table size, typical churn rate, expected entries per VLAN. When problems occur, comparing current state to the baseline makes anomalies obvious. Many network monitoring systems can graph these metrics over time.

Summary: Aging Entries

We've thoroughly examined how bridges manage the lifecycle of forwarding database entries. Let's consolidate the essential concepts:

Key Takeaways

•Aging removes stale entries — Dynamic entries are removed after a period of inactivity (default 300 seconds), ensuring the FDB reflects current topology.
•Traffic refreshes entries — Every frame received from a MAC address resets its aging timer, keeping active entries alive indefinitely.
•STP triggers accelerated aging — Topology changes cause rapid table flushing (15-second aging) to quickly learn new paths.
•Static entries never age — Administratively configured entries persist until manually removed, suitable for critical infrastructure.
•Aging time is tunable — Adjust based on network mobility, stability, and table capacity requirements.
•Manual clear causes flooding — Clearing the FDB forces relearning through flooding; use selectively in production.

What's Next: The Loop Problem

We've now covered learning, forwarding, filtering, and aging—the complete lifecycle of FDB entries. But there's a critical vulnerability in all of this: what happens when there are loops in the network topology? Without special handling, loops cause catastrophic failures. The next page explores the loop problem—why it occurs, its devastating effects, and how it's detected.

Page Complete

You now understand the aging mechanism—how it works, why it exists, how to configure it, and how it interacts with STP. This knowledge completes your understanding of FDB lifecycle management and prepares you for understanding why loop prevention (covered next) is absolutely critical.

4 / 5

Loading learning content...

Learning Bridges: Intelligent LAN Interconnection - Page 4 of 5 | OneNoughtOne

Computer NetworksLearning Bridges

Learning Bridges: Intelligent LAN Interconnection

LevelIntermediate

Duration90 mins

TopicLearning Bridges

4 / 5

Aging Entries: Managing Forwarding Database Lifecycle

The Problem of Stale Information

Imagine this scenario:

Host A (MAC AA:11:22:33:44:55) is connected to Port 1
The bridge learns: AA:11:22:33:44:55 → Port 1
Host A is moved to Port 3 (but the bridge doesn't know yet)
Host B tries to reach Host A
Bridge forwards to Port 1 (wrong port!)
Traffic is black-holed until Host A transmits and triggers re-learning

The solution is entry aging—a timer-based mechanism that automatically removes entries that haven't been refreshed by recent traffic.

What You Will Learn

The Aging Mechanism

How Aging Works

1. Entry Creation

When a new MAC address is learned, a timer is initialized. This can be implemented as:

A timestamp recording when the entry was created/updated
A countdown timer set to the aging time

2. Entry Refresh on Traffic

Every time a frame is received with this MAC as the source address:

Timestamp-based: Update timestamp to current time
Countdown-based: Reset timer to full aging time

This keeps active entries alive indefinitely.

3. Periodic Aging Check

The bridge periodically examines all entries:

Timestamp-based: Remove entries where (current_time - timestamp) > aging_time
Countdown-based: Decrement timers, remove entries that reach zero

4. Entry Removal (Aging Out)

When an entry ages out:

It's removed from the forwarding database
Future traffic to this destination will be flooded
If the device is still present, it will be re-learned when it transmits

Converting Mermaid diagram...

Default Aging Time

The IEEE 802.1D standard specifies a default aging time of 300 seconds (5 minutes). This value represents a balance between:

Responsiveness: Shorter times mean faster adaptation to topology changes
Stability: Longer times mean less flooding during idle periods

Most network equipment uses 300 seconds as the default, but this is configurable.

Why 300 Seconds?

The 5-minute default was chosen based on typical network behavior patterns:

Most devices transmit at least once every 5 minutes (ARP, DHCP renewals, keepalives)
Long enough to ride out brief transmission pauses without unnecessary flooding
Short enough that moved/removed devices don't persist too long
Aligned with ARP cache timeout defaults in many operating systems

This value made sense for networks of the 1990s. Modern networks may benefit from adjustment.

Static Entries Never Age

Configuring Aging Timers

Aging time is a tunable parameter on virtually all managed switches. Understanding when and how to adjust it is an important network administration skill.

Configuration Commands

Cisco IOS:

! Global configuration
switch(config)# mac address-table aging-time 120

! Per-VLAN configuration (some platforms)
switch(config)# mac address-table aging-time 120 vlan 10

! Verify configuration
switch# show mac address-table aging-time
Global Aging Time:  120
Vlan    Aging Time
----    ----------
  10          120
  20          300

Juniper Junos:

[edit ethernet-switching-options]
set mac-table-aging-time 120

HP/Aruba:

switch(config)# mac-age-time 120

Linux Bridge:

# Set aging time to 120 seconds
ip link set br0 type bridge ageing_time 12000
# Note: Linux uses centiseconds (12000 = 120 seconds)

Aging Time Recommendations by Environment
Environment	Suggested Aging Time	Rationale
Stable data center	300-600 seconds	Devices rarely move; fewer timeouts, less flooding
Office with mobile users	120-300 seconds	Laptops move between ports; faster adaptation
High-change VM environment	60-120 seconds	VMs migrate frequently; need quick path updates
Industrial control network	600-1200 seconds	Devices extremely stable; minimize any disruption
Public WiFi/guest network	60-120 seconds	Clients come and go; table space matters
After STP topology change	15-30 seconds (temporary)	Accelerated flush to quickly relearn correct paths

Trade-offs When Adjusting Aging Time

Shorter Aging Time (< 300 seconds)

Pros:

Faster adaptation to topology changes
Quicker recovery from misconfigured paths
Less table space consumed by inactive devices

Cons:

More flooding during idle periods
Higher CPU utilization checking entries more frequently
May impact devices with irregular traffic patterns (e.g., printers)

Longer Aging Time (> 300 seconds)

Pros:

Less flooding; better bandwidth efficiency
Accommodates devices with infrequent traffic
More stable forwarding paths

Cons:

Slower adaptation to moves/failures
Stale entries persist longer
Table may fill with inactive MACs

Disable Aging (Aging Time = 0)

Aging and Spanning Tree Protocol

The interaction between MAC aging and Spanning Tree Protocol (STP) is critical for understanding network convergence behavior.

The Problem: Topology Changes

When STP reconverges due to a link failure or addition:

The active topology changes
Paths that were valid are now invalid
New paths become optimal
The forwarding database contains entries pointing to the old paths

If we wait for normal aging (5 minutes), traffic will be misdirected for up to 5 minutes—unacceptable for modern networks.

The Solution: Accelerated Aging on TCN

When STP detects a Topology Change, bridges take special action:

Topology Change Notification (TCN) is propagated through the network
Bridges receiving TCN reduce their aging time to the forward delay (default 15 seconds)
This accelerated aging persists for max_age + forward_delay seconds
Most/all dynamic entries age out during this period
Traffic floods briefly, relearning occurs, correct paths are established

Converting Mermaid diagram...

Parameters Involved

Several STP parameters affect aging behavior during topology changes:

Forward Delay (default: 15 seconds)

Becomes the temporary aging time during TC
Entries older than this age out immediately

Max Age (default: 20 seconds)

How long TC-triggered accelerated aging persists
After max_age + forward_delay, normal aging resumes

Topology Change Time = max_age + forward_delay = 35 seconds

Duration of accelerated aging period

Rapid Spanning Tree (RSTP) Improvements

RSTP (802.1w) improves on classic STP:

Topology changes are detected faster
TCN propagation is immediate (per-port, not just root-bound)
Affected ports flush entries immediately, not just accelerate aging
Recovery time drops from 30+ seconds to sub-second in many cases

Topology Change Storms

Aging Implementation Details

Understanding how aging is actually implemented helps explain some edge cases and performance characteristics.

Timestamp-Based Aging

The most common implementation:

Entry Structure:
{
    mac_address: 48 bits,
    port: port_id,
    last_seen: 32-bit timestamp (seconds since epoch),
    type: static | dynamic
}

Aging Process (runs periodically, e.g., every second):
    current_time = get_current_time()
    for each entry in fdb:
        if entry.type == dynamic:
            if (current_time - entry.last_seen) > aging_time:
                remove(entry)

Pros:

Simple implementation
Easy to query age of any entry
Debugging-friendly (can see exact last-seen time)

Cons:

Requires periodic scan of entire table
Timestamp comparison for every entry
CPU overhead scales with table size

aging_simulation.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
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
from dataclasses import dataclass
from time import time
from typing import Dict, Optional
 
@dataclass
class FDBEntry:
    """Forwarding Database Entry with aging support"""
    mac_address: str
    port: int
    last_seen: float
    entry_type: str = "dynamic"  # "dynamic" or "static"
    
    def age(self, current_time: float) -> float:
        """Return age in seconds"""
        return current_time - self.last_seen
    
    def is_expired(self, current_time: float, aging_time: float) -> bool:
        """Check if entry has exceeded aging time"""
        if self.entry_type == "static":
            return False  # Static entries never expire
        return self.age(current_time) > aging_time
 
 
class ForwardingDatabase:
    """Simulates bridge forwarding database with aging"""
    
    def __init__(self, aging_time: float = 300.0):
        self.entries: Dict[str, FDBEntry] = {}
        self.aging_time = aging_time
        
    def learn(self, mac: str, port: int) -> None:
        """Learn or update a MAC address"""
        current_time = time()
        
        if mac in self.entries:
            entry = self.entries[mac]
            if entry.entry_type == "static":
                return  # Don't overwrite static entries
            
            if entry.port != port:
                print(f"MAC move: {mac} moved from port {entry.port} to {port}")
            
            entry.port = port
            entry.last_seen = current_time
        else:
            self.entries[mac] = FDBEntry(
                mac_address=mac,
                port=port,
                last_seen=current_time,
                entry_type="dynamic"
            )
            print(f"Learned: {mac} on port {port}")
    
    def lookup(self, mac: str) -> Optional[int]:
        """Look up destination port for a MAC address"""
        if mac not in self.entries:
            return None  # Unknown - must flood
        
        entry = self.entries[mac]
        return entry.port
    
    def run_aging(self) -> int:
        """Remove expired entries, return count of removed entries"""
        current_time = time()
        expired = []
        
        for mac, entry in self.entries.items():
            if entry.is_expired(current_time, self.aging_time):
                expired.append(mac)
        
        for mac in expired:
            print(f"Aged out: {mac} (age: {self.entries[mac].age(current_time):.0f}s)")
            del self.entries[mac]
        
        return len(expired)
    
    def set_aging_time(self, seconds: float) -> None:
        """Adjust aging time (e.g., during STP topology change)"""
        self.aging_time = seconds
        print(f"Aging time set to {seconds} seconds")
 
 
# Example usage demonstrating aging
if __name__ == "__main__":
    fdb = ForwardingDatabase(aging_time=10)  # Short aging for demo
    
    # Simulate learning
    fdb.learn("AA:BB:CC:11:22:33", 1)
    fdb.learn("DD:EE:FF:44:55:66", 2)
    
    # Wait and run aging (in real code, this runs periodically)
    import time as t
    t.sleep(12)
    
    removed = fdb.run_aging()
    print(f"Removed {removed} aged entries")

Hardware Accelerated Aging

In high-performance switches, aging may be implemented in hardware:

CAM entries include age bits that are automatically cleared when matched
Hardware periodically scans and removes entries with cleared age bits
Scanning happens in parallel with normal forwarding
No CPU involvement for routine aging

Aging Granularity

Some implementations have coarser granularity (5-10 seconds) to reduce CPU overhead. This is transparent to administrators but may cause slight timing variations.

Manual Entry Management

While aging handles routine maintenance automatically, administrators sometimes need to manually intervene with forwarding database entries.

Clearing the Entire FDB

For troubleshooting or recovery, you may need to flush all learned entries:

Cisco IOS:

! Clear all dynamic entries
switch# clear mac address-table dynamic

! Clear entries for specific interface
switch# clear mac address-table dynamic interface gigabitethernet0/1

! Clear entries for specific VLAN
switch# clear mac address-table dynamic vlan 10

! Clear specific MAC address
switch# clear mac address-table dynamic address aaaa.bbbb.cccc

When to Manually Clear

After physical topology changes: Cables moved, ports reassigned
During troubleshooting: Clear and observe relearning
Security incidents: Force re-authentication of devices
Lab/testing: Reset to clean state between tests

When to Clear FDB Manually

•Persistent traffic black holes
•MAC address conflicts confirmed
•After major cabling changes
•Post-security incident cleanup
•Troubleshooting STP issues
•Testing/validation scenarios

When NOT to Clear FDB

•Routine maintenance (aging handles this)
•Suspected network issues (investigate first)
•High-traffic production periods
•Without understanding consequences
•On core switches without preparation
•As a 'fix everything' attempt

Impact of Manual Clear

Clearing the FDB causes immediate flooding:

All destinations become "unknown"
Traffic floods to all ports until relearned
Brief bandwidth spike and possible congestion
Security monitoring may trigger on flooding behavior
Normal operation resumes within seconds as learning catches up

Viewing FDB and Entry Ages

To understand what's happening with aging:

! View table with ages
switch# show mac address-table

! View specific entry detail
switch# show mac address-table address aaaa.bbbb.cccc

! View table statistics
switch# show mac address-table count

Some platforms show the exact age of each entry; others only show whether entries are dynamic or static. For detailed age tracking, check platform-specific documentation.

Production Impact

Aging Edge Cases and Behaviors

Several situations reveal interesting aspects of aging behavior that are important for advanced troubleshooting.

Edge Case 1: Receive-Only Devices

Some devices only receive traffic and never transmit (or transmit very rarely):

Network monitoring sensors
Passive logging servers
Sniffer/IDS systems

For these devices:

They're never learned (no source frames to observe)
Traffic to them is always flooded
This is actually correct behavior—flooding ensures delivery
Can waste bandwidth; IGMP snooping helps for multicast cases

Solution: Create static entries for receive-only devices if bandwidth is a concern.

Edge Case 2: Infrequent Transmitters

Devices that transmit less often than the aging time:

Printers (may sit idle for hours)
IoT sensors (transmit periodically, e.g., every 10 minutes)
Backup systems (active only during backup windows)

These devices may age out between transmissions, causing their traffic to be flooded.

Solutions:

Increase aging time if network is stable
Create static entries for known critical devices
Use SNMP/keepalive to refresh entries (some systems support this)
Accept flooding as occasional cost of simplicity

Device Categories and Aging Considerations
Device Type	Traffic Pattern	Aging Risk	Recommendation
Desktop PC	Regular, bidirectional	Low—constant traffic refreshes	Default aging works well
Laptop (wired)	Variable, may move	Medium—mobility, idle periods	Shorter aging if many mobile
Server	Heavy, constant	Very low—always active	Default or longer aging
Network printer	Bursty, long idle periods	High—may age out frequently	Static entry or longer aging
IoT sensor	Periodic, one-way	Very high—may never be learned	Static entry typically required
Virtual machine	Variable, may migrate	Variable—depends on migration	Shorter aging for VMware/etc.

Edge Case 3: Link Down Events

When a port goes down, what happens to entries learned on that port?

Most implementations: Entries are immediately flushed when the port link status changes to down. This is proactive—we know those paths are invalid, so why wait for aging?

Some implementations: Entries persist and age normally. This can cause delays in reconvergence.

Check your switch vendor's behavior:

switch# show mac address-table interface gigabitethernet0/1
! Unplug the cable
! Wait a moment
switch# show mac address-table interface gigabitethernet0/1
! If empty, entries were flushed on link-down

Edge Case 4: VLAN Changes

When a port's VLAN assignment changes:

Entries learned on the old VLAN become invalid
Port-based VLAN changes should flush entries for that port
Trunks with dynamic VLAN additions may behave differently

Always verify that VLAN changes properly update the FDB—stale cross-VLAN entries can cause subtle connectivity issues.

Per-VLAN vs. Global Aging

Monitoring and Troubleshooting

Effective monitoring of aging behavior helps identify network issues before they impact users.

Key Metrics to Monitor

1. Table Size Over Time

Track how many entries are in the FDB:

Gradual growth: Normal as devices are discovered
Sudden spikes: Possible MAC flooding attack or loop
Sudden drops: Mass aging event or manual clear
Constant churn: Unstable topology or flapping

2. Aging Events Rate

How often entries age out:

Low rate: Stable network with active devices
High rate: Possible idle devices or short aging time
Correlated spikes: May indicate topology changes

3. Unknown Unicast Flood Rate

How often flooding occurs:

Low baseline: Well-learned network
Spikes: New devices, topology changes, or attacks
Sustained high rate: Possible table overflow or aggressive aging

Troubleshooting FDB Issues
Symptom	Possible Cause	Investigation Steps
Traffic black-holed to specific destination	Stale FDB entry pointing wrong port	Check FDB for destination MAC; verify port; clear if wrong
Excessive flooding in network	Table overflow, aggressive aging, or attack	Check table utilization; verify aging config; look for flood source
MAC keeps appearing on different ports	MAC flapping due to loop or attack	Check STP status; investigate loop; enable storm control
Device works intermittently	Ages out between transmissions	Check aging time; add static entry if needed
New device can't communicate	Not learned yet, depends on flooding	Wait for transmission; check port config
Post-topology-change flooding	Normal STP TC behavior	If prolonged, check for STP issues

Useful Commands for Troubleshooting

View complete FDB state:

switch# show mac address-table
switch# show mac address-table count
switch# show mac address-table aging-time

Track specific MAC:

switch# show mac address-table address aaaa.bbbb.cccc

Debug learning/aging (use carefully):

switch# debug mac-address-table
! Warning: Can generate massive output in busy networks

SNMP Monitoring:

Standard MIBs provide FDB access:

dot1dTpFdbTable (802.1D bridge MIB)
dot1qTpFdbTable (802.1Q VLAN MIB)

These can be polled to track:

Total entry count
Entry churn rate
Specific MAC presence
Age of entries (implementation-dependent)

Proactive Monitoring Baseline

Summary: Aging Entries

We've thoroughly examined how bridges manage the lifecycle of forwarding database entries. Let's consolidate the essential concepts:

Key Takeaways

•Aging removes stale entries — Dynamic entries are removed after a period of inactivity (default 300 seconds), ensuring the FDB reflects current topology.
•Traffic refreshes entries — Every frame received from a MAC address resets its aging timer, keeping active entries alive indefinitely.
•STP triggers accelerated aging — Topology changes cause rapid table flushing (15-second aging) to quickly learn new paths.
•Static entries never age — Administratively configured entries persist until manually removed, suitable for critical infrastructure.
•Aging time is tunable — Adjust based on network mobility, stability, and table capacity requirements.
•Manual clear causes flooding — Clearing the FDB forces relearning through flooding; use selectively in production.

What's Next: The Loop Problem

Page Complete

4 / 5