A network bridge is a device which connects network segments at the second layer of the OSI model, the datalink layer, and a transparent ethernet bridge does just that – it sits in-line on an ethernet network between 2 network segments.  It’s referred to as a transparent bridge because it has no addresses – it simply accepts and forwards traffic as if it weren’t there.  There are many reasons that a person might want to install an ethernet bridge ranging from QoS and traffic shaping to packet inspection and processing.  We’re going to focus primarily on setting up the ethernet bridge and not go too much into filtering and QoS, but using an application like iptables or ebtables can allow for packet inspection and blocking or forwarding traffic.  I’ve used this as an in-line firewall for preventing access to certain network resources and to limit bandwidth consumption on simple networks.

This requires a single machine with 2 NICs to function as your ethernet bridge.  For something this simple you don’t need a very powerful machine – my first ethernet bridge was armed with 2 half duplex NICs, a Pentium II 500 MHz processor, 64 Mb of PC100 RAM and a 1.8 Gig harddrive.  Unfortunately I no longer own a machine that weak so I had to perform this on a machine with an AMD Athlon 1.2 GHz processor, 512 Mb of RAM, dual 10/100 NICs and a 20 Gig drive.

I am once again using Debian Linux as my environment of choice but I’ve sucessfully tested this on several Fedora and Gentoo distributions as well.  I wouldn’t be surprised to learn that the bridging package is universally available.  At any rate you’re going to want to start with a minimal installation and add packages as necessity dictates – my footprint was just shy of 450 Megabytes when I was finished with the install.  You’ll also want to issue the “ifconfig -a” command to verify that both your NICs were detected properly.  Because troubleshooting a device driver is a little beyond where I’d like to take this project we’re going to assume, for the sake of convenience (mine, mostly) that both your NICs are there and we’re ready to rock and roll.

A note:  after my very basic install the brctl binary was present on my system but it may not be on yours.  On Debian you can ensure this is installed using “apt-get install bridge-utils” and on Fedora/Redhat/CentOS this is done using “yum install bridge-utils”

The next task is to create the bridging device as a virtual interface.  I’m going to call mine bridge0, but you could use nearly anything though I suggest using something intuitive like any of the following:

bridge, br0, br1, brdg0

You want to name this in a way that doesn’t leave much room for confusion.  Let’s look at mine:

EthernetBridge> brctl addbr bridge0

You’ve just created the virtual interface for bridging called “bridge0″

Moving on we want to adhere to the transparent moniker and assign no IP addresses to this machine.  Many would argue that you need IPs if you want to run services like telnet and SSH or NFS, FTP, etc and I would say that if you want to run those services you will absolutely need IPs.  However, this is going to be a specialized installation with no IPs and there will not be a remote management capability.  What you need to do to adhere to this is configure the interfaces to acquire their addresses statically and not via the DHCP service – although it wouldn’t be the end of the world if they had IPs we want this to be simple so on your machine configure NICs statically with no IP, netmask, gateway or other addresses.  Then we need to add these interfaces, which I’ll be calling eth0 and eth1, to the bridge:

EthernetBridge> brctl addif bridge0 eth0 && brctl addif bridgeo eth1 && ip link set bridge0 up

dissecting the chain of command I first add eth0 to the bridge0 virtual interface and, assuming no errors occur, this will then execute the same command to add eth1 to the bridge0 interface and finally “ip link set bridge0 up” activates the bridge0 interface.

At this point your bridge should be functioning in essence as an Ethernet hub and will relay traffic coming into either eth0 or eth1 out the other interface.  If you wanted to filter out certain ports or IPs/IP ranges you could setup iptables or some other firewalling application to do so.  You could also use a similar means to configure all manner of QoS or stateful packet inspection.  If you want this to be a truly transparent bridge you can stop now.    You my also want to note that my installation of Debian automatically compiled with support for IP port forwarding and yours may not have.  You should also note that when I executed the brctl command spanning-tree was off by default, thouh I have seen this enabled in the past.  You disable using “brctl stp off” and you can verify that things are up and running using the brctl command like so:

EthernetBridge> brctl show

this command will return the bridges available, their unique numeric ID, whether or not Spanning-tree (STP) is enabled for the interface, and the interfaces which are members of the bridge interface which should say eth0 and eth1.

Now, barring a reboot, your ethernet bridge should function just fine to pass traffic and really rather quickly.  If you want to be able to survive a reboot you can write yourself a little script to run during the reboot process that looks like this:

#!/bin/bash

brctl addbr bridge0 && brctl addif bridge0 eth1 && brctl addif bridge0 eth1 && ip link set bridge0 up

Quick.  Dirty.  Effective.  However, if you want to do some other things read on…

Let’s add an IP address to the bridge0 interface:

EthernetBridge> ip addr add 192.168.0.253/24  brd + dev bridge0

this command assigns the IP 192.168.0.253 with netmask 255.255.255.0 to bridge0.  In addition to assigning an IP and netmask to the bridge0 interface we need to assign a default route which can be done like so:

EthernetBridge> route add default gw 192.168.0.1 dev bridge0

the above command sets the default gateway to 192.168.0.1 for device bridge0.  If you are connecting several segments together using this mechanism you’ll have to set be sure to assign unique IPs to each bridge interface.

Of course you’d want to add those last commands to the bash script we’re going to run at startup as well as probably configure some iptables rules.  I’m not going to provide an iptables tutorial though, not today anyway, but rest assured that any packet matching those rules will be processed as specified.