Every microsecond, network bridges face a simple but critical question: What should I do with this frame? The answer—forward, filter, or flood—determines whether networks operate efficiently or waste bandwidth broadcasting traffic everywhere.

This decision is the moment where learning translates into action. The carefully built forwarding database exists precisely to answer this question as quickly and accurately as possible.

Understanding forwarding and filtering is essential because:

• It explains how bridges improve network performance
• It reveals why some network problems occur (loops, storms, misdirection)
• It provides insight into switch behavior during troubleshooting
• It forms the foundation for understanding more complex features like VLANs and ACLs

When a frame arrives at a bridge port, the decision process follows a specific sequence. Understanding this sequence is fundamental to predicting bridge behavior.

The Complete Decision Algorithm

Here is the full decision tree that a bridge follows for every incoming frame:

Decision Outcomes Explained

1. DROP (FCS Error)

If the Frame Check Sequence doesn't match the calculated CRC, the frame is corrupted. It's silently discarded. The bridge increments error counters but sends no notification to the sender—error recovery is the responsibility of higher-layer protocols.

2. FORWARD

The destination MAC is found in the forwarding database, and the associated port is different from the receiving port. The frame is queued for transmission on that specific port only. This is the optimal outcome—traffic is precisely directed.

3. FILTER

The destination MAC is found in the forwarding database, but the associated port is the same as the receiving port. This means source and destination are on the same segment—the frame doesn't need to cross the bridge. It's discarded (filtered), preventing unnecessary traffic on other segments.

4. FLOOD

The frame is copied to all ports except the receiving port. This occurs when:

• The destination MAC is unknown
• The destination is the broadcast address (FF:FF:FF:FF:FF:FF)
• The destination is a multicast address (without IGMP snooping)

Flooding ensures delivery when the specific destination is unknown but consumes more bandwidth.

Forwarding is the primary function of a bridge—directing known unicast traffic efficiently along optimal paths.

The Forwarding Process

When the decision is to forward:

1. Queue Selection: The frame is placed in the output queue for the destination port. High-end switches have multiple queues per port for QoS prioritization.

2. Congestion Check: If the output queue is full, the switch must decide whether to drop the new frame (tail drop), drop an existing frame, or use more sophisticated algorithms like WRED (Weighted Random Early Detection).

3. Transmission Scheduling: The frame waits its turn for transmission. In half-duplex mode, CSMA/CD rules apply. In full-duplex mode, frames are transmitted as soon as the port is available.

4. Frame Transmission: The frame is transmitted on the destination port. In store-and-forward mode, this happens after the complete frame is received and verified. In cut-through mode, transmission may have already started.

Multi-Destination Forwarding

In some cases, a single frame must be forwarded to multiple ports:

Unicast Frame Replication

In specific scenarios, such as port mirroring/SPAN configurations, a unicast frame may be copied to additional ports for monitoring purposes. The original forwarding decision is unchanged, but copies are created.

Multicast With IGMP Snooping

When IGMP snooping is enabled, multicast frames are forward to:

• All ports with registered multicast receivers for that group
• Router ports (where multicast routers are connected)

This is still "forwarding" (informed by membership data), not flooding.

Frame Modification During Forwarding

In basic bridging, frames are not modified—the same bytes received are transmitted. However, VLAN-aware bridges may:

• Add VLAN tags when forwarding from access to trunk ports
• Remove VLAN tags when forwarding from trunk to access ports
• Rewrite priority bits based on QoS policy

The underlying MAC addresses and payload remain unchanged.

Filtering is the quiet hero of bridge operation—traffic that doesn't need to cross the bridge simply doesn't. This is how bridges create collision domain separation while maintaining a unified broadcast domain.

When Filtering Occurs

Filtering happens when the destination MAC address lookup reveals that the destination device is on the same port as the source device. Since both devices share the same segment, the frame doesn't need bridge assistance—it was already delivered when the source transmitted it on the shared medium.

Example Scenario

Consider this network:

[Host A]---+
           |--- Port 1 ---[Bridge]--- Port 2 ---+---[Host C]
[Host B]---+                                    +---[Host D]

Host A sends a frame to Host B:

1. The frame arrives at the bridge on Port 1 (source: A, destination: B)
2. Bridge learns: A is reachable via Port 1
3. Bridge looks up B's MAC address
4. If B is known on Port 1, the frame is filtered (discarded)
5. Host A and B communicate without affecting Port 2

Meanwhile, Host C and D can simultaneously communicate on Port 2 without collision—the bridge has effectively created two independent collision domains.

Filtering Efficiency Measurement

The percentage of traffic filtered by a bridge is a key metric:

Filtering Ratio = (Frames Filtered / Total Frames Received) × 100%

Typical values:

• Office network with localized traffic: 60-80% filtering
• Server farm with centralized servers: 20-40% filtering
• Well-designed campus network: 70-90% filtering on access switches
• Poorly designed flat network: 10-30% filtering

A low filtering ratio indicates that most traffic crosses the bridge, suggesting:

• Servers are on wrong segments relative to clients
• Traffic patterns don't match physical topology
• Consider reorganizing topology or using VLANs

Special Filtering Cases

Same-Port Broadcast Filtering

Broadcasts are NOT filtered even when all devices receiving them are on the same port as the source. This is because broadcasts are by definition intended for all devices on the broadcast domain, including those on other ports.

Self-Addressed Frames

If a frame's source and destination MAC are the same (invalid, but can happen with misconfigured software), the bridge will:

1. Learn the source address on the receiving port
2. Look up the destination (same address)
3. Find it on the same port (just learned)
4. Filter the frame

The frame is discarded, which is the correct behavior for this invalid scenario.

Static Filter Entries

Administrators can create static entries that cause specific MAC addresses to be filtered (dropped) regardless of which port they're found on. This provides MAC-based access control:

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

Any frame TO this MAC address will be dropped; any frame FROM this MAC address will also be dropped (port security violation).

Flooding is the fallback behavior when the bridge cannot determine the specific destination port. While necessary for network operation, flooding has significant implications for performance and security.

Types of Flooding

1. Unknown Unicast Flooding

When the destination MAC address isn't in the forwarding database, the bridge must flood. Common causes:

• New device that hasn't transmitted yet (not learned)
• Entry aged out due to inactivity
• Table overflow (new entries couldn't be learned)
• Device recently moved (old entry, now incorrect location)

2. Broadcast Flooding

Frames with destination FF:FF:FF:FF:FF:FF must always be flooded—this is the defined behavior for broadcasts. Examples:

• ARP requests ("Who has IP 10.0.0.1?")
• DHCP discover ("Any DHCP servers out there?")
• NetBIOS name queries
• Some routing protocol messages

3. Multicast Flooding

Without IGMP snooping enabled, multicast traffic (destination starting with 01:xx:xx) is flooded. With snooping, it's forwarded only to interested parties.

Flooding Scope

Understanding where flooded frames go:

Within a VLAN: In VLAN-aware bridges, flooding is constrained to the VLAN. A flood in VLAN 10 doesn't reach ports in VLAN 20. This VLAN isolation is critical for controlling broadcast domains.

Across Bridges: Flooded frames cross bridges just like forwarded frames. If Bridge A floods to Bridge B, Bridge B will either forward (if known) or flood again. This allows unknown unicast to eventually reach any device in the network—but at the cost of bandwidth.

Trunk Ports: On trunk ports carrying multiple VLANs, the flood is tagged with the appropriate VLAN. The frame is still only flooded within its VLAN.

Implications of Excessive Flooding

1. Bandwidth Waste

Every flooded frame consumes bandwidth on every port. A 1 Gbps link carrying flooded traffic can fill with frames that only one port actually needs.

2. Security Exposure

Flooded frames reach devices not intended as recipients. Attackers can exploit this by putting NICs in promiscuous mode to capture flooded traffic.

3. CPU Impact

While the switch handles flooding in hardware, end hosts must process flooded frames to determine if they're intended recipients. This consumes host CPU cycles.

4. Congestion Chain Reaction

In oversubscribed networks, flooding can trigger congestion that causes more flooding (through buffer overflows losing learned entries), creating a negative feedback loop.

Real networks contain multiple bridges (switches). Understanding how traffic flows through these networks requires tracing the forwarding decision at each hop.

Frame Delivery Across Multiple Bridges

Consider a linear topology:

[Host A]---[Bridge 1]---[Bridge 2]---[Bridge 3]---[Host B]

When Host A sends a frame to Host B:

Step 1: Bridge 1

• Receives frame on port connected to Host A
• Learns Host A's MAC on that port
• Looks up Host B's MAC
  • If known (via port toward Bridge 2): Forward
  • If unknown: Flood (including toward Bridge 2)

Step 2: Bridge 2

• Receives frame on port connected to Bridge 1
• Learns Host A's MAC on that port (learns toward Host A)
• Looks up Host B's MAC
  • If known (via port toward Bridge 3): Forward
  • If unknown: Flood

Step 3: Bridge 3

• Receives frame on port connected to Bridge 2
• Learns Host A's MAC on that port
• Looks up Host B's MAC
  • If known (via Host B's port): Forward
  • If unknown: Flood, reaches Host B

When Host B responds:

• Each bridge along the path now has entries for both ends
• Response frame is forwarded (not flooded) at each hop
• Subsequent traffic in both directions is efficiently forwarded

Key Observations

1. Learning Propagates Backward

As frames traverse bridges, each bridge learns the source address. This means the source's location is learned at every bridge along the path—not just the first one.

2. Initial Flooding is Normal

The first frame in a new conversation is almost always flooded at some bridges. This is expected behavior, not an error. The flooding enables discovery; subsequent frames are forwarded.

3. Asymmetric Paths

If multiple paths exist (and STP has blocked some), forward and return traffic may take different routes. Each bridge independently makes forwarding decisions based on its own FDB.

4. Convergence Time

for a new host:

• First outbound frame: Flooded at most/all bridges
• First return frame: Might still be flooded (if return path not the same as forward path)
• Subsequent frames: Forwarded efficiently

This convergence happens within milliseconds of traffic flow beginning.

Let's work through a concrete example showing how forwarding tables evolve and drive traffic decisions.

Network Topology

Consider a simple network:

          VLAN 10
    [PC1: AA:11:...]--+
                     |--Port 1
    [PC2: BB:22:...]--+
                              [Switch]              
    [Server1: CC:33:...]------Port 2
    
    [Server2: DD:44:...]------Port 3

Analysis of Each Event

T1: PC1 → Server1 (Initial Traffic)

• Source: AA:11:... (PC1)
• Destination: CC:33:... (Server1)
• Learning: PC1's MAC added to FDB → Port 1
• Lookup: Server1's MAC not found
• Decision: FLOOD to Ports 2 and 3
• Result: Server1 receives frame, Server2 also receives it (waste)

T4: PC1 → PC2 (Same Segment Traffic)

• Source: AA:11:... (PC1)
• Destination: BB:22:... (PC2)
• Learning: PC1's MAC refreshed on Port 1
• Lookup: PC2's MAC found on Port 1
• Decision: FILTER (same port as source)
• Result: Frame discarded by switch, but PC2 already received it directly on shared medium

This is the filtering optimization in action—local traffic stays local.

Viewing the FDB on Real Switches

Cisco IOS:

switch# show mac address-table
Mac Address Table
-------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       ----        -----
  10    aa11.0000.0001    DYNAMIC     Gi0/1
  10    bb22.0000.0002    DYNAMIC     Gi0/1
  10    cc33.0000.0003    DYNAMIC     Gi0/2
  10    dd44.0000.0004    DYNAMIC     Gi0/3

Certain MAC addresses receive special treatment in the forwarding decision process. Understanding these exceptions is essential for complete mastery of bridge behavior.

1. Broadcast Address (FF:FF:FF:FF:FF:FF)

The all-ones broadcast address is always flooded:

• Never added to the forwarding database (as destination or source)
• Always flooded to all ports in the VLAN
• Receiving hosts process broadcast frames
• Essential for protocols like ARP, DHCP, etc.

2. Multicast Addresses (01:xx:xx:xx:xx:xx)

MAC addresses with the group bit set (least significant bit of first octet = 1):

• Never learned as source addresses (groups don't transmit)
• Default behavior: Flood like unknown unicast
• With IGMP snooping: Forward only to subscribed ports
• Special reserved addresses handled by specific protocols

3. Local Link Layer Addresses

IEEE reserved addresses in the 01:80:C2:00:00:0x range receive special handling:

• These addresses are never forwarded by bridges
• They're processed locally by the switch/bridge itself
• Intended for link-local protocols (STP, LACP, LLDP, etc.)
• Ensures these protocols operate on a per-link basis, not network-wide

4. Locally Administered Addresses

MAC addresses with the locally administered bit set (second-least significant bit of first octet = 1):

• Valid addresses, but not globally unique
• Often used by VMs, containers, and virtual interfaces
• Forwarded normally; no special behavior
• More likely to cause duplicate MAC issues

Identifying Address Types

The first byte of a MAC address encodes important information:

Bit 0 (LSB): Group/Individual
  0 = Unicast (individual address)
  1 = Multicast/Broadcast (group address)

Bit 1: Universal/Local  
  0 = Universally administered (OUI-based)
  1 = Locally administered (may not be unique)

Examples:

• 00:1A:2B:... → Unicast, universal (normal NIC)
• 01:00:5E:... → Multicast, universal (IPv4 multicast)
• 02:42:AC:... → Unicast, local (Docker container)
• FE:FF:FF:... → Would be multicast (group bit set)

We've thoroughly examined how bridges make forwarding decisions. Let's consolidate the essential concepts:

What's Next: Aging Entries

We've seen how entries enter the forwarding database (learning) and how they're used (forwarding/filtering). But what happens when devices become inactive or leave the network? The next page explores entry aging—the mechanism that keeps the forwarding database fresh and accurate by removing stale entries that no longer reflect network reality.