Bridge

This guide will explore the bridging concept, how to configure Gentoo as an IEEE 802.1d compatible bridge and some related arguments.

Bridge basis
A bridge is used to connect two collision domains to form a single coherent broadcast domain. Ethernet operates under a principle called CSMA/CD (Carrier Sense Multiple Access / Collision Detection). In simplistic terms, any Ethernet host "listens" to the network when it wants to transmit. It waits until it believes the network is unused (Carrier Sense Multiple Access) and then sends the data.

Because data is not transmitted instantaneously (there is actually a small amount of delay), there exists the potential that two Ethernet hosts send data at the same time. When that happens, it is as if two people talk at once: neither can really understand what the other is saying. This is called a collision in the domain of networking technology. So an Ethernet host continues to listen to the network while it transmits its data. If it doesn't hear what it originally sent, it assumes a collision occured (Collision Detection). It will stop transmitting for some variable amount of time and then start the whole process over again.

The more hosts you have on a given network segment, the greater the chance of a collision occuring. A network segment can be subdivided to decrease the number of hosts that are on a segment together. That is, I can have a LAN that looks like either of the following diagrams. Both operate the same, but the first is a single collision domain, the second has two collision domains.

|                   |                  |            Host A               Host B             Host C

--[BRIDGE]-- |                   |                  |            Host A               Host B             Host C

In the first example, if A and C talk at the same time, a collision occurs. In the second, A and C can talk at the same time without having to worry about their data colliding &mdash; the bridge assumes the role of minimizing collisions! (Note that in the second example, B and C can still create collisions together.)

Ethernet also has this property called a "broadcast." If you know you want to talk to a host on the network, but you're not quite sure WHICH host you want to talk to &mdash; or maybe you want to talk to all of them with the same message &mdash; then you broadcast the message on the network. Broadcasts must be transmitted across collision domains. In the second example from above, if A sends a broadcast, both B and C hear it. Also, if B sends a broadcast, both A and C hear it. But if B sends a message to C, A will not hear it. That is the difference between a broadcast domain (the logical network) and a collision domain (the physical network).

Advanced bridging
Now that we understand the basics about bridging, let's look at a more complex example:

Host A --+---+- Host B                     |                   | |                  |       Interface 0 ++         ++                 |  Br 1  |          |  Br 2  | ++         ++                      |                   |       Interface 1 |                  |         Host C --+---+- Host D

Hosts A and B are on one network segment, and Hosts C and D are on a different segment. The two segments are connected via two bridges, Br1 and Br2, via Interfaces 0 and 1, respectively. (That is, Interface 0 on Br1 and Br2 points to the Host A/B segment, and Interface 1 points to the Host C/D segment.)

Let's say Host A sends a Layer 2 ARP packet (a broadcast) looking for the address of Host D. Both Br1 and Br2 receive the broadcast packet via Interface 0. Since it is a broadcast, the bridges flood it out every other interface, so Host D receives two copies of the packet from the bridges. It responds using a unicast packet, and the bridges forward the data properly. But something bad has just happened.

When Br1 flooded the broadcast to the wire, Br2 received the packet on Interface 1. (And likewise for Br1 receiving it from Br2.) Since the bridges interpret the packet as "new," they forward the packets out to Interface 0. Wait a second... the broadcast was already heard on that segment when Host A originally sent it! This loop continues again, where Br1 and Br2 keep forwarding the broadcast from interface to interface like a giant perpetual motion machine. The broadcast packets start eating up all of the available time slices when a host can transmit, causing a denial of service attack. This is not a good thing and is called a broadcast storm.

When Host D responds with that unicast packet, another troublesome event takes place. Br1 and Br2 know Host A can be found on Interface 0. They learn from the response that Host D can be found on Interface 1. Both bridges receive the response, and both forward it back out Interface 0 to Host A. When Br1 sends it, Br2 receives it; and vice versa.

Since a bridge learns which port a host is on by the source MAC address, they can get confused when they hear the same source MAC on two different interfaces. Br1 and Br2 learned that Host D is on Interface 1 from the response ... but now they think that Host D is on Interface 0 instead because their forwards got confused! Just like in the broadcast storm example that got us started, the bridges continue forwarding these packets ad infinitum, relearning their bridge forwarding tables on every packet. And thus the unicast flood is born.

Now, these problems do not exist when a single bridge is involved. It is only when two or more segments are interconnected by two or more bridges. But as we can see, they are very important to discuss. Broadcast storms are infamously known for crashing entire networks. So how do we combat this?

The answer is known as the Spanning Tree Protocol (STP). It acts as a type of routing protocol for bridges, telling them to turn off certain ports that may cause potential loops. The details of STP are well beyond the scope of this document, but I highly suggest reading Michael Norton's article Understanding Spanning Tree Protocol - the Fundamental Bridging Algorithm as an introduction to STP.

Now we are ready to begin building our bridge.

Kernel
Like many other things in the Layer 2 realm, 802.1d support requires an addition to the kernel. Thankfully, the 2.4 and 2.6 kernels have included this support &mdash; we just need to make sure it gets compiled.

Program support
Thanks to the magic of portage, installing the programs to control bridging is easy. Install as follow:

A short time later, will be installed and ready to go. The only thing left to do is figure out how to use the program. brctl overview

