Linux BRIDGE-STP-HOWTO

Uwe Böhme

          Johann-Heinrich-Abt-Straße 7
          95213
          Münchberg
          Germany
          +49/9251 960877
          +49/9251 960878
          uwe@bnhof.de
        

Lennert Buytenhenk

bridge code maintainer and developer
gnu.org

          buytenh@gnu.org
        
Release v0.04


Copyright © 2000 by Uwe Böhme
Revision History                                                             
Revision v0.04        11 January 2001            Revised by: U.B.            
Changed Lennert`s Bridge Homepage URL; added NIC to list.                    
Revision v0.03        17 July 2000               Revised by: U.B.            
Overwork pdf. Download links in doc.                                         
Revision v0.02        16 July 2000               Revised by: U.B.            
Fixed broken graphics in html dsl. Prepared pdf. Typos.                      
Revision v0.01        25 June 2000               Revised by: U.B.            
Changes name from BRIDGE-HOWTO to BRIDGE-STP-HOWTO (avoid interference with  
BRIDGE-HOWTO by Christopher Cole) and kill version 1.xx. Lennert Buytenhenk  
announced as coauthor.                                                       
Revision v0.00        01 June 2000               Revised by: U.B.            
Initial Release.                                                             
-----------------------------------------------------------------------------

Table of Contents
1. License
2. Document Home and Downloads
    2.1. The Bridge Sources And Utilities
    2.2. The Mailing-List
    2.3. This Document
   
   
3. What Is A Bridge?
4. Rules On Bridging
5. Preparing The Bridge
    5.1. Get The Files
    5.2. Apply The Patches
    5.3. Configure The Kernel
    5.4. Compile The Kernel
    5.5. Compile The Bridge Utilities
   
   
6. Set Up The Bridge
    6.1. brctl Command Synopsis
    6.2. Basic Setup
   
   
7. Advanced Bridge Features
    7.1. Spanning Tree Protocol
    7.2. Bridge And The IP-Chains
   
   
8. A Practical Setup Example
    8.1. Hardware-setup
    8.2. Software-setup
    8.3. See It Work
    8.4. Bridge Tests
        8.4.1. Tear The Patch Wire Test
        8.4.2. Kill The Root Bridge Test
       
       
   
   
A. Network Interface Cards
B. Recommended Reading
C. FAQ

About The Linux Modular Bridge And STP

   
   
    This document describes how to setup a bridge with the recent kernel
    patches and brctl utility by Lennert Buytenhek. and tries to explain
    about the STP implementation in this code.
   
   
With developer kernel 2.3.47 the new bridging code is part of the mainstream.
There are patches for stable kernels 2.2.14 to 2.2.16, where each is also
available as a ipchains-patch.
-----------------------------------------------------------------------------

1. License

Copyright (c) 2000 by Uwe Böhme. This document may be distributed only
subject to the terms and conditions set forth in the LDP License available at
[http://www.linuxdoc.org//manifesto.html] http://www.linuxdoc.org/
-----------------------------------------------------------------------------

2. Document Home and Downloads

2.1. The Bridge Sources And Utilities

Official url is [http://www.math.leidenuniv.nl/~buytenh/bridge/] http://
www.math.leidenuniv.nl/~buytenh/bridge/. With developer kernel 2.3.47 the new
bridging code is part of the mainstream.
-----------------------------------------------------------------------------

2.2. The Mailing-List

The Bridge-Mailinglist is homed at [http://www.math.leidenuniv.nl/mailman/
listinfo/bridge] http://www.math.leidenuniv.nl/mailman/listinfo/bridge.
-----------------------------------------------------------------------------

2.3. This Document

This document has it's official homepage at [http://www.bnhof.de/~uwe/
bridge-stp-howto/BRIDGE-STP-HOWTO/] http://www.bnhof.de/~uwe/bridge-stp-howto
/BRIDGE-STP-HOWTO/. It's a part of the Linux Documentation Project located at
[http://www.linuxdoc.org/] http://www.linuxdoc.org/.

Download Types and Locations

Build environment as tar.gziped file
    [http://www.bnhof.de/~uwe/bridge-stp-howto/BRIDGE-STP-HOWTO.tar.gz] http:
    //www.bnhof.de/~uwe/bridge-stp-howto/BRIDGE-STP-HOWTO.tar.gz
   
HTML-gziped file
    [http://www.bnhof.de/~uwe/bridge-stp-howto/BRIDGE-STP-HOWTO.html.tar.gz]
    http://www.bnhof.de/~uwe/bridge-stp-howto/BRIDGE-STP-HOWTO.html.tar.gz
   
PDF-gziped file
    [http://www.bnhof.de/~uwe/bridge-stp-howto/BRIDGE-STP-HOWTO.pdf.gz] http:
    //www.bnhof.de/~uwe/bridge-stp-howto/BRIDGE-STP-HOWTO.pdf.gz
   
PS-gziped file
    [http://www.bnhof.de/~uwe/bridge-stp-howto/BRIDGE-STP-HOWTO.ps.gz] http:/
    /www.bnhof.de/~uwe/bridge-stp-howto/BRIDGE-STP-HOWTO.ps.gz
   

-----------------------------------------------------------------------------
3. What Is A Bridge?

A bridge is a device that separates two or more network segments within one
logical network (e.g. a single IP-subnet).

A bridge is usually placed between two separate groups of computers that talk
with each other, but not that much with the computers in the other group. A
good example of this is to consider a cluster of Macintoshes and a cluster of
Unix machines. Both of these groups of machines tend to be quite chatty
amongst themselves, and the traffic they produce on the network causes
collisions for the other machines who are trying to speak to one another.

The job of the bridge is to examine the destination of the data packets one
at a time and decide whether or not to pass the packets to the other side of
the Ethernet segment. The result is a faster, quieter network with less
collisions.

The bridging code decides whether to bridge data or to drop it not by looking
at the protocol type (IP, IPX, NetBEUI), but by looking at the MAC-address
unique to each NIC.

   
    Important: It's vital to understand that a bridge is neither a router nor
    a fire-wall. Spoken in simple term a bridge behaves like a network switch
    (i.e. Layer 2 Switch), making it a transparent network component (which
    is not absolutely true, but nearly). Read more about this at Section 4.
   
In addition, you can overcome hardware incompatibilities with a bridge,
without leaving the address-range of your IP-net or subnet. E.g. it's
possible to bridge between different physical media like 10 Base T and 100
Base TX.

My personal reason for starting to set up a bridge was that in my work I had
to connect Fast Ethernet components to a existing HP Voice Grade network,
which is a proprietary networking standard.

Features Above Pure Bridging

STP
    The Spanning Tree Protocol is a nifty method of keeping Ethernet devices
    connected in multiple paths working. The participating switches negotiate
    the shortest available path by STP. This feature will be discussed in 
    Section 7.1.
   
Multiple Bridge Instances
    Multiple bridge instances allow you to have more than one bridge on your
    box up and running, and to control each instance separately.
   
Fire-walling
    There is a patch to the bridging code which allows you to use IP chains
    on the interface inside a bridge. More info about this you'll find at 
    Section 7.2.
   

-----------------------------------------------------------------------------
4. Rules On Bridging

There is a number of rules you are not allowed to break (otherwise your
bridge will do).

  * A port can only be a member of one bridge.
   
  * A bridge knows nothing about routes.
   
  * A bridge knows nothing about higher protocols than ARP. That's the reason
    why it can bridge any possible protocol possibly running on your
    Ethernet.
   
  * No matter how many ports you have in your logical bridge, it's covered by
    only one logical interface
   
  * As soon as a port (e.g. a NIC) is added to a bridge you have no more
    direct control about it.
   

+---------------------------------------------------------------------------+
|                                  Warning                                  |
+---------------------------------------------------------------------------+
|If one of the points mentioned above is not clear to you now, don't        |
|continue reading. Read the documents listed in Appendix B first.           |
+---------------------------------------------------------------------------+

If you ever tried to ping an unmanaged switch, you will know that it doesn't
work, because you don't have a IP-address for it. To switch datagrams it
doesn't need one. The other thing is if you want to manage the switch. It's
too much strain, to take a dumb terminal, walk to the place you installed it
(normally a dark, dusty and warm room, with a lot of green and red Christmas
lights), to connect the terminal and to change the settings.

What you want is remote management, usually by SNMP, telnet, rlogin or (best)
ssh. For all this services you will need a IP. That's the exception to the
transparency. The new code allows you without any problem to assign a IP
address to the virtual interface formed by the bridge-instance you will
create in Section 6.2. All NIC's (or other interfaces) in your bridge will
happily listen and respond to datagrams destined to this IP.

All other data will not interfere with the bridge. The bridge just acts like
a switch.
-----------------------------------------------------------------------------

5. Preparing The Bridge

This section describes what you need and how you do to prepare your bridge.
-----------------------------------------------------------------------------

5.1. Get The Files

Here you can find a list of the files and down-loads you will need for the
setup of the bridge. If you have one of the mentioned files or packages on
your distribution, of course there is no need to create network load.

I'll only mention the files for the 2.2.14 kernel. If you want to try a
different one (e.g. 2.2.15 or the recent development kernel) just replace the
kernel version number and look whether you find it.

   
    Important: You have read the abstract, didn't you? So you know that there
    is no need to download any kernel-patch if you're working with a kernel
    later than 2.3.47.
   
File and package list

Unpatched kernel-sources
    E.g. linux-2.2.14.tar.bz2 available from your local kernel.org mirror.
    Please check first if you find it in your distribution (take unpatched
    kernel-sources). If you don't, please check The Linux Kernel Archive
    Mirror System for a close by mirror and down-load it from there.
   
Bridge patches
        Note: If your kernel is later than 2.3.47 you don't need this. The
        bridging is part of the mainstream from that version.
       
   
    Get the bridge kernel patches for your kernel version from [http://
    www.math.leidenuniv.nl/~buytenh/bridge/] http://www.math.leidenuniv.nl/
    ~buytenh/bridge/. Identify the file by the kernel number.
   
        Note: There are also patches allowing to work with IP chains. I never
        tried it, for I don't see the need to fire-wall inside my LAN, and
        absolutely no need to bridge against the outer world. Feel free to
        contribute about that issue.
       
   
    Kernel patches for the stable 2.2 kernel.
   
    Available Kernel patches
   
    bridge-0.0.9-against-2.2.18.diff, the main kernel patch against 2.2.18
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-0.0.9-against-2.2.18.diff] http://www.math.leidenuniv.nl/
        ~buytenh/bridge/patches/bridge-0.0.9-against-2.2.18.diff
       
    bridge-ipchains-against-0.0.9-against-2.2.18.diff, an add-on patch for
        bridge firewalling against 2.2.18
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.9-against-2.2.18.diff] http://
        www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.9-against-2.2.18.diff
       
    bridge-0.0.8-against-2.2.18pre19.diff, the main kernel patch against
        2.2.18pre19.
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-0.0.8-against-2.2.18pre19.diff] http://www.math.leidenuniv.nl/
        ~buytenh/bridge/patches/bridge-0.0.8-against-2.2.18pre19.diff
       
    bridge-0.0.8-against-2.2.17-0.5.diff, the main kernel patch against
        2.2.17-0.5
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-0.0.8-against-2.2.17-0.5.diff] http://www.math.leidenuniv.nl/
        ~buytenh/bridge/patches/bridge-0.0.8-against-2.2.17-0.5.diff
       
    bridge-ipchains-against-0.0.8-against-2.2.18pre19.diff, an add-on patch
        for bridge firewalling against 2.2.18pre19
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.8-against-2.2.18pre19.diff] http://
        www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.8-against-2.2.18pre19.diff
       
    bridge-ipchains-against-0.0.8-against-2.2.17-0.5.diff, an add-on patch
        for bridge firewalling against 2.2.17-0.5
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.8-against-2.2.17-0.5.diff] http://
        www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.8-against-2.2.17-0.5.diff
       
    bridge-0.0.7-against-2.2.18pre15.diff, the main kernel patch against
        2.2.18pre15
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-0.0.7-against-2.2.18pre15.diff] http://www.math.leidenuniv.nl/
        ~buytenh/bridge/patches/bridge-0.0.7-against-2.2.18pre15.diff
       
    bridge-ipchains-against-0.0.7-against-2.2.18pre15.diff, an add-on patch
        for bridge firewalling against 2.2.18pre15
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.7-against-2.2.18pre15.diff] http://
        www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.7-against-2.2.18pre15.diff
       
    bridge-0.0.7-against-2.2.17.diff, the main kernel patch against 2.2.17
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-0.0.7-against-2.2.17.diff] http://www.math.leidenuniv.nl/
        ~buytenh/bridge/patches/bridge-0.0.7-against-2.2.17.diff
       
    bridge-ipchains-against-0.0.7-against-2.2.17.diff, an add-on patch for
        bridge firewalling against 2.2.17
        [http://www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.7-against-2.2.17.diff] http://
        www.math.leidenuniv.nl/~buytenh/bridge/patches/
        bridge-ipchains-against-0.0.7-against-2.2.17.diff
       
   
   
Bridge configuration utilities
    You also will need the bridge configuration utilities to set up the
    bridge Section 6. You can also download them from [http://
    www.math.leidenuniv.nl/~buytenh/bridge/] http://www.math.leidenuniv.nl/
    ~buytenh/bridge/.
   

-----------------------------------------------------------------------------
5.2. Apply The Patches

    Note: If your kernel is later than 2.3.47 you don't need this. The
    bridging is part of the mainstream from that version.
   
Apply the bridging patch your kernel. If you don`t know how to do that read
the Kernel-HOWTO which can be found in your distribution or at [http://
www.linuxdoc.org/HOWTO/Kernel-HOWTO.html] http://www.linuxdoc.org/HOWTO/
Kernel-HOWTO.html


Example 1. Applying a kernel patch
root@mbb-1:~ # cd /usr/src/linux-2.2.14                                      
root@mbb-1:/usr/src/linux-2.2.14 # patch -p1 < \                             
    bridge-0.0.5-against-2.2.14.diff                                         
.                                                                            
.                                                                            
                                                                             
-----------------------------------------------------------------------------

5.3. Configure The Kernel

Now it's time we configure our freshly patched kernel to create the ability
to bridge.

Run make config, make menuconfig or the click-o-rama make xconfig. Select 
bridging in the networking option section to be compiled as a module. AFAIK
there is no strong reason why not to compile it as a kernel module, whereas I
heard rumors about problems with compiling the bridging code directly into
the kernel.


root@mbb-1:~ # cd /usr/src/linux-2.2.14                                      
root@mbb-1:/usr/src/linux-2.2.14 # make menuconfig                           
.                                                                            
                                                                             

-----------------------------------------------------------------------------
5.4. Compile The Kernel

Compile your kernel Example 2. Make the new compiled kernel-image to be
loaded. I don't know if the kernel patches only apply to the bridging-module
or also modify some interfaces inside vmlinuz. So it might not be a error to
give a reboot after you updated the kernel-image.


Example 2. Commands To Compile Your Kernel
root@mbb-1:/usr/src/linux-2.2.14 # make dep clean zImage modules modules_install zlilo 
...                                                                                    
                                                                                       
-----------------------------------------------------------------------------

5.5. Compile The Bridge Utilities

This is how to compile and install from the scratch. Just unzip the
utilities-tarball, cd into the newly created directory and give a make.


Example 3. Commands To Compile Your Bridge-Utilities
root@mbb-1:/usr/src/linux-2.2.14 # cd /usr/local/src                         
root@mbb-1:/usr/local/src/ # tar xzvf bridge-utils-0.9.1.tar.gz              
.....                                                                        
....                                                                         
root@mbb-1:/usr/local/src # cd bridge                                        
root@mbb-1:/usr/local/src/bridge # make                                      
.....                                                                        
....                                                                         
                                                                             

After the compilation shown in Example 3 have worked properly, you can copy
the executables to let's say /usr/local/sbin/ (at least I did). So the
commands you have to give should be clear, but to be complete see Example 4


Example 4. Copy The Binaries Of The Utilities
root@mbb-1:/usr/local/src/bridge # cd brctl                                  
root@mbb-1:/usr/local/src/bridge/brctl # cp brctl /usr/local/sbin            
root@mbb-1:/usr/local/src/bridge/brctl # chmod 700 /usr/local/sbin/brctl     
root@mbb-1:/usr/local/src/bridge/brctl # cp brctld /usr/local/sbin           
root@mbb-1:/usr/local/src/bridge/brctl # chmod 700 /usr/local/sbin/brctld    
                                                                             

Also now you can copy the new man-page to a decent place, as shown in Example
5.


Example 5. Copy The Man-page Of brctl
root@mbb-1:/usr/local/src/bridge # cd doc                                                
root@mbb-1:/usr/local/src/bridge/doc #  gzip -c brctl.8 > /usr/local/man/man8/brctl.8.gz 
                                                                                         
-----------------------------------------------------------------------------

6. Set Up The Bridge

Make sure all your network cards are working nicely and are accessible. If
so, ifconfig will show you the hardware layout of the network-interface. If
you have problems making your cards work please read the Ethernet-HOWTO at
[http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html] http://www.linuxdoc.org/
HOWTO/Ethernet-HOWTO.html. Don't mess around with IP-addresses or net-masks.
You will not need it, until you bridge fully operational an up.

After you did the steps mentioned above a modprobe -v bridge should show no
errors. You can check the success by issuing a cat /proc/modules. Also for
each of the network cards you want to use in the bridge the ifconfig
whateverNameYourInterfaceHas should give you some information about the
interface.

If your bridge-utilities have been correctly built and your kernel and
bridge-module are OK, then issuing a brctl should show a small command
synopsis.
-----------------------------------------------------------------------------

6.1. brctl Command Synopsis

