In this article I’ll discuss network bridges and where they are commonly used (spoiler: they aren’t any more). Mainly though I want to discuss how bridges are used in an OpenStack set up as building a personal cloud is my final aim. Hardware network bridges aren’t as common as they once were as switches have largely replaced hubs in the network so there’s no problem with large collision domains. 

Simply put, a bridge is a layer two device that is used to join two (Ethernet) networks together to form a single larger network. Why is this useful? Imagine a business spread across two different sites each with it’s own LAN. Without an interconnection between the two networks machines on one LAN couldn’t communicate with machines on the other. This can be fixed by installing a bridge between the two sites which will forward packets from one LAN to the other effectively making the two LANs into one large network.

Notice that in the example I didn’t state how geographically close the two sites were as it doesn’t matter from theoretical perspective. If the sites are quite close, say for example within the transmission distance of Ethernet, then standard networking equipment may be able to act as the bridge. If the transmission is further a dedicated fibre optic of microwave link may be used to form the bridge for example. The key point is that once the two networks are bridged they appear as a single network.

Bridges may or may not learn about the hosts connected to the networks they are bridging. A basic transparent bridge will just pass all packets arriving on it’s input port out the output port(s). This strategy is simple but it can be very wasteful and potentially expensive if the bridge link is charged on the amount of data that passes across it. A better solution is to use a learning bridge that will learn the MAC addresses of hosts on each connected network and only put packets on the bridge when the required. Note that in many respects a learning bridge is much like a regular Ethernet switch which is why bridges as a piece of real hardware have all but disappeared.

Bridge Utilities

In the modern network switches have largely made bridges obsolete but the concept of the bridge is still very useful in the virtual world. By installing the package “bridge-utils” on any mainstream Linux machine the you get the ability to create virtual bridges with commands such as:

brctl addbr br0

This would create a virtual bridge called “br0”. You can then add interfaces to the bridge like this:

brctl addif br0 eth0
brctl addif br0 eth1

This adds two Ethernet ports “eth0” and “eth1” to the bridge. If these are physical ports then this set up has linked the two networks connected to these ports at layer two and packets will flow between them. Linux has built in support for filtering the packets passing across the bridge using the user space tool “ebtables” (Ethernet bridge tables) which is similar to “iptables”.

You can see the configuration of virtual bridges using the command:

brctl show

Finally you can remove an interface and delete a bridge like this:

brctl delif br0 eth0
brctl delbr br0

Iproute2 Bridges

The examples above use the brctl command from the bridge-utils package but that has now been superseded by the newer iproute2 utility which can also create bridges. To create a bridge with iproute2 use the following command:

ip link add br0 type bridge
ip link show

The second show command just displays the link information which you can use to confirm the bridge has been created. To add an interface to the bridge (know as enslaving it) use a command like this:

ip link set ep1 master br0

This adds the interface ep1 to the bridge br0 (the interfaces ep1 and ep2 are just a veth pair that I’ve created for testing, I’ll discuss veth pairs in another article). The output of and ip link show command would now look something like this:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
 link/ether 08:00:27:4a:5e:e1 brd ff:ff:ff:ff:ff:ff
4: ep2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
 link/ether fa:d3:ce:c3:da:ad brd ff:ff:ff:ff:ff:ff
5: ep1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master br0 state DOWN mode DEFAULT group default qlen 1000
 link/ether e6:80:a3:19:2c:10 brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
 link/ether e6:80:a3:19:2c:10 brd ff:ff:ff:ff:ff:ff

Notice that the ep1 interface shows br0 as it’s master. To then remove or release the ep1 interface from the bridge:

ip link set ep1 nomaster

And finally to delete the bridge:

ip link delete br0

So the obvious question at this point is so what? Bridging two physical ports like this is interesting but physical bridges didn’t die out because they were useful! Where this starts to get interesting is when you learn that Linux supports the creation of virtual ports (TUN/TAP devices) which can also be added to the bridge. This means that a single machine hosting multiple virtual machines can give each one it’s own virtual network port which can be connected to and controlled with a virtual switch device. In fact it doesn’t stop there, it’s possible to create virtual VLANs (they are very virtual) and link together multiple virtual switches. More on this in another article on Open vSwitch though I think.