A Linux network bridge isn’t just a virtual switch; it’s a full-fledged Layer 2 device that allows multiple network interfaces to act as if they were plugged into the same physical switch, forwarding traffic based on MAC addresses.
Let’s see it in action. Imagine you have a host running KVM virtual machines, and you want them to be on the same subnet as your physical network. You can create a bridge, add your physical interface (say, eth0) to it, and then add your virtual interfaces (like vnet0, vnet1) to the same bridge.
Here’s how you’d set it up using iproute2:
First, create the bridge interface:
sudo ip link add br0 type bridge
sudo ip link set br0 up
This creates a new virtual network interface named br0 and brings it online. br0 is now ready to accept other interfaces.
Next, add your physical interface to the bridge. We’ll detach eth0 from its current IP configuration (if any) and attach it to br0.
sudo ip link set eth0 master br0
sudo ip link set eth0 up
Now, eth0 is no longer directly handling IP traffic; it’s just a port on br0. Traffic arriving on eth0 will be processed by the bridge.
If you have virtual interfaces, say vnet0 for a VM, you’d add it similarly:
sudo ip link add vnet0 type veth peer name veth0
sudo ip link set veth0 master br0
sudo ip link set veth0 up
sudo ip link set vnet0 up
This creates a pair of virtual Ethernet devices (veth0 and vnet0). veth0 is connected to the bridge br0, and vnet0 would be connected to your virtual machine’s network stack.
Finally, assign an IP address to the bridge interface itself, not the individual ports attached to it:
sudo ip addr add 192.168.1.100/24 dev br0
Now, any traffic destined for 192.168.1.100 will be handled by the br0 interface. The bridge will learn the MAC addresses of devices connected to its ports (including the physical eth0 and virtual veth0) and forward frames accordingly.
The core problem a bridge solves is creating a unified network segment from disparate physical and virtual interfaces. Without it, your VMs would typically be isolated on their own private networks or require complex NAT configurations to reach the outside world. The bridge effectively makes the host a silent participant in the network, extending the existing LAN to include your virtual machines.
Internally, the bridge operates by maintaining a MAC address table, similar to a physical switch. When a frame arrives on one of its ports, the bridge inspects the source MAC address and adds an entry to its table mapping that MAC to the incoming port. It then looks at the destination MAC address. If the destination MAC is known and associated with a different port, the frame is forwarded only to that port. If the destination MAC is unknown, or if it’s the same as the source MAC, the frame is flooded to all ports (except the one it arrived on).
You control the bridge’s behavior through various options. For instance, stp (Spanning Tree Protocol) is enabled by default on Linux bridges. This is crucial for preventing network loops if you have multiple paths between devices. You can disable it if you’re certain there are no loops, but it’s generally a good idea to keep it on. To check its status:
sudo brctl showstp br0
And to disable it (not recommended for complex setups):
sudo brctl stp br0 off
Another important parameter is forward-delay. This is part of STP and dictates how long a port stays in a listening state before transitioning to forwarding. You can adjust it, though default values are usually fine.
The bridge also handles VLAN tagging. If you have VLANs configured on your physical network and your eth0 interface, you can configure the bridge to be VLAN-aware. This allows you to assign different VLAN tags to traffic going out of different ports on the bridge, effectively segmenting your network traffic at Layer 2. For example, a VLAN-aware bridge can be configured to tag traffic from a specific VM port with a particular VLAN ID, ensuring it adheres to your network’s VLAN policies.
When you add an interface to a bridge, that interface loses its own IP address and MAC address for routing purposes. The bridge interface br0 then takes on the primary IP and MAC address for that segment. This means ARP requests for the bridge’s IP address will be answered by the bridge, and it will manage the MAC address table for all connected interfaces.
The most surprising true thing about Linux network bridges is how seamlessly they integrate with existing network infrastructure, often without requiring any changes on external switches. When you add a physical interface like eth0 to br0, the external switch sees br0 (which is using eth0’s MAC address) as just another device on the network. The switch doesn’t "know" about the virtual interfaces connected to br0 behind the host; it only sees the bridge’s MAC address and forwards traffic to eth0 as it normally would.
The next concept you’ll likely explore is how to manage multiple bridges or how to bridge interfaces that are themselves VLAN-tagged.