Manually Creating a Bridge Interface
Let's say I want to create Br1 from our previous example. Let's name it. and will be the interfaces used. Linux requires that we create a new bridge interface that is a summation of the two real interfaces, so let's go ahead and do that: Manual Bridge Creation This tells to create an interface  and then to assign  and  to it. And with those three commands, we have a fully functional bridge. The rest is just tweaking.

By default, STP is disabled under Linux bridging. Let's go ahead and enable this for safe measure: Enable STP Ah, now Br1 is really working well. We don't need to worry about broadcast storms or unicast floods on this bridge anymore.

The only thing lacking is remote administration of the Linux box. and are in promiscuous mode to be part of the bridge, so how do we SSH into it? The answer: we assign the bridge interface itself an IP address. Assign the Bridge Interface The only thing more perfect would be if we could somehow script all this into an init script.

Gentoo Init Scripts
Thanks to the kind developers over the baselayout scripts, we no longer have to patch the init scripts. Also, it seems you no longer have to start the bridging software as a separate process. It gets fairly simple from here.

Our first step is to modify to add the bridge configuration. If you look at you'll notice a sample configuration you can use as a template. You'll notice the syntax is similar to the syntax for configuing individual interfaces specifically.

Note that for any interfaces that are to be in the bridge, they need to be set to "null." Unexpected results may occur if these ports get configured with an IP. Hence, configure the individual ethernet ports like so:

To access the network through add to :

If you have multiple bridges on the network, you'll probably want to turn on STP (discussed above, shown below). You can use similar syntax for other commands:

On the other hand, if you are really sure to configure one bridge on the network, you can turn off STP and avoid the preparatory delay recommended by STP itself:

Next, create the symbolic links for the extra interface and for init scripts and add them to the default runlevel: Symbolic links & default runlevel

Bridging With VLANs
A VLAN is a «is a group of hosts with a common set of requirements that communicate as if they were attached to the same broadcast domain». It is normally managed by extra frame headers defined in the IEEE 802.1Q standard.

To have a VLAN you need at least the following kernel configuration:

You will need also the userspace utilities :

To learn the basics of VLANs OpenWRT provide the simple Understanding Network Interfaces about.

802.1d and 802.1Q can combine seamlessly under a Linux system. Unfortunately, Gentoo does not make configuration easy on us. Using Bash variables, we cannot easily create a device-specific VLAN and specify configuration parameters. To do this, we would need to be able to create a "config_eth0.2" directive in /etc/conf.d/net, which violates the variable rules for Bash. We can, however, circumvent the problem entirely using the vconfig name-type parameter 'VLAN_PLUS_VID_NO_PAD'. Unfortunately, if the same VLAN is used on two interfaces, this method will not work without a helper function to rename the VLAN to something unique on a per-interface basis. Using the function provided by Gentoo, we can issue a series of commands that performs this renaming for us.

As you can see, the basics of bridging with VLAN support is already present. The only problem we have to circumvent is the Bash variable naming problem. Gentoo provides adequate capabilities to do this. Our last step is to create the init.d scripts and add them to the default runlevel: Create and manage initscripts Now we can start our bridged interfaces: Start the Bridged Interfaces The bridged interfaces require all VLAN interfaces to start first. If you fail to start your VLAN interfaces before starting a bridged interface, the VLAN interfaces will fail to start. You can start your bridged interfaces in any order, just so long as all VLAN interfaces (e0v2, e1v2, etc) have been started prior to starting a bridged interface.

Creating 802.11/802.3 Bridges
Quite simply, Linux does not support this easily. From Jean Tourrilhes' site : The conventional Ethernet bridging method (promiscuous sniffing) doesn't work with most wireless LAN standard, because of the header encapsulation and the interactions with link layer retransmissions. In other word, most often, when you use a software bridge on a wireless LAN (such as the Linux bridge on a 802.11 card), it doesn't work (moreover, quite often promiscuous is broken as well).

The driver could work around this restriction by creating its own MAC headers (802.11 headers instead of 802.3, and putting the right bits in the right place), but in fact most vendors don't provide the specification on how to this with their hardware (when they don't explicitly prevent it in hardware, to force you to buy their Access Points). The eventual goal is to bridge a wireless network to a wired network. This is what an access point provides so if you can, buy an access point instead of trying to build your own. If you need it to bridge a virtual machine to your wireless network, you are going to be pretty out of luck for the time being.

Bridge & iptables
You can filter bridged traffic with iptables, to do that you have to enable following kernel option:

If you want to disable this feature on-the-fly without recompiling the kernel, you can tune the behavior with :

Conclusion
While Gentoo has enjoyed lots of attention in the matters of 802.1q VLANs and Layer 3 routers/firewalls, bridging support is has been relatively ignored. Hopefully, this document has remedied some of that.

A Linux bridge can be used in the special case of a transparent proxy server. Read Chapter 7 in the Transparent Proxy with Linux and Squid mini-HOWTO by Daniel Kiracofe. Otherwise, specialized hardware could be preferred.

You can use 802.1d in combination with other features like Linux 802.1q VLANs, firewalling, Linux Channel Bonding, and Squid for a flexible and complete solution in any network. Start with the basics and expand outwards.