root@mbb-1:~ # brctl                                                              
commands:                                                                         
    addbr           <bridge>                add bridge                      (1)   
    addif           <bridge> <device>       add interface to bridge         (2)   
    delbr           <bridge>                delete bridge                   (3)   
    delif           <bridge> <device>       delete interface from bridge    (4)   
    show                                    show a list of bridges          (5)   
    showbr          <bridge>                show bridge info                (6)   
    showmacs        <bridge>                show a list of mac addrs        (7)   
                                                                                  
    setageing       <bridge> <time>         set ageing time                 (8)   
    setbridgeprio   <bridge> <prio>         set bridge priority             (9)   
    setfd           <bridge> <time>         set bridge forward delay        (10)  
    setgcint        <bridge> <time>         set garbage collection interval (11)  
    sethello        <bridge> <time>         set hello time                  (12)  
    setmaxage       <bridge> <time>         set max message age             (13)  
    setpathcost     <bridge> <port> <cost>  set path cost                   (14)  
    setportprio     <bridge> <port> <prio>  set port priority               (15)  
    stp             <bridge> <state>        {dis,en}able stp                (16)  
                                                                                  

(1) (3)
    The brctl addbr bridgename command creates a logical bridge instance with
    the name bridgename. You will need at least one logical instance to do
    any bridging at all. You can interpret the logical bridge being a
    container for the interfaces taking part in the bridging. Each bridging
    instance is represented by a new network interface.
   
   
    Example 6. Creating A Instance
    root@mbb-1:~ # brctl addbr mybridge1                                     
                                                                             
    The corresponding "shutdown" command is brctl delbr bridgename.
   
    +-----------------------------------------------------------------------+
    |                                Caution                                |
    +-----------------------------------------------------------------------+
    |brctl delbr bridgename will only work, if there are no more interfaces |
    |added to the instance you want to delete.                              |
    +-----------------------------------------------------------------------+
   
(2) (4)
    The brctl addif bridgename device command enslaves the network device 
    device to take part in the bridging of bridgename. As a simple
    explanation, each interface enslaved into a instance is bridged to the
    other interfaces of the instance.
    The corresponding command to tale a interface out of the bridge would be 
    brctl delif bridgename device
   
(5) The brctl show command gives you a summary about the overall bridge
    status, and the instances running as shown in Example 7. If you are
    interested in detailed information about a instance and it's interfaces
    you will have to check  (6) .
   
   
    Example 7. Output Of brctl show
    root@mbb-1:~ # brctl show                                                
    bridge name     bridge id               stp enabled                      
    mybridge1       0000.0800062815f6       yes                              
                                                                             
   
(6) The brctl showbr bridgename command gives you a summary about a bridge
    instance and it's enslaved interfaces.
   
   
    Example 8. Output Of brctl showbr bridgename
    root@mbb-1:~ # brctl showbr mybridge1                                              
    mybridge1                                                                          
     bridge id              0000.0800062815f6                                          
     designated root        0000.0800062815f6                                          
     root port                 0                    path cost                  0       
     max age                   4.00                 bridge max age             4.00    
     hello time                1.00                 bridge hello time          1.00    
     forward delay             4.00                 bridge forward delay       4.00    
     ageing time             300.00                 gc interval                4.00    
     hello timer               0.84                 tcn timer                  0.00    
     topology change timer     0.00                 gc timer                   1.84    
     flags                                                                             
                                                                                       
                                                                                       
    eth0 (1)                                                                           
     port id                8001                    state                   forwarding 
     designated root        0000.0800062815f6       path cost                100       
     designated bridge      0000.0800062815f6       message age timer          0.00    
     designated port        8001                    forward delay timer        0.00    
     designated cost           0                    hold timer                 0.84    
     flags                                                                             
                                                                                       
    eth1 (2)                                                                           
     port id                8002                    state                   forwarding 
     designated root        0000.0800062815f6       path cost                100       
     designated bridge      0000.0800062815f6       message age timer          0.00    
     designated port        8002                    forward delay timer        0.00    
     designated cost           0                    hold timer                 0.84    
     flags                                                                             
                                                                                       
   
(7) The brctl showmacs bridgename command gives you a list of MAC-addresses
    of the interfaces which are enslaved in bridgename.
   
   
    Example 9. Output Of brctl showmacs bridgename
    root@mbb-1:~ # brctl showmacs mybridge1                                  
    port no mac addr                is local?       ageing timer             
      1     00:10:4b:b6:c6:e4       no               119.25                  
      1     00:50:04:43:82:85       no                 0.00                  
      1     00:50:da:45:45:b1       no                76.75                  
      1     00:a0:24:d0:4c:d6       yes                0.00                  
      1     00:a0:24:f0:22:71       no                 5.81                  
      1     08:00:09:b5:dc:41       no                22.22                  
      1     08:00:09:fb:39:a1       no                27.24                  
      1     08:00:09:fc:92:2c       no                53.13                  
      4     08:00:09:fc:d2:11       yes                0.00                  
      1     08:00:09:fd:23:88       no               230.42                  
      1     08:00:09:fe:0d:6f       no               144.55                  
                                                                             
   
(8) Sets the aging time. The aging time is the number of seconds a MAC
    -address will be kept in the forwarding database after having received a
    packet from this MAC address. The entries in the forwarding database are
    periodically timed out to ensure they won't stay around forever. Normally
    there should be no need to modify this parameter.
(9) Sets the bridge's relative priority. The bridge with the lowest priority
    will be elected as the root bridge. The root bridge is the "central"
    bridge in the spanning tree. More information about STP you find at 
    Section 7.1.
(10)
    Sets the forwarding delay time. The forwarding delay time is the time
    spent in each of the Listening and Learning states before the Forwarding
    state is entered.
(11)Sets the garbage collection interval. Every (this number) seconds, the
    entire forwarding database is checked for timed-out entries. The
    timed-out entries are removed.
(12)Sets the hello time. Every (this number) seconds, a hello packet is sent
    out by the Root Bridge and the Designated Bridges. Hello packets are used
    to communicate information about the topology throughout the entire
    Bridged Local Area Network. More information about STP you find at 
    Section 7.1.
(13)Sets the maximum message age. If the last seen (received) hello packet is
    more than this number of seconds old, the bridge in question will start
    the takeover procedure in attempt to become the Root Bridge itself. More
    information about STP you find at Section 7.1.
(14)Sets the cost of receiving (or sending, I'm not sure) a packet on this
    interface. Faster interfaces should have lower path costs. These values
    are used in the computation of the minimal spanning tree. More
    information about STP you find at Section 7.1. Paths with lower costs are
    likelier to be used in the spanning tree than high-cost paths (As an
    example, think of a gigabit line with a 100Mbit or 10Mbit line as a
    backup line. You don't want the 10/100Mbit line to become the primary
    line there.)
    The Linux implementation currently sets the path cost of all eth*
    interfaces to 100, the nominal cost for a 10Mbit connection. There is
    unfortunately no easy way to discern 10Mbit from 100Mbit from 1Gbit
    Ethernet cards, so the bridge cannot use the real interface speed.
   
(16)With this parameter you can enable or disable the Spanning Tree Protocol.
(9) (12)(14)(16)
    This parameters are only of interest, if you have more than one bridge in
    your LAN and stp enabled. Before modifying them you should read Section
    7.1.

-----------------------------------------------------------------------------
6.2. Basic Setup

The standard configuration should consist of:

 1. Create the bridge interface.
    root@mbb-1:~ # brctl addbr mybridge                              
                                                                     
   
 2. Add interfaces to the bridge.
    root@mbb-1:~ # brctl addif mybridge eth0                         
    root@mbb-1:~ # brctl addif mybridge eth1                         
                                                                     
   
 3. Zero IP the interfaces.
    root@mbb-1:~ # ifconfig eth0 0.0.0.0                             
    root@mbb-1:~ # ifconfig eth1 0.0.0.0                             
                                                                     
   
 4. Put up the bridge.
    root@mbb-1:~ # ifconfig mybridge up                              
                                                                     
   
 5. Optionally you can configure the virtual interface mybridge to take part
    in your network. It behaves like one interface (like a normal network
    card). Exactly that way you configure it, replacing the previous command
    with something like:
    root@mbb-1:~ # ifconfig mybridge 192.168.100.5 netmask 255.255.255.0 up 
                                                                            
   

A more sophisticated setup script you will find at Example 16.

   
    Important: If you get the terrible experience of a frozen system or some
    nasty behavior of your nicely shaped linux box at
    root@mbb-1:~ # ifconfig ethn 0 0.0.0.0                                   
                                                                             
    please try (after the reboot of the system if necessary) before starting
    any bridge stuff at all a
    root@mbb-1:~ # ifconfig ethn promisc up                                  
                                                                             
    If again your system is frozen it's you NIC's driver you have to blame,
    not the bridging code.
   
-----------------------------------------------------------------------------
7. Advanced Bridge Features

Here we will cover some advanced features of the new bridge code.
-----------------------------------------------------------------------------

7.1. Spanning Tree Protocol

Tell me...

  * You are a networkadmin...?
   
  * You have a switch on top of your ethernet tree...?
   
  * You have nightmares of a switch emmiting smoke...?
   
  * Your company is not extremely rich and con provide another redundant
    switch just waiting for you to plug the patchwires..?
   
  * You don't feel like placing your bed close to your main network node to
    plug the wires...?
   

Don't wait until you're just another nervous wreck. Join linux bridge
community and enjoy the relaxment a stp-enabled inhouse scenario is offering
to you.

Ok, let's leave that commercial and get back linux and the bridge. Take a
look on this small thread from the linux-bridge mailing list.

STP Thread from bridge@openrock.net (no more valid)

Could you give me some hints about multi-bridge scenarios.
Does the STP "heartbeat" mechanism also work with bridges with more than two
    cards?
How fast does it get up, and what can I do about it?

Could you give me some hints about multi-bridge scenarios.

You can just set up two "mirrored" bridges. You have two network interfaces
in your bridge? Set up the mirror bridge so that it has two network
interfaces as well, and connect each of the interfaces to one subnet. This
will work without the need of configuration.

    Note: Be sure that you have the spanning tree protocol enabled. If you
    didn't use brctl, this should be fine, because in Linux, it is on by
    default. To check, you could check whether the bridge sends a packet to
    0180c2000000 every 2 seconds. If it does, the STP is on. The STP is
    needed so that only one bridge will be active at any given time.
   
    Note: To be able to see nicely formatted stp packages in your network
    take a look at at the bridge homepage for the patches to tcpdump.
   
The "master" bridge will send out STP packets every 2 seconds by default. The
"slave" bridge will receive these packets, and will notice that the master is
still up. If the slave hasn't received a packet in 20 seconds (max. message
age parameter), it will start the takeover procedure. From the moment the
takeover procedure starts, it will take about 30 seconds (twice the forward
delay parameter) for the bridge to become fully operational.

Does the STP "heartbeat" mechanism also work with bridges with more than two
cards?

Yes, it works with any number of interfaces. You can invent bizarre
topologies to your heart's desire. You can use multiple (redundant)
bridge-bridge connects, you can insert loops, whatever. The STP code will
always find the minimal spanning tree. The bridge code will even deal with
the loss of any number of interfaces. If there are two redundant bridges with
identical connections, the loss of an interface on one of the bridges will
cause the other bridge to take over forwarding to that specific interface. 
Now isn't that great? :)

How fast does it get up, and what can I do about it?

If you think 50 seconds is too much -- and I guess you should; alas, the IEEE
specs gives us these default values -- you can tweak these parameters. If you
set the hello time (the STP packet interval) from 2 to 1 second, you can
safely set the message age parameter to 4 seconds. Then you can set the
forward delay to 4 seconds, and this will in total give you a takeover time
of ~12 seconds.

The great thing which is made possible by STP is a redundant parallel
bridging scenario, with automated take over features. Within a network basing
on stp the bridges always try to send a datagram the (by path cost) shortest
path. Only on that path the bridges are forwarding, all other paths between
this shortest way are blocked. If there is a broken path, the bridges agree
about the next shortest. So doubled paths don't break the net, but are
bringing more security... For a example setup of a fail secured connection
see Section 8.
-----------------------------------------------------------------------------

7.2. Bridge And The IP-Chains

The normal idea about a bridge would not allow anything like firewalling, but
since several people have asked Lennert for ipchains firewalling on bridge
forwarding he implemented it.

   
    Important: If you want to do this, you will need to apply the special
    ip-chain-bridge-patch (also available at [http://www.math.leidenuniv.nl/
    ~buytenh/bridge/] the bridge homepage).
   
As soon you have everything up correctly, the bridging code will check each
to-be-forwarded packet against the ipchains chain which has the same name as
the bridge.

So.. if a packet on eth0 is to be forwarded to eth1, and those interfaces are
both part of the bridge group br0, the bridging code will check the packet
against the chain called 'br0'.

+---------------------------------------------------------------------------+
|                                  Warning                                  |
+---------------------------------------------------------------------------+
|If the chain does not exist, the packet will be forwarded. So if you want  |
|to do firewalling, you'll have to create the chain yourself.               |
+---------------------------------------------------------------------------+


Example 10. A Simple Bridge Firewall Setup
Example:                                                                     
# brctl addbr br0                                   (1)                      
# brctl addif br0 eth0                              (2)                      
# brctl addif br0 eth1                              (3)                      
# ifconfig br0 10.0.0.254                           (4)                      
# ipchains -N br0                                   (5)                      
# ipchains -A br0 -s 10.0.0.1/8 -i eth0 -j DENY     (6)                      
                                                                             

(1) Creating a bridge interface named br0
(2) (3)
    Placing eth0 and eth1 into the bridge.
(4) Assigning a regular IP address to the bridge. The IP is taken from
    private network 10.X.X.X (Class A).
(5) Creating a ip-chain named br0
(1) (5)
    +-----------------------------------------------------------------------+
    |                                Caution                                |
    +-----------------------------------------------------------------------+
    |It's vital to have the same name here (br0 or whatever you have        |
    |selected, as long as you have the same in all places).                 |
    +-----------------------------------------------------------------------+
   
(6) Denying all trafic with source 10.X.X.X on eth0.

-----------------------------------------------------------------------------
8. A Practical Setup Example

   
    This is a real-world example which is currently working in our network.
    Even if it's for sure not a very common situation it might be useful.
   
   
I had to solve a small hardware incompatibility. HP-VG (Voice Grade) 100Mbit
network is not fast Ethernet compatible. Having neither the money nor the
will to replace the stuff and having the need to expand the system I had to
find a solution which was a) stable and b) cheap.

For sure buying a HP modular switch was not meeting condition b). So I
remembered I heard about Linux-bridging which automatically fulfilled
condition a) and b).

So quite some time ago I successfully set up a bridge between the two
incompatible networks. Its first hardware-layout is shown in Figure 1.


Figure 1. Hardware setup Of The Old Bridge Scenario

[old-hardware-setup]

The old setup of my previous linux bridge

It was configured as a transparent network component, meaning it didn't take
a part in the network, but only bridged it. Originally it was set up on
kernel 2.0.35 from a SuSE 5.3 distribution.

The next problem showed up at once. A single bridge connecting the big
segments might be c) a bottleneck and d) a reason to kill the netadmin, if it
blows up. So I tried to find some solution for that problem.

What happened next was that I discovered some hints that a new maintainer
took over the bridging code. A few mails on the bridge-mailing list later as
shown in Section 7.1 I was more clever. The new modular bridging code
fulfilled exactly what I was looking for.

The new maintainer: Lennert Buytenhek . His project page can be found at
[http://www.math.leidenuniv.nl/~buytenh/bridge/] http://
www.math.leidenuniv.nl/~buytenh/bridge/ IMHO he's doing a great job. Thanks a
lot.
-----------------------------------------------------------------------------

8.1. Hardware-setup

The ideas and hints I got from the mailing list discussion shown in Section
7.1 lead to a new hardware-setup shown in Figure 2. The setup is intended to
provide a default machine (guess which one). The bridge has 3 HP cards of
which each is connected to a HP VG15 hub. The 3com card is connected to a
3com Superstack Fast Ethernet switch.


Figure 2. Hardware Setup Of The Multi bridge Scenario

[hardware-setup]

The practically working setup of my local linux Ethernet multi bridge

This setup is not only fail proof to any one of the bridge's interfaces being
down, but also to complete blackout of one of the bridges. Additional
advantage to the old-setup Figure 1 that the single HUBS are switched. This
means that a datagram being sent from one port on the VG15 HUB blocks 30
ports by maximum and 15 ports by minimum, instead of blocking all 45 ports.
Also, the breakdown of the HUB, to the old bridge was connected, would have
caused the whole HP-segment to break down. With the new code only the
machines connected to the broken HUB will get no more data.
-----------------------------------------------------------------------------

8.2. Software-setup

For both bridges the setup is exactly the same (with the exception of bridge
priority which will be discussed later on). The machine was setup by the SuSE
6.4 distribution with the original unpatched kernel sources installed. At
this point only the minimal configuration and no additional hardware or
network setup.

The basic setup is according the descriptions in the beginning of this
document. The thing I did in addition was bringing up the unpatched 2.2.14
sources of the SuSE 6.4 distribution to version 2.2.15 as in Example 11.


Example 11. Upgrading The Kernel From 2.2.14 To 2.2.15
root@mbb-1:~ # cd /usr/src/linux-2.2.14                                      
root@mbb-1:/usr/src/linux-2.2.14 # patch -p1 \                               
    /usr/local/download/kernel/patch-2.2.15                                  
patching file ........................                                       
patching file ...................                                            
...                                                                          
..                                                                           
root@mbb-1:/usr/src/linux-2.2.14 # cd ..                                     
root@mbb-1:/usr/src # mv linux-2.2.14 linux-2.2.15                           
root@mbb-1:/usr/src # rm linux                                               
root@mbb-1:/usr/src # ln -s linux-2.2.15 linux                               
                                                                             

Next step was to apply the bridge-patch as shown in Example 12.


Example 12. Applying The Kernel Patch
root@mbb-1:/usr/src # cd /usr/src/linux-2.2.15                               
root@mbb-1:/usr/src/linux-2.2.15 # patch -p1 < \                             
    bridge-0.0.5-against-2.2.15.diff                                         
patching file ........................                                       
patching file ...................                                            
...                                                                          
..                                                                           
                                                                             

After that I selected the bridging code to be compiled as a module as shown
in Example 13.


Example 13. Configuring The Kernel
root@mbb-1:/usr/src/linux-2.2.15 # make config                               
                                                                             
..                                                                           
                                                                             
*                                                                            
* Code maturity level options                                                
*                                                                            
Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL)  
[N/y/?] Y                                                                    
                                                                             
