Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
HOWTO: Building a Gentoo 802.1d Bridge
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
gtsquirrel
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2002
Posts: 85
Location: San Jose, CA

PostPosted: Wed Dec 24, 2003 7:14 pm    Post subject: HOWTO: Building a Gentoo 802.1d Bridge Reply with quote

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:

Code:
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:

Code:
# 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:

Code:
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.

Code:
# /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.


Code:
          ----------------------------------------------------
               |                    |                  |
             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:

Code:
          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:

Code:
# /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:

Code:
# /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.

Code:
# /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.

Code:
/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:

Code:
# 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.

Code:
/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:

Code:
# 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:

Code:
/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:

Code:
# 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
Back to top
View user's profile Send private message
curtis119
Bodhisattva
Bodhisattva


Joined: 10 Mar 2003
Posts: 2160
Location: Phoenix, AZ USA, North America, Earth, SOL System, Milky Way, The Universe, The Cosmos, and Beyond.

PostPosted: Fri Jul 16, 2004 5:01 pm    Post subject: Reply with quote

Nice tip. Are you still planning on writing a How-To?
_________________
Gentoo: it's like wiping your ass with silk.
Back to top
View user's profile Send private message
gtsquirrel
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2002
Posts: 85
Location: San Jose, CA

PostPosted: Fri Jul 16, 2004 9:47 pm    Post subject: HOWTO status Reply with quote

As with most things, life has gotten in the way of it. :-) 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.
Back to top
View user's profile Send private message
gtsquirrel
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2002
Posts: 85
Location: San Jose, CA

PostPosted: Thu Jul 29, 2004 8:33 pm    Post subject: Clarification Reply with quote

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.

Code:
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! :-)
Back to top
View user's profile Send private message
niraj
n00b
n00b


Joined: 21 Jul 2004
Posts: 19
Location: Bangkok, Thailand

PostPosted: Thu Jul 29, 2004 8:36 pm    Post subject: Reply with quote

Wow.. that was fast :) Thanks! I'll try it right now.
Back to top
View user's profile Send private message
niraj
n00b
n00b


Joined: 21 Jul 2004
Posts: 19
Location: Bangkok, Thailand

PostPosted: Thu Jul 29, 2004 8:55 pm    Post subject: Reply with quote

Ok, I've finally managed to set up bridging :D 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?
Back to top
View user's profile Send private message
gtsquirrel
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2002
Posts: 85
Location: San Jose, CA

PostPosted: Mon Aug 16, 2004 6:04 pm    Post subject: Clarify? Reply with quote

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

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

Code:
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. :-)
Back to top
View user's profile Send private message
CarlUman
Apprentice
Apprentice


Joined: 07 Jul 2004
Posts: 158
Location: SE Iowa

PostPosted: Tue Sep 21, 2004 8:41 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
gtsquirrel
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2002
Posts: 85
Location: San Jose, CA

PostPosted: Tue Sep 21, 2004 8:54 pm    Post subject: Reply with quote

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.

Code:
         |                                       |
         |                                       |
         |     +--------+         +--------+     |
         |-----| 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.).

Code:
         |                                       |
         |                                       |
         |     +--------+         +--------+     |
         |-----| 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.
Back to top
View user's profile Send private message
gtsquirrel
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2002
Posts: 85
Location: San Jose, CA

PostPosted: Tue Oct 26, 2004 12:13 am    Post subject: E-mail from viewer Reply with quote

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:

Code:
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:

Code:
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
Back to top
View user's profile Send private message
LamboAlpha
n00b
n00b


Joined: 19 Feb 2004
Posts: 12

PostPosted: Sun Oct 30, 2005 8:01 pm    Post subject: How would you go about doing this? Reply with quote

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.

Code:
    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
Back to top
View user's profile Send private message
gtsquirrel
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2002
Posts: 85
Location: San Jose, CA

PostPosted: Mon Oct 31, 2005 6:42 pm    Post subject: I wouldn't :-) Reply with quote

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:

Code:
    +---------+            +---------+
    | 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." :-)
Back to top
View user's profile Send private message
LamboAlpha
n00b
n00b


Joined: 19 Feb 2004
Posts: 12

PostPosted: Tue Nov 01, 2005 2:25 am    Post subject: Let me rephrase that... Reply with quote

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?
Back to top
View user's profile Send private message
gtsquirrel
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2002
Posts: 85
Location: San Jose, CA

PostPosted: Tue Nov 01, 2005 5:47 am    Post subject: Correct Reply with quote

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. :-)

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.) ;-)

Good luck!
Back to top
View user's profile Send private message
sigix
Apprentice
Apprentice


Joined: 25 Jul 2003
Posts: 192

PostPosted: Sun Sep 03, 2006 1:18 pm    Post subject: Network flooding through interface bridges Reply with quote

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.

Code:


                +-----+------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
Back to top
View user's profile Send private message
nobspangle
Veteran
Veteran


Joined: 23 Mar 2004
Posts: 1318
Location: Manchester, UK

PostPosted: Mon Sep 11, 2006 9:42 am    Post subject: Reply with quote

You need switches that support spanning tree protocol, that way they will automatically disable the redundant routes and then enable them when needed.
Back to top
View user's profile Send private message
sigix
Apprentice
Apprentice


Joined: 25 Jul 2003
Posts: 192

PostPosted: Fri Apr 06, 2007 11:04 am    Post subject: reducing bridge interface failover Reply with quote

If one of bridge interface goes down, it'll fail over to another interface. How can I reduce the fail over time ?
Back to top
View user's profile Send private message
think4urs11
Bodhisattva
Bodhisattva


Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud

PostPosted: Fri Apr 06, 2007 11:13 am    Post subject: Re: reducing bridge interface failover Reply with quote

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
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum