What Is a Network Bridge?

Early Ethernet networks had a noise problem. Every device shared the same wire, which meant every packet reached every device. Your computer heard your neighbor's file transfer and your printer's status updates and the server's backup traffic—all of it, all the time. The more devices you added, the more crowded the conversation became.

A network bridge creates quiet rooms within the chaos. It connects two network segments, watches the traffic flowing through, and makes a simple but powerful decision for each packet: does this actually need to cross, or can it stay local?

How a Bridge Thinks

Imagine two office areas, each with its own cluster of computers. People in the east wing mostly talk to each other. People in the west wing mostly talk to each other. But occasionally, someone in the east needs to reach someone in the west.

A hub connecting everyone would force all traffic through one loud room. A bridge connecting the two wings does something smarter: it learns who lives where, then only passes messages across when they're actually addressed to the other side.

The bridge doesn't know where devices are when it starts. It learns by eavesdropping—watching the return addresses on every frame that passes through, building its map of who lives where. When a frame arrives from the east wing with source address AA:BB:CC:DD:EE:FF, the bridge notes: "This device is reachable through my east port."

Now when a frame arrives destined for that address, the bridge knows exactly where to send it. If the frame came from the east wing and is destined for the east wing, the bridge does nothing—that conversation can stay local. If it came from the west wing, the bridge forwards it east. This filtering is the bridge's superpower.

The Forwarding Table

The bridge maintains a forwarding table—a map of MAC addresses to ports. This table grows as traffic flows:

The "last seen" timer matters. If a device hasn't sent traffic recently, the bridge eventually forgets about it. This aging mechanism lets the network adapt—when someone unplugs their laptop from the east wing and plugs it into the west wing, the old entry expires and a new one forms.

For unknown destinations (addresses not yet in the table), the bridge has no choice but to forward the frame everywhere except where it came from. This flooding ensures the frame reaches its destination while the bridge learns where that destination actually is.

What Makes This Different from a Hub

A hub is a crowded room where everyone shouts. A bridge puts up a wall with a door—conversations stay local unless someone specifically needs to cross.

This distinction matters for performance:

With a hub: Every frame reaches every device. Ten devices sending simultaneously create chaos—collisions, retransmissions, wasted bandwidth.

With a bridge: Local traffic stays local. The east wing can have its own conversation while the west wing has its own. Only cross-wing traffic competes for the bridge's attention.

Bridges operate at Layer 2—the Data Link layer—making decisions based on MAC addresses. They don't understand IP addresses or anything above Layer 2. They just know "this frame needs to reach this physical address" and figure out which direction to send it.

From Bridges to Switches

Here's where the terminology gets confusing: switches are just bridges with more ports.

A traditional bridge might have two or four ports, connecting two or four network segments. Network engineers started asking: what if we gave every device its own segment? What if a 24-port device was really 24 separate collision domains, intelligently connected?

That's a switch. Every port is its own segment. When your computer sends a frame, it doesn't compete with anyone else—it has a private conversation with the switch, which then forwards the frame only to the specific port where the destination lives.

The underlying logic is identical to bridging: learn MAC addresses, build a forwarding table, filter local traffic, forward only what needs to move. Switches just extend this to many ports with hardware optimized for speed.

Today, "bridge" typically describes specific use cases—connecting distinct network segments, wireless links between buildings, software-defined networking—while "switch" describes the infrastructure devices that connect end devices.

When Bridges Create Loops

Redundancy is good. If one path fails, traffic can take another. But bridges and redundancy create a dangerous problem: loops.

Imagine two bridges connecting the same two segments. A broadcast frame arrives at Bridge A, which forwards it to the other segment. Bridge B sees this frame and forwards it back. Bridge A sees it again and forwards it again. The frame circulates forever, multiplying with each broadcast, until the network drowns in traffic.

Spanning Tree Protocol (STP) solves this. Bridges exchange special messages to detect loops and agree on which paths to use. Redundant paths get blocked—they stay ready to activate if the primary path fails, but they don't forward traffic. The result is a loop-free tree of active paths with backup paths standing by.

STP is essential whenever you have redundant bridge or switch connections. Modern variants like Rapid STP (RSTP) recover from failures in seconds rather than the 30-50 seconds of original STP.

Bridges in Software

Bridges don't have to be physical devices. Your operating system can bridge network interfaces:

Linux bridges let a computer with multiple network cards act as a bridge, forwarding traffic between them. The bridge utility creates and manages these.

Virtual machine bridges connect VMs to the physical network. The hypervisor creates a software bridge that connects virtual network interfaces to physical ones, making VMs appear as regular devices on the network.

Container bridges connect containers to each other and to the outside world. Docker's default bridge network is exactly this—a software bridge that containers attach to, with the host forwarding traffic between the bridge and the physical network.

Software bridges trade performance for flexibility. You can create them instantly, reconfigure them on the fly, and destroy them when done. For most virtualization and container workloads, the performance is more than adequate.

Wireless Bridges

One of the most practical modern uses of bridge technology: connecting buildings without digging trenches for cables.

A wireless bridge pair acts exactly like a cable. Two directional antennas point at each other across a parking lot, a street, or even a few kilometers. Traffic enters one side, crosses the radio link, and exits the other side. From the network's perspective, it's just another cable—the wireless nature is invisible to protocols.

Point-to-point wireless bridges connect exactly two locations. Point-to-multipoint bridges connect a central site to several remote sites, useful for campus networks or connecting branch offices.

The same bridging logic applies: the wireless bridge learns which MAC addresses are on which side and forwards traffic accordingly. The only difference is the physical medium carrying the frames.

Limitations Worth Understanding

Bridges work at Layer 2, which means they have inherent limitations:

Broadcasts go everywhere. When a device sends a broadcast (like an ARP request asking "who has this IP?"), the bridge must forward it to all segments. Large bridged networks can drown in broadcast traffic.

One big subnet. Bridged segments share the same IP subnet. You can't use bridging to separate networks that need different IP address ranges.

No traffic filtering by content. Bridges make decisions based purely on MAC addresses. They can't block traffic based on IP addresses, ports, or application protocols. That requires a router or firewall.

Spanning Tree takes time. When topology changes (a link fails, a new bridge comes online), STP needs time to recalculate. During convergence, some paths may be temporarily unavailable.

For small to medium networks, these limitations rarely matter. For larger networks or those with security requirements, routers provide the segmentation and filtering that bridges cannot.

The Concept That Persists

The word "bridge" has faded from everyday networking vocabulary, absorbed into "switch" and hidden inside virtualization platforms. But the concept—learning where devices live, filtering traffic that doesn't need to cross boundaries, creating smaller collision domains within larger networks—remains the foundation of how local networks operate.

Every time your laptop sends a frame and only the destination device receives it, that's bridging logic at work. Every time a virtual machine talks to the physical network, a software bridge is making forwarding decisions. Every time two buildings communicate over a wireless link, bridge technology is treating radio waves like copper.

The devices have gotten faster. The ports have multiplied. The software has grown sophisticated. But the core insight—that networks work better when local conversations stay local—is as true now as when the first bridge split a noisy Ethernet in two.