..                                                                           
                                                                             
                                                                             
802.1d Ethernet Bridging (CONFIG_BRIDGE) [N/y/m/?] (NEW) m                   
                                                                             
..                                                                           
                                                                             

By the way I also selected the drivers of my NIC's to be compiled as modules
which resulted to 3c95x.o and hp100.o.


root@mbb-1:/usr/src/linux-2.2.15 # make dep clean zImage \                   
  modules modules_install zlilo                                              
                                                                             
..                                                                           
                                                                             
root@mbb-1:/usr/src/linux-2.2.15 # init 6                                    
                                                                             

After the reboot happening I started at runlevel 1 leaving all the networking
out of the running system. That gave me the chance to check the setup step by
step.

The command modprobe -v bridge worked without any warnings, so that one was
OK. Next I edited my /etc/modules.conf by aliasing my network card drivers as
shown in Example 14 and Example 15. I didn't need to make use of the options,
all cards where realized proper as I checked by cat /proc/modules, cat /proc/
interrupts and cat /proc/ioports.


Example 14. /etc/modules.conf of mbb-1
# Aliases - specify your hardware                                            
alias eth0             3c59x                                                 
alias eth1             hp100                                                 
alias eth2             hp100                                                 
alias eth3             hp100                                                 
                                                                             


Example 15. /etc/modules.conf of mbb-2
# Aliases - specify your hardware                                            
alias eth0             3c509                                                 
alias eth1             hp100                                                 
alias eth2             hp100                                                 
alias eth3             hp100                                                 
                                                                             

So next thing would have been a step by step setup of the bridge and it's
interfaces. Because I'm lazy I just show the init script I prepared for the
setup.

   
    Important: Of course you'll have do adapt the script to your system, if
    you want to use it. Please remember I'm writing this for the setup of a
    SuSE distribution.
   
Example 16. Bridge Init Script

#! /bin/bash                                                                      
# Copyright (c) 2000 Uwe Böhme.  All rights reserved.                             
#                                                                                 
# Author: Uwe Böhme <uwe@bnhof.de>, 2000                                          
#                                                                                 
#                                                                                 
# /sbin/init.d/bridge                                                             
#                                                                                 
                                                                                  
. /etc/rc.config                                                                  
                                                                                  
return=$rc_done                                                                   
case "$1" in                                                                      
                                                                                  
    start)                                                                        
        echo "Starting service bridge mueb"                                       
        brctl addbr mueb  ||  return=$rc_failed                             (1)   
        brctl setbridgeprio mueb 0 || return=$rc_failed                     (2)   
        brctl addif mueb eth0  ||  return=$rc_failed                        (3)   
        brctl addif mueb eth1  ||  return=$rc_failed                        (4)   
        brctl addif mueb eth2  ||  return=$rc_failed                        (5)   
        brctl addif mueb eth3  ||  return=$rc_failed                        (6)   
        ifconfig eth0 0.0.0.0  ||  return=$rc_failed                        (7)   
        ifconfig eth1 0.0.0.0  ||  return=$rc_failed                        (8)   
        ifconfig eth2 0.0.0.0  ||  return=$rc_failed                        (9)   
        ifconfig eth3 0.0.0.0  ||  return=$rc_failed                        (10)  
        brctl sethello mueb 1  ||  return=$rc_failed                        (11)  
        brctl setmaxage mueb 4  ||  return=$rc_failed                       (12)  
        brctl setfd mueb 4  ||  return=$rc_failed                           (13)  
                                                                                  
        echo -e "$return"                                                         
        ;;                                                                        
                                                                                  
    stop)                                                                         
        echo "Shutting down service bridge mueb"                                  
        brctl delif mueb eth3  ||  return=$rc_failed                        (14)  
        brctl delif mueb eth2  ||  return=$rc_failed                        (15)  
        brctl delif mueb eth1  ||  return=$rc_failed                        (16)  
        brctl delif mueb eth0  ||  return=$rc_failed                        (17)  
        brctl delbr mueb  ||  return=$rc_failed                             (18)  
        rmmod bridge || return=$rc_failed                                   (19)  
                                                                                  
        echo -e "$return"                                                         
        ;;                                                                        
                                                                                  
    status)                                                                       
        ifconfig mueb                                                             
        brctl showbr mueb                                                         
        ;;                                                                        
                                                                                  
    restart)                                                                      
        $0 stop && $0 start || return=$rc_failed                                  
        ;;                                                                        
                                                                                  
    *)                                                                            
        echo "Usage: $0 {start|stop|status|restart}"                              
        exit 1                                                                    
esac                                                                              
                                                                                  
test "$return" = "$rc_done" || exit 1                                             
exit 0                                                                            
                                                                                  

(1) This command creates a new virtual interface (bridge instance) with the
    name mueb and also brings up the bridge module.
       
        Note: At least my system it does. Maybe you have to enable the kernel
        module loader.
       
   
(2) Here the script sets the bridge's priority (relative to other bridges in
    the net) to 0. This is indicating that this bridge will become the root
    bridge as long as there is no other bridge with a lower priority level
    available.
       
        Important: In the init script of the backup bridge this line in
        missing, leaving it with the default priority of 100.
       
   
(3) (4) (5) (6)
    Enslaves the Ethernet interface to become a port in the bridge.
(7) (8) (9) (10)
    Takes away any possibly disturbing IP-address and brings the interface
    up.
(11)Setting the hello time of the bridge to one second makes it possible to
    reduce the maxage value of the bridges inside the network.
(12)Setting the time the a bridge is waiting before starting the takeover
    process to a shorter period.
(13)Forcing the bridge to forward earlier than the default time.
(14)(15)(16)(17)
    Take the Ethernet out of the bridging instance.
(18)Destroy the bridge instance.
(19)Remove the bridge module.

To polish your setup and to be able to reach the bridge from remote you now
can configure your bridge instance as if it would be a physical existing
network interface. You can give it a nice IP with a suitable net-mask. It
doesn't matter from which segment in you net, you will reach the bridge with
this IP-address.
-----------------------------------------------------------------------------

8.3. See It Work

Here I want to show and explain about how the running bridge shows up. The
output Example 17 of bridge@mbb-1 is the output of the primary bridge, while
you see in Example 18 the output of the backup bridge waiting to take over.


Example 17. Status Output Of mbb-1 Fully Up
mueb                                                                                  
 bridge id              0000.0800062815f6                                             
 designated root        0000.0800062815f6                                             
 root port                 0                    path cost                  0          
 max age                   4.00                 bridge max age             4.00       
 hello time                1.00                 bridge hello time          1.00       
 forward delay             4.00                 bridge forward delay       4.00       
 ageing time             300.00                 gc interval                4.00       
 hello timer               0.80                 tcn timer                  0.00       
 topology change timer     0.00                 gc timer                   3.80       
 flags                                                                                
                                                                                      
                                                                                      
eth0 (1)                                                                              
 port id                8001                    state                   forwarding    
 designated root        0000.0800062815f6       path cost                100          
 designated bridge      0000.0800062815f6       message age timer          0.00       
 designated port        8001                    forward delay timer        0.00       
 designated cost           0                    hold timer                 0.80       
 flags                                                                                
                                                                                      
eth1 (2)                                                                              
 port id                8002                    state                   forwarding    
 designated root        0000.0800062815f6       path cost                100          
 designated bridge      0000.0800062815f6       message age timer          0.00       
 designated port        8002                    forward delay timer        0.00       
 designated cost           0                    hold timer                 0.80       
 flags                                                                                
                                                                                      
eth2 (3)                                                                              
 port id                8003                    state                   forwarding    
 designated root        0000.0800062815f6       path cost                100          
 designated bridge      0000.0800062815f6       message age timer          0.00       
 designated port        8003                    forward delay timer        0.00       
 designated cost           0                    hold timer                 0.80       
 flags                                                                                
                                                                                      
eth3 (4)                                                                              
 port id                8004                    state                   forwarding    
 designated root        0000.0800062815f6       path cost                100          
 designated bridge      0000.0800062815f6       message age timer          0.00       
 designated port        8004                    forward delay timer        0.00       
 designated cost           0                    hold timer                 0.80       
 flags                                                                                
                                                                                      


