Network Devices: Repeaters, Hubs, Bridges, Switches, and Routers

The repeater and hub solved the problem of physical signal extension but introduced a critical limitation: as networks grew, the single collision domain became a performance bottleneck. Every device competed for the same bandwidth, collisions increased proportionally with device count, and network performance degraded unacceptably.

The bridge represented a conceptual breakthrough—the first networking device to operate at the Data Link Layer (Layer 2) of the OSI model. Instead of blindly repeating every signal, a bridge examines each frame's destination MAC address and makes an intelligent forwarding decision: send the frame only where it's needed, or drop it if the destination is on the same segment as the source.

This seemingly simple intelligence—learning which devices are connected to which ports and forwarding selectively—transformed network design. Suddenly, large networks could be segmented into smaller, independent collision domains, each operating at full efficiency.

A bridge is a network device that operates at the Data Link Layer (Layer 2) of the OSI model. It connects two or more network segments and makes forwarding decisions based on MAC addresses contained within each frame. This represents a fundamental shift from the Physical Layer operation of repeaters and hubs.

Core Bridge Characteristics:

Bridge vs. Repeater/Hub: Conceptual Comparison:

Historical Context:

Bridges emerged in the mid-1980s as networks grew beyond what single collision domains could efficiently handle. The theoretical foundation was laid by Radia Perlman and others at Digital Equipment Corporation, who developed the spanning tree algorithm (which we'll cover in a later module) to enable bridges to operate in redundant topologies.

The term 'bridge' reflects the device's original use case: connecting two existing LAN segments—'bridging' between them—rather than the multi-port design we now associate with switches.

The defining characteristic of bridge operation is the store-and-forward architecture. Unlike repeaters that immediately retransmit incoming signals, bridges receive and buffer the complete frame before making a forwarding decision.

The Store-and-Forward Process:

┌─────────────────────────────────────────────────────────────────┐
│              Bridge Store-and-Forward Operation                  │
└─────────────────────────────────────────────────────────────────┘

   Incoming Frame                    Bridge Processing
   ─────────────                    ──────────────────

   ┌──────────────────────┐
   │ Preamble + SFD       │  ──►  Synchronize, detect frame start
   ├──────────────────────┤
   │ Destination MAC      │  ──►  Read destination for forwarding
   ├──────────────────────┤
   │ Source MAC           │  ──►  Learn: associate with ingress port
   ├──────────────────────┤
   │ Type/Length          │  ──►  Store in buffer
   ├──────────────────────┤
   │ Payload              │  ──►  Store in buffer (up to 1500 bytes)
   ├──────────────────────┤
   │ FCS (CRC-32)         │  ──►  Validate entire frame integrity
   └──────────────────────┘
                                   │
                                   ▼
                            ┌────────────────┐
                            │  CRC Valid?    │
                            └───────┬────────┘
                                    │
                    ┌───────────────┴───────────────┐
                    │                               │
                    ▼                               ▼
              ┌─────────┐                    ┌─────────────┐
              │  Yes    │                    │    No       │
              └────┬────┘                    └──────┬──────┘
                   │                                │
                   ▼                                ▼
          Lookup destination                  Drop frame
          in forwarding table                 (no forwarding)

Benefits of Store-and-Forward:

1. Error Isolation: By validating the FCS (Frame Check Sequence) before forwarding, bridges prevent corrupted frames from propagating. A frame damaged on one segment is discarded rather than wasting bandwidth on all segments.

2. Speed Buffering: Store-and-forward bridges can connect segments of different speeds. A 10 Mbps segment can communicate with a 100 Mbps segment; the bridge buffers frames as needed to accommodate the speed difference.

3. Complete Address Information: The bridge has access to both source and destination MAC addresses before making any forwarding decision, enabling accurate learning and forwarding.

4. Frame Filtering: Bridges can examine additional frame fields and implement filtering rules (in advanced implementations) based on frame content.

Latency Implications:

Store-and-forward introduces latency equal to the time required to receive the entire frame plus processing time:

Latency = Frame Reception Time + Processing Time + Transmission Time

For a 1518-byte frame at 10 Mbps:
- Reception: 1518 × 8 bits ÷ 10 Mbps = 1,214.4 μs ≈ 1.2 ms
- Processing: typically 10-100 μs
- Transmission: same as reception on equal-speed port

Total: ~2.5 ms per bridge hop (worst case)

This latency was considered significant in early networks but is negligible in modern switched networks with microsecond-level processing.

The bridge's ability to learn MAC addresses automatically—without any manual configuration—is among its most valuable features. This transparent learning process builds the forwarding table dynamically as the network operates.

The Learning Algorithm:

When a bridge receives a frame on any port:

1. Extract the Source MAC Address from the frame header
2. Check if the address exists in the forwarding table
3. If new: Add an entry mapping this MAC address to the receiving port
4. If exists with same port: Reset the aging timer (address still reachable via this port)
5. If exists with different port: Update the port mapping (device has moved)
6. Proceed to forwarding decision (independent of learning)

Why Source Address?

The learning algorithm uses the source MAC address because:

• The source address identifies a device that definitely exists and just transmitted
• Learning from destination addresses would learn addresses that might not be reachable
• Source learning is passive—devices don't need to participate in the learning process

Learning Walkthrough Example:

Consider a two-port bridge connecting Segment A (Port 1) and Segment B (Port 2):

Initial State: Forwarding table is empty

Step 1: Device A1 (MAC: AA:AA:AA:AA:AA:AA) on Segment A
        sends a frame to Device B1
        
        Bridge receives frame on Port 1
        Source MAC: AA:AA:AA:AA:AA:AA
        Action: Learn AA:AA:AA:AA:AA:AA → Port 1
        
        Forwarding Table:
        | AA:AA:AA:AA:AA:AA | Port 1 | Age: 0 |

Step 2: Device B1 (MAC: BB:BB:BB:BB:BB:BB) on Segment B
        sends a reply to Device A1
        
        Bridge receives frame on Port 2
        Source MAC: BB:BB:BB:BB:BB:BB
        Action: Learn BB:BB:BB:BB:BB:BB → Port 2
        
        Forwarding Table:
        | AA:AA:AA:AA:AA:AA | Port 1 | Age: 5 |
        | BB:BB:BB:BB:BB:BB | Port 2 | Age: 0 |

Step 3: Device A2 (MAC: CC:CC:CC:CC:CC:CC) on Segment A
        sends a frame to Device B1
        
        Bridge receives frame on Port 1
        Source MAC: CC:CC:CC:CC:CC:CC
        Action: Learn CC:CC:CC:CC:CC:CC → Port 1
        
        Forwarding Table:
        | AA:AA:AA:AA:AA:AA | Port 1 | Age: 10 |
        | BB:BB:BB:BB:BB:BB | Port 2 | Age: 5  |
        | CC:CC:CC:CC:CC:CC | Port 1 | Age: 0  |

This passive learning process continues as long as the bridge operates, building a complete map of MAC address locations without any administrative intervention.

After learning the source address location, the bridge makes a forwarding decision based on the frame's destination MAC address. This decision determines whether to forward, filter, or flood the frame.

The Forwarding Algorithm:

RECEIVE frame on port P:
    
    1. Learn source_MAC → port P (as described above)
    
    2. Extract destination_MAC from frame
    
    3. IF destination_MAC is broadcast (FF:FF:FF:FF:FF:FF)
           OR destination_MAC is multicast (01:xx:xx:xx:xx:xx):
           → FLOOD: Forward to ALL ports except port P
    
    4. ELSE lookup destination_MAC in forwarding table:
       
       4a. IF destination_MAC found AND mapped to port P:
           → FILTER: Do not forward (destination on same segment)
       
       4b. IF destination_MAC found AND mapped to port Q (Q ≠ P):
           → FORWARD: Send frame out port Q only
       
       4c. IF destination_MAC NOT found in table:
           → FLOOD: Forward to ALL ports except port P
           (Unknown unicast flooding)

Practical Examples:

Example 1: Known Unicast

Frame arrives on Port 1:
  Source: AA:AA:AA:AA:AA:AA
  Destination: BB:BB:BB:BB:BB:BB

Forwarding Table:
  | BB:BB:BB:BB:BB:BB | Port 2 |

Decision: FORWARD to Port 2 only
Result: Port 2 receives frame; Ports 3, 4, ... do not

Example 2: Same-Segment Traffic (Filtering)

Frame arrives on Port 1:
  Source: AA:AA:AA:AA:AA:AA
  Destination: CC:CC:CC:CC:CC:CC

Forwarding Table:
  | CC:CC:CC:CC:CC:CC | Port 1 |

Decision: FILTER (drop the frame)
Result: No ports receive forwarded frame
Reason: Source and destination are on the same segment

Example 3: Unknown Destination

Frame arrives on Port 1:
  Source: AA:AA:AA:AA:AA:AA
  Destination: DD:DD:DD:DD:DD:DD

Forwarding Table:
  | DD:DD:DD:DD:DD:DD | (not found) |

Decision: FLOOD to all ports except Port 1
Result: Ports 2, 3, 4, ... all receive the frame
Reason: Bridge doesn't know where DD:DD:DD:DD:DD:DD is located

Example 4: Broadcast

Frame arrives on Port 2:
  Source: BB:BB:BB:BB:BB:BB
  Destination: FF:FF:FF:FF:FF:FF (broadcast)

Decision: FLOOD to all ports except Port 2
Result: Ports 1, 3, 4, ... all receive the frame
Reason: Broadcasts must reach all devices

Network topology is not static. Devices are added, removed, moved between ports, and powered off. The bridge's forwarding table must adapt to these changes automatically. The aging mechanism ensures stale entries are removed, keeping the table accurate.

The Aging Process:

Each forwarding table entry has an associated age timer:

1. Entry Creation: When a MAC address is first learned, its age is set to 0
2. Age Increment: All entries age continuously (typically measured in seconds)
3. Age Reset: When a frame with this source MAC arrives, the age resets to 0
4. Age Expiration: When an entry reaches the maximum age (default: 300 seconds / 5 minutes in most implementations), it is removed from the table

Why Aging is Necessary:

Aging Timer Tuning:

The default 300-second aging time balances two competing concerns:

Typical recommendations:

• Stable networks: 300-600 seconds (default is usually fine)
• Mobile environments (laptops, wireless): 60-120 seconds
• Data center (servers rarely move): 300-1800 seconds

Static Entries:

Network administrators can create static entries that never age:

Static Entry: 00:11:22:33:44:55 → Port 2 (never ages)

Use cases:
- Critical servers that must always be reachable
- Security: static entry for known legitimate devices
- Special handling for specific MAC addresses

Static entries override dynamic entries and prevent learning-based updates. This provides guaranteed forwarding behavior but requires manual maintenance.

The bridge's most significant contribution to network performance is collision domain segmentation. Each bridge port creates an independent collision domain, allowing simultaneous transmissions on different segments without interference.

Understanding Collision domain Segmentation:

     Without Bridge (Hub-based network)           With Bridge
     ─────────────────────────────────           ───────────

           ┌─────────────────────┐              Segment A    Segment B
           │     Single Hub      │              (Port 1)     (Port 2)
           └─┬───┬───┬───┬───┬───┘                 │            │
             │   │   │   │   │                     │  ┌──────┐  │
            A1  A2  A3  B1  B2  B3                 │  │Bridge│  │
                                                   │  └──┬───┘  │
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━               │     │      │
        All 6 devices in ONE collision         ┌──┴──┐  │  ┌───┴───┐
        domain. If A1 and B2 transmit          │ Hub │  │  │  Hub  │
        simultaneously → COLLISION             └┬─┬─┬┘  │  └┬──┬──┬┘
                                                │ │ │      │  │  │
                                               A1 A2 A3   B1 B2 B3
                                                
                                               ━━━━━━━━   ━━━━━━━━
                                               Collision  Collision
                                               Domain 1   Domain 2
                                               
                                               A1 and B1 can transmit
                                               SIMULTANEOUSLY!

Performance Impact of Segmentation:

Consider a network with 6 devices, each generating 2 Mbps of traffic:

Without Bridge (single 10 Mbps collision domain):

• Total offered load: 6 × 2 Mbps = 12 Mbps
• Available bandwidth: 10 Mbps (shared)
• Utilization: 120% → Severe congestion and collision storms
• Result: Network is unusable

With Bridge (two segments, each with 3 devices):

• Segment A offered load: 3 × 2 Mbps = 6 Mbps
• Segment B offered load: 3 × 2 Mbps = 6 Mbps
• Each segment has 10 Mbps available
• Utilization per segment: 60% → Acceptable performance

But it gets even better: If most traffic is local (A1↔A2, B1↔B2), the bridge filters this traffic. Cross-segment traffic might be only 2 Mbps total:

• Traffic crossing bridge: 2 Mbps
• Local Segment A traffic: 4 Mbps (never crosses bridge)
• Local Segment B traffic: 4 Mbps (never crosses bridge)

Each segment operates independently with comfortable utilization, and the bridge handles only the inter-segment traffic.

Aggregate Bandwidth Enhancement:

*Aggregate capacity assumes no single conversation needs to exceed the bottleneck link (bridge inter-port) bandwidth.

This is why microsegmentation—connecting each device to its own bridge/switch port—became the standard practice. The evolution toward per-device switching maximizes aggregate bandwidth and eliminates collisions entirely.

Bridges evolved into several types to address different network requirements. Understanding these variations illuminates the path from early bridges to modern switches.

Transparent Bridges:

The most common type, transparent bridges operate invisibly to end devices:

• No configuration required on connected hosts
• Automatic MAC learning and aging
• Forward decisions based solely on MAC addresses
• Defined by IEEE 802.1D standard

Transparent bridges are the direct ancestors of modern Ethernet switches.

Source-Route Bridges:

Used primarily in IBM Token Ring networks, source-route bridges required hosts to determine the path through the network:

• Source device includes routing information in frame header
• Bridges follow explicit path instructions, not MAC lookups
• Required specialized discovery protocols (Routing Information Field or RIF)
• Largely obsolete with Token Ring's decline**

Translational Bridges:

These bridges connected networks using different Layer 2 protocols:

• Ethernet ↔ Token Ring translation
• Ethernet ↔ FDDI translation
• Required frame format conversion and address translation
• Complex, expensive, and largely replaced by routers or protocol standardization

Forwarding Methods:

Store-and-Forward:

• Receives complete frame before forwarding
• CRC validation ensures no corrupted frame propagation
• Higher latency (entire frame time + processing)
• Best for reliability and mixed-speed connections

Cut-Through:

• Begins forwarding after reading destination MAC (first 14 bytes)
• Lowest latency (microseconds)
• Cannot validate CRC; corrupted frames propagate
• Best for latency-sensitive applications with reliable networks

Fragment-Free (Modified Cut-Through):

• Waits for first 64 bytes (minimum frame size + collision window)
• Catches runts and collision fragments
• Compromise between latency and error filtering
• Common in early switches

Adaptive:

• Dynamically switches between store-and-forward and cut-through
• Uses store-and-forward when error rate is high
• Returns to cut-through when network is clean
• Provides optimal performance across conditions

While bridges represented a fundamental advance over hubs, they carried limitations that drove further development. Understanding these limitations explains the evolution to modern switches.

Port Density Limitations:

Early bridges typically had only 2-4 ports:

• 2-port bridges connected two segments (classic use case)
• Higher port counts were expensive and computationally demanding
• Large networks required cascading multiple bridges

The desire for higher port density drove switch development—essentially multi-port bridges with optimized hardware.

Processing Performance:

Software-based forwarding in early bridges created bottlenecks:

• General-purpose CPUs performed table lookups
• Frame buffering consumed available memory
• Forwarding rate was limited by CPU speed

Modern switches use ASICs (Application-Specific Integrated Circuits) for wire-speed forwarding.

Broadcast Domain Persistence:

As discussed, bridges do not segment broadcast domains:

• Large bridged networks experience broadcast flooding
• Broadcast storms propagate through all segments
• No isolation between logical workgroups

Evolution to Switches:

The network switch emerged as the hybrid successor to bridges and hubs:

The term 'switch' emerged to differentiate high-performance, high-port-count devices from traditional bridges. Technically, switches ARE bridges—they perform the same Layer 2 forwarding based on MAC addresses. The distinction is commercial and performance-based, not architectural.

Modern switches are multi-port bridges with:

• Hardware-based forwarding at wire speed
• Millisecond or microsecond latency
• VLAN support for logical segmentation
• Quality of Service (QoS) for traffic prioritization
• Management and monitoring features
• Stacking and high-availability capabilities

We have thoroughly explored the network bridge—the first Layer 2 device and the conceptual foundation for all modern switch technology. Let's consolidate the key concepts:

Looking Ahead:

The bridge established the foundational concepts of Layer 2 networking: MAC learning, selective forwarding, and collision domain segmentation. The next page explores the switch—the commercial and technical evolution of the bridge that dominates modern networks. We'll examine hardware architectures, VLAN capabilities, and why switches completely replaced both hubs and traditional bridges.