# HOWTO: Building a Gentoo 802.1d Bridge

## gtsquirrel

The Gentoo 802.1d Bridge Guide

Author: Christopher Verges <squirrel@headnut.org>

Release Date: 24 Nov 2004

Introduction

As Gentoo seems to gain more popularity as a home-brewed server platform, extending it to act like different network devices is important.  In this guide, we will explore how to configure Gentoo as an IEEE 802.1d compatible bridge.

Intended Audience

This document is written for users with a working knowledge of networking.  Prerequisite knowledge includes those topics covered in the Gentoo Installation Guide and commands needed to edit common configuration files.

Kernel Support

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 -- we just need to make sure it gets compiled.

For simplicity, I am going to assume we start with a vanilla 2.6 kernel.  Edit the /usr/src/linux/.config file with the following changes:

```
To compile 802.1d support as a module:

CONFIG_BRIDGE=m

To compile 802.1d support into the kernel:

CONFIG_BRIDGE=y
```

Compiled the kernel and load the bridging code as necessary.  If you compile into the kernel, reboot.  If you opt to compile as a module, do not forget to add the module to your /etc/modules.autoload.d/kernel-2.6 file:

```
# echo "bridge" >> /etc/modules.autoload.d/kernel-2.6

# update-modules

# modprobe bridge
```

Use the dmesg command to ensure the 802.1d code was loaded successfully.  Once it is loaded without errors, continue to the next stage.

Program Support

Thanks to the magic of portage, installing the programs to control bridging is easy:

```
emerge net-misc/bridge-utils
```

About three minutes later, depending on the speed of your machine, brctl will be installed and ready to go.  The only thing left to do is figure out how to use the program.

```
# /sbin/brctl

commands:

       addbr           <bridge>                add bridge

       addif           <bridge> <device>       add interface to bridge

       delbr           <bridge>                delete bridge

       delif           <bridge> <device>       delete interface from bridge

       show                                    show a list of bridges

       showmacs        <bridge>                show a list of mac addrs

       showstp         <bridge>                show bridge stp info

       

       setageing       <bridge> <time>         set ageing time

       setbridgeprio   <bridge> <prio>         set bridge priority

       setfd           <bridge> <time>         set bridge forward delay

       setgcint        <bridge> <time>         set garbage collection interval

       sethello        <bridge> <time>         set hello time

       setmaxage       <bridge> <time>         set max message age

       setpathcost     <bridge> <port> <cost>  set path cost

       setportprio     <bridge> <port> <prio>  set port priority

       stp             <bridge> <state>        turn stp on/off
```

Bridge Basics

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 -- 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 -- or maybe you want to talk to all of them with the same message -- 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 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 inifitum, 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" (http://oreillynet.com/pub/a/network/2001/03/30/net_2nd_lang.html) as an introduction to STP.

Now we are ready to begin building our bridge.

Manually Creating a Bridge Interface

Let's say I want to create Br1 from our previous example.  eth0 and eth1 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:

```
# /sbin/ifconfig eth0 up

# /sbin/ifconfig eth1 up

# /sbin/brctl addbr br0

# /sbin/brctl addif br0 eth0

# /sbin/brctl addif br0 eth1

# /sbin/ifconfig br0 up
```

This tells brctl to create an interface br0 and then to assign eth0 and eth1 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:

```
# /sbin/brctl stp br0 on
```

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. eth0 and eth1 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.

```
# /sbin/ifconfig br0 192.168.1.2 netmask 255.255.255.0 up
```

The only thing more perfect would be if we could somehow script

all this into an init script.

Gentoo Init Scripts

Wouldn't you know it, someone already answered this question for us!  In fact, there are several solutions.  I posted one at https://forums.gentoo.org/viewtopic.php?p=730212.  There is another that was submitted to Gentoo for consideration as a baselayout patch at https://bugs.gentoo.org/show_bug.cgi?id=72392.  The net-misc/bridge-utils package comes with its own init script now, too.

We will be covering the net-misc/bridge-utils script and the patch I submitted since those have actual merit in a production environment.

When you install net-misc/bridge-utils, it creates a configuration file (/etc/conf.d/bridge) and an init script (/etc/init.d/bridge).  The syntax of the configuration file is relatively simplistic -- define the bridges and then define the interfaces for the bridges.

```
/etc/conf.d/bridge:

bridge="br0"

bridge_br0_devices="eth0 eth1"
```

Next, add the bridge init script to the default runlevel and start it up:

```
# rc-update add bridge default

# /etc/init.d/bridge start
```

And with that, our bridge will start upon system boot.  If you wanted to run more than one bridge on a Linux system, just define the bridges in the conf file.

```
/etc/conf.d/bridge:

bridge="br0 br1"

bridge_br0_devices="eth0 eth1"

bridge_br1_devices="eth2 eth3"
```

Now this is all fine and dandy, but I wondered why a separate bridge script was needed.  Since bridging is a networking function, it makes more sense for support to be included in the regular /etc/conf.d/net and /etc/init.d/net.* files.  That is where my series of patches come into play.  The first thing is to grab them from Bugzilla and apply them:

```
# cd /root

# wget -O net-conf.patch \

       "http://bugs.gentoo.org/attachment.cgi?id=44674&action=view"

# wget -O net-init.patch \

       "http://bugs.gentoo.org/attachment.cgi?id=44675&action=view"

# patch -u -b /etc/conf.d/net net-conf.patch

# patch -u -b /etc/init.d/net.eth0 net-init.patch
```

Not too difficult, but still tedious.  This will no longer be necessary if Gentoo decides to include the patches in their default baselayout scripts.  But that is not for me to decide. Until then, patching manually is the only solution.

The next step is to modify /etc/conf.d/net to add the bridge configuration.  You'll notice it is very similar to the regular syntax:

```
/etc/conf.d/net:

iface_eth0=""   # Tells ifconfig to bring up the interfaces

iface_eth1=""   # without assigning an IP address

iface_br0="192.168.1.1 netmask 255.255.255.0"

bridge_br0="eth0 eth1"
```

The final step is to create the symbolic link for the br0 init script and add it to the default runlevel:

```
# ln -sf /etc/init.d/net.eth0 /etc/init.d/net.eth1

# rc-update add net.eth0 default

# rc-update add net.eth1 default

# ln -sf /etc/init.d/net.eth0 /etc/init.d/net.br0

# rc-update add net.br0 default

# /etc/init.d/net.br0 start
```

Certainly both methods have strengths and weaknesses, so I provide both for you to choose from.  They are mutually exclusive, however -- only choose one and stick with it.

Creating 802.11/802.3 Bridges

Quite simply, Linux does not support this easily.  From Jean Tourrilhes' site:

 *Quote:*   

> 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 explicitely prevent it in hardware, to force you to buy their Access Points).  (http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.usage.html)

 

The eventual goal is to bridge a wireless network to a wired network.  Fortunately, this is exactly what an access point does.  There are several out there from which to choose.  If you have lots of money or need VLAN/QoS support, the Cisco Aironet 1100 and Aironet 1200 access points are a great investment.  If your budget is more of a requirement, the Linksys WAP54G or WRT54G are cheap and quite effective.  (The Linksys Cable/DSL "routers" can easily be turned into a regular access point via a single selection box in the configuration.)

So rather than trying to hack a Linux 802.11/802.3 bridge together, spend the $100 and save yourself a lot of headaches.

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.

I recommend using a Linux bridge 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 (http://tldp.org/HOWTO/TransparentProxy.html).  Otherwise, I generally prefer specialized hardware.  My flavor of choice is the Cisco Catalyst 2950, though just about any Layer 2 switch would handle the job.  (The Catalyst supports STP and VLANs along with remote management features.)

You can use 802.1d in combination with other features like Linux 802.1q VLANs, firewalling, Linux Channel Bonding (http://sourceforge.net/projects/bonding), and Squid for a flexible and complete solution in any network.  Start with the basics and expand outwards.

Update History:

18 Dec 2004 - Added information about bridging a wireless network and a wired network.24 Nov 2004 - Posted HOWTO to Gentoo forums.  Overwrote old guide.Last edited by gtsquirrel on Sun Dec 19, 2004 5:41 am; edited 5 times in total

----------

## curtis119

Nice tip. Are you still planning on writing a How-To?

----------

## gtsquirrel

As with most things, life has gotten in the way of it.   :Smile:   For a very simple bridge, the information in the original post will suffice.  If you want help with anything specific, feel free to e-mail me directly at squirrel@headnut.org and I will respond within 48 hours.

The HOWTO is on my to-do list, however.  I got caught up writing a book about monitoring hardware under Linux, so that takes precedence right now.

----------

## gtsquirrel

This thread seems to have generated some traffic lately, so I'm going to post some clarifications.  Here is a response to an e-mail asking about specific commands to run.

```
This is the basis of what I did:

    ln -sf /etc/init.d/net.eth0 /etc/init.d/net.eth1

    ln -sf /etc/init.d/net.eth0 /etc/init.d/net.br0

    rc-update add net.eth0 default

    rc-update add net.eth1 default

    rc-update add net.br0 default

Now create the /etc/init.d/bridge script

    ------- BEGIN /etc/init.d/bridge SCRIPT ---------

    #! /sbin/runscript

    depend() { before net }

    start() {

        ebegin "Setting up bridge"

        brctl addbr br0

        brctl addif br0 eth0

        brctl addif br0 eth1

        eend 0

    }

    stop() {

        ebegin "Unloading bridge interface(s)"

        ifconfig br0 down

        brctl delif br0 eth0

        brctl delif br0 eth1

        brctl delbr br0

        eend 0

    }

    -------- END /etc/init.d/bridge SCRIPT ----------

And just make it executable on startup.

    chmod 744 /etc/init.d/bridge

    rc-update add bridge default

All of the rc-update commands should return with a successful response.
```

Again, feel free to e-mail with questions!   :Smile: 

----------

## niraj

Wow.. that was fast  :Smile:  Thanks! I'll try it right now.

----------

## niraj

Ok, I've finally managed to set up bridging  :Very Happy:  Had to add some lines to set the IP using ifconfig to your script though... For some reason setting the IP in /etc/conf.d/net does not work for me.

I've run into another problem though... I can no longer access the internet from my gentoo box. The computer is not directly connected to the internet, but one of the 2 computers it is bridging is connected and it used to work before bridging... Any ideas on fixing this?

----------

## gtsquirrel

Sorry, I'm having a slow day.   :Smile:   What exactly is the problem?

Also, you should be able to create a line in the /etc/conf.d/net file like so:

```
iface_br0="IPADDRESS broadcast BCAST netmask SUBNETMASK"

# or even

# dhcpcd_br0=""
```

That's working on my box ... just have to make sure the net.br0 file is symlinked to /etc/init.d/net.eth0 for this to work.

If you can pass back a crude ASCII network diagram, that would be appreciated.   :Smile: 

----------

## CarlUman

Now this is cool!  Thanks for posting the info.

Question.

I would like to setup a wireless link between two houses (2500') but the cost of a bridge was to much.  Couldn't a computer at each end be setup like this to take the place of the bridges?  Well, I think I would only need to setup a bridge at one end since it is a single computer on the other.  All I would need is the antena and wire to go to/from the computers on each end.  Since the computer would be the bridge I would have no cost for the bridge(except the extra nic).

Thanks much

Carl

----------

## gtsquirrel

Yes, but that is not the purpose of a bridge.  What you're talking about is more of a Layer 2 switch function.  It is probably better implemented as a router (Layer 3), though.

Wireless has a few challenges to overcome, so it's a bit quirky to use as a "bridge" between wireless segments.  For instance, here are a few topologies.

```
         |                                       |

         |                                       |

         |     +--------+         +--------+     |

         |-----| WiFi-A | ooooooo | WiFi-B |-----|

         |     +--------+         +--------+     |

         |                                       |

         |                                       |

       LAN 1                                   LAN 2

                  Both LAN 1 and LAN 2 are

                    on the same IP subnet

```

To do this, you're talking about using the wireless link between hosts WiFi-A and WiFi-B as a Layer 2 bridge.  Basically, you want both to learn the MAC addresses of the hosts on the two LANs and act like a very fancy switch.  Doing this *is* possible using the 802.1d Linux code, but it is not very fun.  I do not recommend this approach, especially since it propogates a LOT of traffic over the wireless link (i.e. broadcasts, floods, etc.).

```
         |                                       |

         |                                       |

         |     +--------+         +--------+     |

         |-----| WiFi-A | ooooooo | WiFi-B |-----|

         |     +--------+         +--------+     |

         |                                       |

         |                                       |

       LAN 1                                   LAN 2

               LAN 1 and LAN 2 use different

                       IP subnets

```

In this topology, LAN 1 uses one IP subnet (192.168.1.0/24) while LAN 2 uses another (192.168.2.0/24).  The boxes act like Layer 3 routers, only sending traffic that is explicitly destined for the other side over the wireless link.  This is not as transparent as the other solution, but it certainly is more elegant in that you don't need to worry about the overhead of transparency.

If you're really set on doing the Layer 2 solution, let's take this off-line and discuss it further.  Shoot me an e-mail at squirrel@headnut.org with some more of the details.

Also, just in terms of antenna design, you might want to use a directional high-gain antenna with low-powered broadcasts.  This will minimize RF bleed and decrease the chances of a hacker accessing the link.  (Certainly, I would encrypt all of the traffic going over the link with IPSec or PPTP or some other very secure form of VPN technology.  This is one of the reasons the Layer 3 router solution works better: you can do this with a router, not a switch.)

Good luck!

chris

P.S.  I would like to clarify the last statement some ... you can setup security on the wireless link using any of the Layer 2 security options defined by the IEEE 802.11 committee (WEP, WPA, EAPOL, etc.).  However, these solutions are generally considered to be less secure than something like IPSec which operates at Layer 3.

----------

## gtsquirrel

I received the following e-mail from someone who read this posting, and I thought my reply could help to clear up any questions that might arise later on:

```
Date: Fri, 22 Oct 2004 22:31:22 -0400

From: rhargrove@---.---

To: squirrel@headnut.org

Subject: 802.1D Question

Hi,

  I see you have tried to tackle the new kernel bridging support, I have

tried in the past and have failed to bridge two networks using the old

method, I am hoping it is easier now, but I have no idea where to begin. I

was hoping you could point me to a how-to or give me a quick run down of

what to configure..

here is how I want my setup to look:

               Server 1 - gentoo 2.6.9

                ETH0 - PPP0 (dhcp assigned ip from ISP)-----------

           ---- ETH1 - 192.168.1.2                                |

          |                                                       |

192.168.1.0/24                                                Internet

                                                                  |

                                                                  |

               Server 2 - gentoo 2.6.9                            |

                ETH0 - (209.xxx.xxx.xx static from ISP)-----------

           ---- ETH1 - 192.168.1.1

          |

192.168.1.0/24

I need two physically seperate networks to talk so as to allow LAN gaming

on both sides (I run a gaming center) I was originally going to setup

routing, but I need the network to forward broadcasts to let games work

in multi-player between both networks.

Thanks,

   Russ

P.S Would it be more productive / efficient / easier to setup routing

instead of bridging and try to get linux to simply forward broadcasts?
```

And the reply:

```
Date: Mon, 25 Oct 2004 19:59:28 -0400

From: Chris Verges <squirrel@headnut.org>

To: rhargrove@---.---

Subject: Re: 802.1D Question

> I see you have tried to tackle the new kernel bridging support, I

> have tried in the past and have failed to bridge two networks using

> the old method, I am hoping it is easier now, but I have no idea

> where to begin. I was hoping you could point me to a how-to or give

> me a quick run down of what to configure..

The 802.1d bridging code is indeed quite simple nowadays.  Bridging

between two different technologies (i.e. WiFi and Ethernet, Token Ring

and Ethernet, etc.) is a little more complex, but for the most part

straight forward.

> here is how I want my setup to look:

>

>               Server 1 - gentoo 2.6.9

>                ETH0 - PPP0 (dhcp assigned ip from ISP)-----------

>           ---- ETH1 - 192.168.1.2                                |

>          |                                                       |

> 192.168.1.0/24                                                Internet

>                                                                  |

>                                                                  |

>               Server 2 - gentoo 2.6.9                            |

>                ETH0 - (209.xxx.xxx.xx static from ISP)-----------

>           ---- ETH1 - 192.168.1.1

>          |

> 192.168.1.0/24

Before we go any further, I wanted to comment on something related to

bridging ... for a bridge to work, all the interfaces that are part of

the bridge have to be in promiscuous mode.  (That is, they have to

receive and forward ALL packets, regardless of destination MAC or IP

address.)  Generally, by adding an interface to the conglomerate

bridge interface, it is automatically put into promiscuous mode AND

any assigned IP address(es) are cleared.

If you wanted to assign an IP address to the bridge for management

purposes, you would assign it to the bridge interface that you

created, not to the individual interfaces that make up the bridge.

That is,

        Create br0 as {eth0, eth1}

        ifconfig br0 192.168.1.1 netmask 255.255.255.0

        br0          192.168.1.1

         |- eth0     NONE <Promiscuous>

         +- eth1     NONE <Promiscuous>

What you want to do falls outside the scope of a bridge.  A bridge is

used to connect two collision domains to form a single coherent

broadcast domain.  (I apologize if you already understand these

concepts, but just in case I will be re-explaining them here.)

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 -- 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 -- or maybe you want to talk to all of them

with the same message -- 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).

So you want your logical networks to be contiguous while separating

out your collision domains.  That is, you want your network to

logically appear to act like this:

         Segment A ---------- Ethernet "Bridge" ---------- Segment B

       |                                                             |

       |<--------------------- 192.168.1.0/24 ---------------------->|

Certainly, this seems like a bridge would be PERFECT for this setup!

Alas, this is not the case as we will see in a minute.  Remember that

bridging technology works only for separate LAN segments.  While it is

true that Segment A and Segment B are logical segments, they are

actually physically quite far apart in your case.  Let's assume for

the sake of argument that Segment A is in San Jose (California) and

Segment B is in Atlanta (Georgia).  You can't simply plug a CAT5 cable

between them to connect them!  If you could, then you can use a

bridge.  (That's the basic rule of thumb you can use to decide when to

use a bridge.)

Rather, what we want to do is called IP tunneling.  We want to

simulate the CAT5 cable plugged in between Segment A and Segment B

OVER the Internet.  To do this, we use a router (or a Linux box acting

as a router).  We start by attaching two routers, one to each side of

the network:

      Segment A --------------- Router A

      Segment B --------------- Router B

Both segments use the same IP address range, 192.168.1.0/24 in your

case.  I will also assume that eth1 points to the LAN segment and eth0

points to the Internet connection.  (Substitute ppp0 for eth0 as is

the case.)  Assign some IP addresses to the router LAN interfaces

then:

      Router A      eth1     192.168.1.1

      Router B      eth1     192.168.1.2

Now you want to create a tunnel from Router A's eth1 to Router B's

eth1 via both of their respective eth0 interfaces.  There are several

projects to do this, but I definitely recommend looking at the

following projects:

  ipsec-tools         http://ipsec-tools.sf.net

  vtun                http://vtun.sf.net

  openvpn             http://openvpn.sf.net

  openswan            http://www.openswan.org

You can probably just look at openvpn and do what you need.  I haven't

actually set one of these up with a Linux box, though I know it is

possible.  You might want to search the article archives at

http://www.lugatgt.org for details ... I remember we gave a

presentation on how to do this exact thing, but I am not sure if it

ever made it to the website.

  A Whirlwind Tour (SSH + VPNs) by Sonny Rao:

    http://lugatgt.org/articles/sec_tour/#toc_2_4

Regardless, I don't recommend using a Linux box for this, especially

if this is for a company that requires a high amount of uptime and

good throughput.  You should look into some of the VPN solutions from

Cisco Systems.  (Disclaimer: I work for Cisco, but I recommend them

because I honestly do believe the equipment and the service you get

from Cisco is the best in the industry.  I wouldn't have gone to work

for them if I didn't believe that.)  They have self-contained routers

which will setup the VPN gateway for you and handle all of the details

that just aren't fun to manually configure.

  Cisco Security and VPN solutions:

    http://www.cisco.com/en/US/products/hw/vpndevc/index.html

  Cisco VPN 3002 Hardware Clients:

    http://www.cisco.com/en/US/products/hw/vpndevc/ps2286/index.html

  Cisco VPN 3000 Series Concentrators:

    http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/index.html

> P.S Would it be more productive / efficient / easier to setup

> routing instead of bridging and try to get linux to simply forward

> broadcasts?

Short answer: NO!!!!!!!

Slightly longer answer: Hell no!

Explanation: You never want to hack together this kind of solution.

It would be great if your games supported multicast and/or unicast

rather than relying on IP broadcasts, but I realize that is out of

your control.  (Petition the gaming companies to pay closer attention

to how they code the protocols!)  Let's assume I forward an IP packet

with a broadcast address of 192.168.1.255 to the 192.168.2.0/24

subnet.  None of the hosts on the subnet will pay attention to it

because it originated from an unknown network.  Ooops!

Like I said, the Cisco VPN solutions handle all of this for you.

There are many issues to take into account with a VPN, including Layer

2 and Layer 3 broadcasts, protocol encapsulation, security features

(L2TP, IPSec, PAP/CHAP, etc.), and more.  Configuring all of these can

make even the most experienced Linux guru come away with a headache

and wondering if he/she got all the settings right.  I would

definitely say to just buy the right equipment at the get-go -- you'll

be very thankful you did later on!

So in a short book form, that's how Ethernet, bridges, and IP tunnels

work!  I hope it has been as educational for you as it was fun for me.

You might want to ask your provider about a technology called MPLS

VPNs, too.  (Multi-Protocol Label Switching   Virtual Private

Networks.)  It is _very_ secure because the ISP actually configures

a private route for your two sites to use.  Some providers support it,

some don't.  But it is a very cool up-and-coming technology that is

rapidly replacing ATM and Frame Relay.

And just for my employer's benefit:

   All thoughts, suggestions and comments do not reflect the views or

   opinions of my employer, Cisco Systems.  Though I recommend Cisco

   equipment to be used in the final solution, any vendor's equipment

   that performs identical functions would suffice.  For the best

   results, contact your ISP's tech support center for their advice.

If I can help in any other way, feel free to ask.  :-)

chris

--

http://headnut.org

squirrel@headnut.org
```

----------

## LamboAlpha

Even though I have read several different posts, I am still confused how I would go about doing this (if even possible). Above you talked about an installation very similar to the picture shown below. I known someone (if not everyone) will recommend that I buy an AP (I am not being cheap); I have other reasons for not wanting to use an AP.

```
    Internet

        |                                        |

        |                                        |

        |     +---------+         +--------+     |

        +-----|  Router | ooooooo | Client |-----|

              +----+----+         +--------+     |

                   |                             |

                   |                             |

                 LAN 1                         LAN 2

                       LAN 1 and LAN 2
```

I have no problem getting the client box connected to the router, the question is how to setup the bridging/proxy. I would like all the computers to be on the same subnet, but as talked about above in this thread, it would easier to setup the client box on a different subnet. I wanted the router to be the dhcp for both networks, but I could also setup dhcpd on the client box. The end goal is to have it so that computers on both wired networks can access each other and the internet.

Router: WRT54G running WPA-PSK with AES (CCMP)

Client: Atheros base wireless card using MADWifi, WPA_Supplicant

----------

## gtsquirrel

So, in your diagram, you want Client to forward packets between two subnets (LAN1 = 192.168.1.0/24 and LAN2 = 192.168.2.0/24, for example)?  If that's the case, then you want Client to act as a router, not a bridge.  You do not want Client to bridge two subnets together ... it's considered a "bad thing."  A router will take packets and logically forward them along to Router, which will in turn forward them along to the Internet.  Using a wireless connection between the LAN1 and LAN2 routers is perfectly fine -- we do it all the time at work!  You just want to make sure that you configured the LAN2 gateway as a router, however.

Topology I'm assuming:

```
    +---------+            +---------+

    | Router1 | oooooooooo | Router2 |

    +---------+            +---------+

         |                      |

         |                      |

     |   |   |              |   |   |

   --------------         --------------

       |   |                  |   |

           |

           |

       +--------+

       |  DHCP  |

       | Server |

       +--------+
```

So here's what you need:

Linksys WRT54G as Router1

Linux PC as Router2, eth0 as LAN2 wired connection and wifi0 as LAN1 wireless connection

Enable the wireless feature of the WRT54G -- we'll assume you're using an ESSID of "linksys" for now with no WEP.  The internal IP of the WRT54G (Router1) should be 192.168.1.1/24.  Next, configure the wifi0 interface of the Linux PC (Router2) to connect to the wireless network being broadcast from Router1.  After you have a WiFi connection going from Router2 to Router1, configure the eth0 interface of the Linux PC (Router2) with an IP of 192.168.2.1/24.  Using iptables, SNAT all packets going from 192.168.2.0/24 to 192.168.1.0/24 with the wifi0 IP address -- might want to use the MASQUERADE chain rather than SNAT if you're not using a static IP on wifi0.  And once IP forwarding is enabled on Router2, you should be able to send packets from LAN2 to LAN1 and out to the Internet.  (The gateway for all LAN2 clients needs to be 192.168.2.1, or eth0 on the Linux PC.)

Note: To forward packets from LAN2 to a DHCP server on LAN1, you'll need to enable DHCP relaying on Router2.  I don't know how to do this on a Linux PC running iptables, but the related Cisco IOS commands are ip dhcp smart-delay and ip helper-address.  You can probably do a Google search to pick up that info.  Ideally, though, just run DHCP on Router2 to give address out the eth0 interface (to LAN2).

However, all this being said, the network you're attempting to setup is fairly complex, definitely not what the Linksys was intended for.  You would most likely be better off getting two Cisco 1800 series routers with wireless WIC options to act as Router1 and Router2 in the end.  I know you said that you cannot buy any gear, which is why I tried to solve the problem for you in the previous paragraph, but just realize that what you're doing is non-conventional.  Oh, and totally outside the scope of "802.1d bridging."   :Smile: 

----------

## LamboAlpha

I wanted to create a wireless link between the Router (WRT54G) and the Client (a computer), the client computer would be a transparent bridge to the traffic going between LAN 1 and LAN 2. After read this thread and other I found out that might be easier said then done. 

What I am now wondering if instead of creating a bridge on Client (create br0 with eth0 and ath0 on the Client), if I could setup the Client as a proxy. The Client would be the DHCP server for LAN 2, while the Router is the DHCP server for LAN 1. The router (including all of LAN 1 and ath0 on the Client) would be on subnet 192.168.0.X, while LAN 2 (eth0 on the Client) would be subnet 192.168.1.X.

Reading you reply, this seams possible (it is not as complex as originally explained), is this correct?

----------

## gtsquirrel

Correct.  This is the ideal scenario when attempting to bridge two wired LANs over wireless using a Linux PC.  In an ideal world, you could look at a hardware-based wireless bridge solution, like Cisco's Aironet 1300s, to fully link two wired networks over a feature-rich wireless link.  But in trying to do that with a Linux PC that acts as both a client and a bridge ... I just think you're going to be asking for too much trouble.   :Smile: 

Since it looks like LAN2 will be dependent on Client being on and its wireless link working, I think you should probably try to set it up as a router as I described before.  It will greatly simplify your troubleshooting later.  (Just remember, things ALWAYS go wrong.)   :Wink: 

Good luck!

----------

## sigix

Have followed the guide, currently I'm facing an issue regarding briding, eth0, eth1 are under bridge br0 on 2 machines 

Now when both bridged interface machines are on network they cause latency and disturbes machines connected. How do I deal with traffic flooding. I'm using 3com unmanaged switches.  Main purpose of bridging interfaces is to have single IP so if eth0 link to switch-1 of machine A goes down. It can access machine B through eth1 connected to switch2.

```

                +-----+------switch-2-----+------+

                |                         |

                +-----+--------------------------+ 

                      |                   |

                      |eth1               |eth1

                 +--------+          +--------+

                 |    B     |          |    A   |

                 +--------+          +--------+

                      |eth0               |eth0

                      |                   |

                +-----+------switch-1-----+------+

                |                         |

                +-----+--------------------------+ 

```

Ip-addr: A machine -- 192.168.1.4

  bro = eth0, eth1

Ip-addr: B machine -- 192.168.1.5

  bro = eth0, eth1

Now if B-eth0 goes down, A should be accessible through B-eth1-switch2 route 

similarly

Now if B-eth1 goes down, A should be accessible through B-eth0-switch1 route 

and major effort to avoid traffic flooding...

Futher help will be much appreciated

----------

## nobspangle

You need switches that support spanning tree protocol, that way they will automatically disable the redundant routes and then enable them when needed.

----------

## sigix

If one of bridge interface goes down, it'll fail over to another interface. How can I reduce the fail over time ?

----------

## think4urs11

 *sigix wrote:*   

> If one of bridge interface goes down, it'll fail over to another interface. How can I reduce the fail over time ?

 https://forums.gentoo.org/viewtopic-p-3996237.html#3996237

----------