Example 18. Status Output Of mbb-2 Fully Up
mueb                                                                                  
 bridge id              0064.00a024d04cd6                                             
 designated root        0000.0800062815f6                                             
 root port                 1                    path cost                100          
 max age                   4.00                 bridge max age             4.00       
 hello time                1.00                 bridge hello time          1.00       
 forward delay             4.00                 bridge forward delay       4.00       
 ageing time             300.00                 gc interval                4.00       
 hello timer               0.00                 tcn timer                  0.00       
 topology change timer     0.00                 gc timer                   2.39       
 flags                                                                                
                                                                                      
                                                                                      
eth0 (1)                                                                              
 port id                8001                    state                   forwarding    
 designated root        0000.0800062815f6       path cost                100          
 designated bridge      0000.0800062815f6       message age timer          0.42       
 designated port        8001                    forward delay timer        0.00       
 designated cost           0                    hold timer                 0.00       
 flags                                                                                
                                                                                      
eth1 (2)                                                                              
 port id                8002                    state                   blocking      
 designated root        0000.0800062815f6       path cost                100          
 designated bridge      0000.0800062815f6       message age timer          0.42       
 designated port        8002                    forward delay timer        0.00       
 designated cost           0                    hold timer                 0.00       
 flags                                                                                
                                                                                      
eth2 (3)                                                                              
 port id                8003                    state                   blocking      
 designated root        0000.0800062815f6       path cost                100          
 designated bridge      0000.0800062815f6       message age timer          0.42       
 designated port        8003                    forward delay timer        0.00       
 designated cost           0                    hold timer                 0.00       
 flags                                                                                
                                                                                      
eth3 (4)                                                                              
 port id                8004                    state                   blocking      
 designated root        0000.0800062815f6       path cost                100          
 designated bridge      0000.0800062815f6       message age timer          0.42       
 designated port        8004                    forward delay timer        0.00       
 designated cost           0                    hold timer                 0.00       
 flags                                                                                
                                                                                      

If you take a glance into /var/log/messages as shown in Example 19 and in 
Example 20 you can see how the bridges are coming up and deciding how to do
their duty. mbb-1 has a lower value for bridge-priority (see  (9) ), telling
it to try to become the root bridge. As you can see mbb-1 forwards all ports,
while mbb-2 blocks all ports with the exception of eth0.


Example 19. mbb-1 Messages From init 2
May 25 16:46:04 mbb-1 init: Switching to runlevel: 2                         
May 25 16:46:04 mbb-1 kernel: NET4: Ethernet Bridge 008 for NET4.0           
May 25 16:46:04 mbb-1 kernel: device eth0 entered promiscuous mode           
May 25 16:46:04 mbb-1 kernel: device eth1 entered promiscuous mode           
May 25 16:46:04 mbb-1 kernel: device eth2 entered promiscuous mode           
May 25 16:46:04 mbb-1 kernel: device eth3 entered promiscuous mode           
May 25 16:46:04 mbb-1 kernel: mueb: port 4(eth3) entering listening state    
May 25 16:46:04 mbb-1 kernel: mueb: port 3(eth2) entering listening state    
May 25 16:46:04 mbb-1 kernel: mueb: port 2(eth1) entering listening state    
May 25 16:46:04 mbb-1 kernel: mueb: port 1(eth0) entering listening state    
May 25 16:46:08 mbb-1 kernel: mueb: port 4(eth3) entering learning state     
May 25 16:46:08 mbb-1 kernel: mueb: port 3(eth2) entering learning state     
May 25 16:46:08 mbb-1 kernel: mueb: port 2(eth1) entering learning state     
May 25 16:46:08 mbb-1 kernel: mueb: port 1(eth0) entering learning state     
May 25 16:46:12 mbb-1 kernel: mueb: port 4(eth3) entering forwarding state   
May 25 16:46:12 mbb-1 kernel: mueb: topology change detected, propagating    
May 25 16:46:12 mbb-1 kernel: mueb: port 3(eth2) entering forwarding state   
May 25 16:46:12 mbb-1 kernel: mueb: topology change detected, propagating    
May 25 16:46:12 mbb-1 kernel: mueb: port 2(eth1) entering forwarding state   
May 25 16:46:12 mbb-1 kernel: mueb: topology change detected, propagating    
May 25 16:46:12 mbb-1 kernel: mueb: port 1(eth0) entering forwarding state   
May 25 16:46:12 mbb-1 kernel: mueb: topology change detected, propagating    
                                                                             


Example 20. mbb-2 Messages From init 2
Jun  8 06:06:16 mbb-2 init: Switching to runlevel: 2                         
Jun  8 06:06:17 mbb-2 kernel: NET4: Ethernet Bridge 008 for NET4.0           
Jun  8 06:06:17 mbb-2 kernel: device eth0 entered promiscuous mode           
Jun  8 06:06:17 mbb-2 kernel: device eth1 entered promiscuous mode           
Jun  8 06:06:17 mbb-2 kernel: device eth2 entered promiscuous mode           
Jun  8 06:06:17 mbb-2 kernel: device eth3 entered promiscuous mode           
Jun  8 06:06:17 mbb-2 kernel: mueb: port 4(eth3) entering listening state    
Jun  8 06:06:17 mbb-2 kernel: mueb: port 3(eth2) entering listening state    
Jun  8 06:06:17 mbb-2 kernel: mueb: port 2(eth1) entering listening state    
Jun  8 06:06:17 mbb-2 kernel: mueb: port 1(eth0) entering listening state    
Jun  8 06:06:17 mbb-2 kernel: mueb: port 2(eth1) entering blocking state     
Jun  8 06:06:17 mbb-2 kernel: mueb: port 3(eth2) entering blocking state     
Jun  8 06:06:17 mbb-2 kernel: mueb: port 4(eth3) entering blocking state     
Jun  8 06:06:21 mbb-2 kernel: mueb: port 1(eth0) entering learning state     
Jun  8 06:06:25 mbb-2 kernel: mueb: port 1(eth0) entering forwarding state   
                                                                             
-----------------------------------------------------------------------------

8.4. Bridge Tests

To check if really all the promised features are working, I did some crude
test. The message logs are shown here in.
-----------------------------------------------------------------------------

8.4.1. Tear The Patch Wire Test

I think just taking a patch wire out of a bridge port is a really good real
survival test. So I pulled the plugs one by one out of the sockets and looked
what happened. To give you not too much tension let me summarize first: It's
really working. All the takeovers happened within less then 12 seconds.

The really interesting messages you can find at mbb-2. To see how everything
comes up, I stopped network services first. In Example 21 you will see the
messages caused by a init 2 followed by a "take out the plug, wait what
happens, then place it back" in the order eth3, eth2, eth1, eth0 .

   
    Note: The thing I did, was making the tests, and publishing the dump. The
    one writing the nice explanations was Lennert again.
   
Example 21. mbb-2 Message Output Of Bridge Test
Jun  8 06:06:16 mbb-2 init: Switching to runlevel: 2                                            
Jun  8 06:06:17 mbb-2 kernel: NET4: Ethernet Bridge 008 for NET4.0                              
Jun  8 06:06:17 mbb-2 kernel: device eth0 entered promiscuous mode                              
Jun  8 06:06:17 mbb-2 kernel: device eth1 entered promiscuous mode                              
Jun  8 06:06:17 mbb-2 kernel: device eth2 entered promiscuous mode                              
Jun  8 06:06:17 mbb-2 kernel: device eth3 entered promiscuous mode                              
Jun  8 06:06:17 mbb-2 kernel: mueb: port 4(eth3) entering listening state                       
Jun  8 06:06:17 mbb-2 kernel: mueb: port 3(eth2) entering listening state                       
Jun  8 06:06:17 mbb-2 kernel: mueb: port 2(eth1) entering listening state                       
Jun  8 06:06:17 mbb-2 kernel: mueb: port 1(eth0) entering listening state                 (1)   
Jun  8 06:06:17 mbb-2 kernel: mueb: port 2(eth1) entering blocking state                        
Jun  8 06:06:17 mbb-2 kernel: mueb: port 3(eth2) entering blocking state                        
Jun  8 06:06:17 mbb-2 kernel: mueb: port 4(eth3) entering blocking state                        
Jun  8 06:06:21 mbb-2 kernel: mueb: port 1(eth0) entering learning state                        
Jun  8 06:06:25 mbb-2 kernel: mueb: port 1(eth0) entering forwarding state                (2)   
Jun  8 06:07:15 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 4(eth3) (3)   
Jun  8 06:07:15 mbb-2 kernel: mueb: port 4(eth3) entering listening state                 (4)   
Jun  8 06:07:19 mbb-2 kernel: mueb: port 4(eth3) entering learning state                  (5)   
Jun  8 06:07:23 mbb-2 kernel: mueb: port 4(eth3) entering forwarding state                (6)   
Jun  8 06:07:23 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu            (7)   
Jun  8 06:08:51 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu            (8)   
Jun  8 06:08:51 mbb-2 kernel: mueb: port 4(eth3) entering blocking state                  (9)   
Jun  8 06:09:22 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 3(eth2) (10)  
Jun  8 06:09:22 mbb-2 kernel: mueb: port 3(eth2) entering listening state                       
Jun  8 06:09:26 mbb-2 kernel: mueb: port 3(eth2) entering learning state                        
Jun  8 06:09:30 mbb-2 kernel: mueb: port 3(eth2) entering forwarding state                      
Jun  8 06:09:30 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu                  
Jun  8 06:10:09 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu                  
Jun  8 06:10:09 mbb-2 kernel: mueb: port 3(eth2) entering blocking state                        
Jun  8 06:10:10 mbb-2 kernel: mueb: retransmitting tcn bpdu                               (11)  
Jun  8 06:10:41 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 2(eth1) (12)  
Jun  8 06:10:41 mbb-2 kernel: mueb: port 2(eth1) entering listening state                       
Jun  8 06:10:45 mbb-2 kernel: mueb: port 2(eth1) entering learning state                        
Jun  8 06:10:49 mbb-2 kernel: mueb: port 2(eth1) entering forwarding state                      
Jun  8 06:10:49 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu                  
Jun  8 06:11:06 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu                  
Jun  8 06:11:06 mbb-2 kernel: mueb: port 2(eth1) entering blocking state                        
Jun  8 06:11:33 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 1(eth0) (13)  
Jun  8 06:11:33 mbb-2 kernel: mueb: port 2(eth1) entering listening state                       
Jun  8 06:11:37 mbb-2 kernel: mueb: port 2(eth1) entering learning state                        
Jun  8 06:11:41 mbb-2 kernel: mueb: port 2(eth1) entering forwarding state                      
Jun  8 06:11:41 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu                  
Jun  8 06:14:18 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu                  
Jun  8 06:14:18 mbb-2 kernel: mueb: port 2(eth1) entering blocking state                        
Jun  8 06:14:19 mbb-2 kernel: mueb: retransmitting tcn bpdu                                     
                                                                                                

(1) The kernel sees that there are already bridges (actually, only one of
    them, but Hello packets are coming in on all 4 of the ports) on eth
    [0123].
(2) To maintain connectivity with the rest of the network, the bridge decides
    to keep port 1 (eth0) active (i.e. in the "forwarding" state), and to
    temporarily disable ports 2-4.
(3) The plug on eth3 was pulled. Here you can see that the message age timer
    expired ( (13)). The last Hello packet was seen more than X seconds ago.
    The bridge concludes that the connection to the bridge that was there has
    died. Therefore, it is going to try to enable this port, to provide
    network connectivity to the now-cutoff segment.
(4) It enters the listening state. It waits to see whether the old bridge
    might come back, or whether another bridge is going to claim takeover.
(5) Okay, no other bridge was seen. We're going to try to provide network
    connectivity to this segment ourselves. Which means: we're going to try
    and become "designated bridge" for this segment. We now enter the
    learning state. In this state, we only learn MAC addresses and we do not
    forward yet. This is because if we see an unknown destination address, we
    send the datagram to all ports, and this "flooding" will happen
    unnecessarily often if we have a empty MAC table. Therefore, we're going
    to fill up our MAC table with useful entries first, and this is what
    happens during the learning state.
(6) Okay, here we go. Pray for us.
(7) Because we took over for this segment, all communication towards this
    segment now goes through this bridge. This means that the topology has
    changed. If the topology changes, we must let all bridges now, so that
    they can time out stale MAC address location data quickly. This is why we
    send Topology Change Notification Bridge Protocol Data Units (tcn bpdus).
    Apparently the root bridge immediately acknowledges this tcn bpdu in the
    next Hello message it sends (the protocol requires for the root bridge to
    acknowledge it), because this is the only such message we see.
       
        Note: In situations where you see loads of these messages, it means
        that the root bridge cannot acknowledge them, which probably means
        your root bridge has a twisted STP implementation.
       
   
(8) Hey, something happened again!
(9) Yup... eth3 came back online. The root bridge will provide connectivity
    for this segment again, so that we can disable this port.
(10) (12)(13)
    Same story for eth2, eth1 and eth0.
(11)This means the tcn bpdu wasn't acknowledged quick enough. That is why it
    is retransmitted.

The root bridge mbb-1 was not so chatty. It only reported some topology
changes and propagated them as you can see in Example 22. If somebody can
offer a explanation why the root bridge is so quiet in messaging please
[mailto:uwe@bnhof] tell me.


Example 22. mbb-2 Message Output Of Bridge Test
Jun  8 06:06:52 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun  8 06:06:52 mbb-1 kernel: mueb: topology change detected, propagating    
Jun  8 06:07:31 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun  8 06:07:31 mbb-1 kernel: mueb: topology change detected, propagating    
Jun  8 06:07:32 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun  8 06:07:32 mbb-1 kernel: mueb: topology change detected, propagating    
Jun  8 06:08:11 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun  8 06:08:11 mbb-1 kernel: mueb: topology change detected, propagating    
Jun  8 06:08:29 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun  8 06:08:29 mbb-1 kernel: mueb: topology change detected, propagating    
Jun  8 06:09:03 mbb-1 kernel: mueb: received tcn bpdu on port 2(eth1)        
Jun  8 06:09:03 mbb-1 kernel: mueb: topology change detected, propagating    
Jun  8 06:11:40 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun  8 06:11:40 mbb-1 kernel: mueb: topology change detected, propagating    
Jun  8 06:11:41 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun  8 06:11:41 mbb-1 kernel: mueb: topology change detected, propagating    
                                                                             

One of the other bridges tells us that the topology of the LAN has changed
(see Example 21). Well, okay. We will set lower timeouts on our MACC table
for a short period of time, and we will propagate this topology change
throughout the network.
-----------------------------------------------------------------------------

8.4.2. Kill The Root Bridge Test

The ultimate test is of course a total blocking, breakdown or something
similar to the root bridge. I did this by shooting down the root bridge by 
init 1. Next I brought it up again with init 2. Last I pulled all plugs out
of the root bridge and waited for some time before I placed them again. In 
Example 23 you will see the messages from the master-bridge mbb-1, and in 
Example 24 you see what happened the same time at the backup-bridge mbb-2.


Example 23. Test Messages Of Master Bridge mbb-1
Jun 12 13:35:15 mbb-1 init: Switching to runlevel: 1                         
Jun 12 13:35:20 mbb-1 kernel: mueb: port 4(eth3) entering disabled state     
Jun 12 13:35:20 mbb-1 kernel: mueb: port 3(eth2) entering disabled state     
Jun 12 13:35:20 mbb-1 kernel: mueb: port 2(eth1) entering disabled state     
Jun 12 13:35:20 mbb-1 kernel: mueb: port 1(eth0) entering disabled state     
Jun 12 13:35:20 mbb-1 kernel: mueb: port 2(eth1) entering disabled state     
Jun 12 13:35:20 mbb-1 kernel: device eth1 left promiscuous mode              
Jun 12 13:35:20 mbb-1 kernel: mueb: port 1(eth0) entering disabled state     
Jun 12 13:35:20 mbb-1 kernel: device eth0 left promiscuous mode              
Jun 12 13:35:20 mbb-1 kernel: mueb: port 4(eth3) entering disabled state     
Jun 12 13:35:20 mbb-1 kernel: device eth3 left promiscuous mode              
Jun 12 13:35:20 mbb-1 kernel: mueb: port 3(eth2) entering disabled state     
Jun 12 13:35:20 mbb-1 kernel: device eth2 left promiscuous mode              
Jun 12 13:35:50 mbb-1 init: Switching to runlevel: 2                         
Jun 12 13:35:50 mbb-1 kernel: NET4: Ethernet Bridge 008 for NET4.0           
Jun 12 13:35:51 mbb-1 kernel: device eth0 entered promiscuous mode           
Jun 12 13:35:51 mbb-1 kernel: device eth1 entered promiscuous mode           
Jun 12 13:35:51 mbb-1 kernel: device eth2 entered promiscuous mode           
Jun 12 13:35:51 mbb-1 kernel: device eth3 entered promiscuous mode           
Jun 12 13:35:51 mbb-1 kernel: mueb: port 4(eth3) entering listening state    
Jun 12 13:35:51 mbb-1 kernel: mueb: port 3(eth2) entering listening state    
Jun 12 13:35:51 mbb-1 kernel: mueb: port 2(eth1) entering listening state    
Jun 12 13:35:51 mbb-1 kernel: mueb: port 1(eth0) entering listening state    
Jun 12 13:35:51 mbb-1 kernel: mueb: received tcn bpdu on port 2(eth1)        
Jun 12 13:35:51 mbb-1 kernel: mueb: topology change detected, propagating    
Jun 12 13:35:52 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun 12 13:35:52 mbb-1 kernel: mueb: topology change detected, propagating    
Jun 12 13:35:55 mbb-1 kernel: mueb: port 4(eth3) entering learning state     
Jun 12 13:35:55 mbb-1 kernel: mueb: port 3(eth2) entering learning state     
Jun 12 13:35:55 mbb-1 kernel: mueb: port 2(eth1) entering learning state     
Jun 12 13:35:55 mbb-1 kernel: mueb: port 1(eth0) entering learning state     
Jun 12 13:35:59 mbb-1 kernel: mueb: port 4(eth3) entering forwarding state   
Jun 12 13:35:59 mbb-1 kernel: mueb: topology change detected, propagating    
Jun 12 13:35:59 mbb-1 kernel: mueb: port 3(eth2) entering forwarding state   
Jun 12 13:35:59 mbb-1 kernel: mueb: topology change detected, propagating    
Jun 12 13:35:59 mbb-1 kernel: mueb: port 2(eth1) entering forwarding state   
Jun 12 13:35:59 mbb-1 kernel: mueb: topology change detected, propagating    
Jun 12 13:35:59 mbb-1 kernel: mueb: port 1(eth0) entering forwarding state   
Jun 12 13:35:59 mbb-1 kernel: mueb: topology change detected, propagating    
Jun 12 13:39:03 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun 12 13:39:03 mbb-1 kernel: mueb: topology change detected, propagating    
Jun 12 13:39:05 mbb-1 kernel: mueb: received tcn bpdu on port 1(eth0)        
Jun 12 13:39:05 mbb-1 kernel: mueb: topology change detected, propagating    
                                                                             

Example 24. Test Messages Of Backup Bridge mbb-2
Jun 12 13:35:21 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 4(eth3) 
Jun 12 13:35:21 mbb-2 kernel: mueb: port 4(eth3) entering listening state                 
Jun 12 13:35:21 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 3(eth2) 
Jun 12 13:35:21 mbb-2 kernel: mueb: port 3(eth2) entering listening state                 
Jun 12 13:35:21 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 2(eth1) 
Jun 12 13:35:21 mbb-2 kernel: mueb: port 2(eth1) entering listening state                 
Jun 12 13:35:21 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 1(eth0) 
Jun 12 13:35:21 mbb-2 kernel: mueb: topology change detected, propagating                 
Jun 12 13:35:25 mbb-2 kernel: mueb: port 4(eth3) entering learning state                  
Jun 12 13:35:25 mbb-2 kernel: mueb: port 3(eth2) entering learning state                  
Jun 12 13:35:25 mbb-2 kernel: mueb: port 2(eth1) entering learning state                  
Jun 12 13:35:29 mbb-2 kernel: mueb: port 4(eth3) entering forwarding state                
Jun 12 13:35:29 mbb-2 kernel: mueb: topology change detected, propagating                 
Jun 12 13:35:29 mbb-2 kernel: mueb: port 3(eth2) entering forwarding state                
Jun 12 13:35:29 mbb-2 kernel: mueb: topology change detected, propagating                 
Jun 12 13:35:29 mbb-2 kernel: mueb: port 2(eth1) entering forwarding state                
Jun 12 13:35:29 mbb-2 kernel: mueb: topology change detected, propagating                 
Jun 12 13:35:49 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu            
Jun 12 13:35:49 mbb-2 kernel: mueb: port 3(eth2) entering blocking state                  
Jun 12 13:35:49 mbb-2 kernel: mueb: topology change detected, \                           
                              <6>mueb: port 4(eth3) entering blocking state               
Jun 12 13:35:49 mbb-2 kernel: mueb: topology change detected, \                           
                              <6>mueb: port 2(eth1) entering blocking state               
Jun 12 13:35:50 mbb-2 kernel: mueb: retransmitting tcn bpdu                               
Jun 12 13:38:26 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 2(eth1) 
Jun 12 13:38:26 mbb-2 kernel: mueb: port 2(eth1) entering listening state                 
Jun 12 13:38:27 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 3(eth2) 
Jun 12 13:38:27 mbb-2 kernel: mueb: port 3(eth2) entering listening state                 
Jun 12 13:38:28 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 4(eth3) 
Jun 12 13:38:28 mbb-2 kernel: mueb: port 4(eth3) entering listening state                 
Jun 12 13:38:30 mbb-2 kernel: mueb: port 2(eth1) entering learning state                  
Jun 12 13:38:30 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 1(eth0) 
Jun 12 13:38:30 mbb-2 kernel: mueb: topology change detected, propagating                 
Jun 12 13:38:31 mbb-2 kernel: mueb: port 3(eth2) entering learning state                  
Jun 12 13:38:32 mbb-2 kernel: mueb: port 4(eth3) entering learning state                  
Jun 12 13:38:34 mbb-2 kernel: mueb: port 2(eth1) entering forwarding state                
Jun 12 13:38:34 mbb-2 kernel: mueb: topology change detected, propagating                 
Jun 12 13:38:35 mbb-2 kernel: mueb: port 3(eth2) entering forwarding state                
Jun 12 13:38:35 mbb-2 kernel: mueb: topology change detected, propagating                 
Jun 12 13:38:36 mbb-2 kernel: mueb: port 4(eth3) entering forwarding state                
Jun 12 13:38:36 mbb-2 kernel: mueb: topology change detected, propagating                 
Jun 12 13:39:01 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu            
Jun 12 13:39:01 mbb-2 kernel: mueb: port 3(eth2) entering blocking state                  
Jun 12 13:39:01 mbb-2 kernel: mueb: topology change detected, \                           
                              <6>mueb: port 4(eth3) entering blocking state               
Jun 12 13:39:02 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu            
Jun 12 13:39:02 mbb-2 kernel: mueb: port 2(eth1) entering blocking state                  
                                                                                          

-----------------------------------------------------------------------------
A. Network Interface Cards

In this section you will find a (for now) very incomplete list of NIC's which
are known to work or known to cause problem. For I neither have the money to
buy a lot of different NIC's, nor I have any connections to hardware vendors,
I depend on your feedback to keep the list accurate. So feel free to mail
about success or failure to [mailto:uwe@bnhof.de] Uwe Böhme.

Valuing Of NIC Information

- - -
    Cards I tried and are also reported not to work by other people
   
- -
    Cards I tried or are reported not to work by other people
   
-
    Cards reported not to work by other people
   
+
    Cards reported to work by other people
   
+ +
    Cards I tried or are reported to work by other people
   
+ + +
    Cards I tried and are also reported to work by other people
   

NIC Information

3c509b Etherlink III
    + +
   
3c905b/3c905c
    + + + Never heard about any problem
   
HP J2585A
    - - System hang-up after ifconfig, unable to run promisc mode
   
HP J2585B
    + +
   
AMD PCnet32 10/100
    + +
   
RTL (Realtek) 8029
    + +
   

-----------------------------------------------------------------------------
B. Recommended Reading

Here you will some recommendations which documents you should read before you
start to setup a bridge.

[http://www.math.leidenuniv.nl/~buytenh/bridge/] The bridge home-page
    Will give you recent information about the bridging code and the bridge
    utilities.
   
[http://www.linuxdoc.org/HOWTO/NET3-4-HOWTO.html] http://www.linuxdoc.org/
    HOWTO/NET3-4-HOWTO
    Describes how to install and configure the Linux networking software and
    associated tools.
   
[http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html] http://www.linuxdoc.org//
    HOWTO/Ethernet-HOWTO
    Information about which Ethernet devices can be used for Linux, and how
    to set them up (focused on the hardware and low level driver aspect of
    the Ethernet cards).
   

-----------------------------------------------------------------------------
C. FAQ

Here you will find some of the frequently asked questions connected to
bridging.

FAQ

1. Hardware
    What hardware do I need to run a bridge with 2-n NICs.
    Can you please recommend some tools to measure a 2-port linux bridge
        throughput.
   
   
2. Software
    I'm running with kernel x.x.x. Is a patch out there, to give me chance to
        use this stuff?
   
   

1. Hardware

What hardware do I need to run a bridge with 2-n NICs.

I think a fat 486 or a modest Pentium should be able to keep up with
2x100Mbit pretty well, but I have never tested this. I don't think RAM will
matter much (8 or 16MB and all should be fine). CPU will not matter a whole
lot either (486/Pentium and all should be fine). I think the primary
contributor is the type of bus (ISA, PCI) and the type of network cards (some
network cards require less "work" than others). Big switches usually have
immensely fat internal buses (3 or 4 gigabits is not uncommon). Standard PCI,
for example, can't keep up with a gigabit ethernet cards.

Can you please recommend some tools to measure a 2-port linux bridge
throughput.

Well, first question is: does it have 100mbit interfaces? If it hasn't
(10mbit only), it shouldn't have problems with keeping up, almost regardless
of the processor speed. If it does have 100mbit interfaces and you're not
sure it will keep up, you can run a flood ping with big packets across it (
ping -f -s 1450 ipaddress) and see whether it keeps up.

2. Software

I'm running with kernel x.x.x. Is a patch out there, to give me chance to use
this stuff?

There are patches for and 2.2.14, 2.2.15. Since 2.3.47 it's in the mainstream
kernel, so you don't need to patch. If you're talking about others, you will
have to upgrade, if you need to bridge.

   
    Note: I've heared unconfirmed roumors about the 2.2.15 patches working
    without any change also with the 2.2.16 kernel. Anyone mind telling me
    about it?
   
