
Linux BRIDGE-STP-HOWTO

Uwe Bhme

             Johann-Heinrich-Abt-Strae 7
             95213
             Mnchberg
             Germany
             +49/9251 960877
             +49/9251 960878
             uwe@bnhof.de
   
Lennert Buytenhenk

   bridge code maintainer and developer
   gnu.org
   
             buytenh@gnu.org
   
   Still draft
   
   Copyright  2000 by Uwe Bhme
   Revision History
   Revision v0.00 01 June 2000 Revised by: U.B.
   Initial Release.
   Revision v1.01 07 June 2000 Revised by: U.B.
   Applied patch from Lennert. Corrected some syntactical errors.
   Completed some brctl commands. Added test output and description.
   Revision v1.02 08 June 2000 Revised by: U.B.
   More typo and grammar corrections.
   Revision v1.03 09 June 2000 Revised by: U.B.
   The usual typo. Applied Lennert's explanations about the message logs
   of the pull-the-plug-test.
   Revision v1.04 11 June 2000 Revised by: U.B.
   The usual typo. Applied ultimate test dumps.
   Revision v1.05 17 June 2000 Revised by: U.B.
   System freeze remark. Modified style sheet.
   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 restart Version numbering
   (we where already too far). Lennert Buytenhenk announced as coauthor.
     _________________________________________________________________
   
   Table of Contents
   1. [1]License
   2. [2]What Is A Bridge?
   3. [3]Rules On Bridging
   4. [4]Preparing The Bridge
          
        4.1. [5]Get The Files
        4.2. [6]Apply The Patches
        4.3. [7]Configure The Kernel
        4.4. [8]Compile The Kernel
        4.5. [9]Compile The Bridge Utilities
                
   5. [10]Set Up The Bridge
          
        5.1. [11]brctl Command Synopsis
        5.2. [12]Basic Setup
                
   6. [13]Advanced Bridge Features
          
        6.1. [14]Spanning Tree Protocol
        6.2. [15]Bridge And The IP-Chains
                
   7. [16]A Practical Setup Example
          
        7.1. [17]Hardware-setup
        7.2. [18]Software-setup
        7.3. [19]See It Work
        7.4. [20]Bridge Tests
                
   Appendix A. [21]Network Interface Cards
   Appendix B. [22]Recommended Reading
   Appendix C. [23]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. With developer kernel
   2.3.47 the new bridging code is part of the mainstream. On 20.06.2000
   there are patches for stable kernels 2.2.14 and 2.2.15. What happend
   if a penguin crosses a bridge?
     _________________________________________________________________
   
1. License

   Copyright (c) 2000 by Uwe Bhme. This document may be distributed only
   subject to the terms and conditions set forth in the [24]LDP License
   available at [25]http://sunsite.unc.edu/LDP/LICENSE.html
     _________________________________________________________________
   
2. What Is A Bridge?

   A bridge is a device that separates two or more network segments
   within one logical network (e.g. 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, bat nearly). Read more about
   this at [26]Section 3.
   
   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 [27]Section 6.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 [28]Section 6.2.
     _________________________________________________________________
   
3. Rules On Bridging

   There is a number of rules you are not allowed to break (otherwise
   your bridge does).
   
     * 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 [29]Appendix 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 [30]Section 5.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.
     _________________________________________________________________
   
4. Preparing The Bridge

   This section describes what you need and how you do to prepare your
   bridge.
     _________________________________________________________________
   
4.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.
   
   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
          [31]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
          [32]http://www.openrock.net/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. 
          + [33]bridge-0.0.5-against-2.2.14.diff
          + [34]bridge-0.0.5-against-2.2.15.diff
            
   Bridge configuration utilities
          You also will need the bridge configuration utilities to set up
          the bridge [35]Section 5. You can also download them from
          [36]http://www.openrock.net/bridge/. The current one (as of
          this writing) is bridge-utils-0.9.1.tar.gz.
          [37]bridge-utils-0.9.1.tar.gz.
     _________________________________________________________________
   
4.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
   [38]http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX.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
.
.
     _________________________________________________________________
   
4.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
.
     _________________________________________________________________
   
4.4. Compile The Kernel

   Compile your kernel [39]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_instal
l zlilo
...
     _________________________________________________________________
   
4.5. Compile The Bridge Utilities

   There is no magic about it. 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 [40]Example 3 have worked properly, you
   can copy the executables to let's say /usr/sbin/ (at least I did). So
   the commands you have to give should be clear, but to be complete see
   [41]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/bin/local
root@mbb-1:/usr/local/src/bridge/brctl # chmod 700 /usr/bin/local/brctl
root@mbb-1:/usr/local/src/bridge/brctl # cp brctld /usr/bin/local
root@mbb-1:/usr/local/src/bridge/brctl # chmod 700 /usr/bin/local/brctld

   Also now you can copy the new man-page to a decent place, as shown in
   [42]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/b
rctl.8.gz
     _________________________________________________________________
   
5. 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
   [43]http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX.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. 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.
     _________________________________________________________________
   
5.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         (1
0)
    setgcint        <bridge> <time>         set garbage collection interval  (1
1)
    sethello        <bridge> <time>         set hello time                   (1
2)
    setmaxage       <bridge> <time>         set max message age              (1
3)
    setpathcost     <bridge> <port> <cost>  set path cost                    (1
4)
    setportprio     <bridge> <port> <prio>  set port priority                (1
5)
    stp             <bridge> <state>        {dis,en}able stp                 (1
6)

   [44](1) [45](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.
   [46](2) [47](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
   [48](5) 
          The brctl show command gives you a summary about the overall
          bridge status, and the instances running as shown in
          [49]Example 7. If you are interested in detailed information
          about a instance and it's interfaces you will have to check
          [50](6) .
          
   Example 7. Output Of brctl show
root@mbb-1:~ # brctl show
bridge name     bridge id               stp enabled
mybridge1       0000.0800062815f6       yes


   [51](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                   forward
ing
 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                   forward
ing
 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


   [52](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


   [53](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.
   [54](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 [55]Section 6.1.
   [56](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.
   [57](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.
   [58](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 [59]Section
          6.1.
   [60](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
          [61]Section 6.1.
   [62](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
          [63]Section 6.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.
   [64](16) 
          With this parameter you can enable or disable the Spanning Tree
          Protocol.
   [65](9) [66](12) [67](14) [68](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 [69]Section 6.1.
     _________________________________________________________________
   
5.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. 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.
       
root@mbb-1:~ # ifconfig mybridge 192.168.100.5 netmask 255.255.255.0 up


   A more sophisticated setup script you will find at [70]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.
     _________________________________________________________________
   
6. Advanced Bridge Features

   Here we will cover some advanced features of the new bridge code.
     _________________________________________________________________
   
6.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

   [71]Could you give me some hints about multi-bridge scenarios. 
   [72]Does the STP "heartbeat" mechanism also work with bridges with
          more than two cards? 
          
   [73]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.
   
   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 [74]Section 7.
     _________________________________________________________________
   
6.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 [75]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)

   [76](1) 
          Creating a bridge interface named br0
   [77](2) [78](3) 
          Placing eth0 and eth1 into the bridge.
   [79](4) 
          Assigning a regular IP address to the bridge. The IP is taken
          from private network 10.X.X.X (Class A).
   [80](5) 
          Creating a ip-chain named br0
   [81](1) [82](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).
   [83](6) 
          Denying all trafic with source 10.X.X.X on eth0.
     _________________________________________________________________
   
7. 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
   [84]Figure 1.
   
   Figure 1. Hardware setup Of The Old Bridge Scenario
   
   [old-hardware-setup.png]
   
   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 [85]Section 6.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 [86]http://openrock.net/bridge IMHO he's doing a great job. Thanks
   a lot.
     _________________________________________________________________
   
7.1. Hardware-setup

   The ideas and hints I got from the mailing list discussion shown in
   [87]Section 6.1 lead to a new hardware-setup shown in [88]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.png]
   
   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 [89]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.
     _________________________________________________________________
   
7.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
   [90]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 [91]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 [92]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 [93]Example 14 and [94]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 Bhme.  All rights reserved.
#
# Author: Uwe Bhme <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

   [95](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.
   [96](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.
   [97](3) [98](4) [99](5) [100](6) 
          Enslaves the Ethernet interface to become a port in the bridge.
   [101](7) [102](8) [103](9) [104](10) 
          Takes away any possibly disturbing IP-address and brings the
          interface up.
   [105](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.
   [106](12) 
          Setting the time the a bridge is waiting before starting the
          takeover process to a shorter period.
   [107](13) 
          Forcing the bridge to forward earlier than the default time.
   [108](14) [109](15) [110](16) [111](17) 
          Take the Ethernet out of the bridging instance.
   [112](18) 
          Destroy the bridge instance.
   [113](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.
     _________________________________________________________________
   
7.3. See It Work

   Here I want to show and explain about how the running bridge shows up.
   The output [114]Example 17 of bridge@mbb-1 is the output of the
   primary bridge, while you see in [115]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                   forward
ing
 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                   forward
ing
 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                   forward
ing
 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                   forward
ing
 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                   forward
ing
 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                   blockin
g
 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                   blockin
g
 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                   blockin
g
 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 [116]Example
   19 and in [117]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 [118](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
     _________________________________________________________________
   
7.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.
     _________________________________________________________________
   
7.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 [119]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 po
rt 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 po
rt 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 po
rt 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 po
rt 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

   4What Lennert Told About This
   [120](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].
   [121](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.
   [122](3) 
          The plug on eth3 was pulled. Here you can see that the message
          age timer expired ([123] (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.
   [124](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.
   [125](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.
   [126](6) 
          Okay, here we go. Pray for us.
   [127](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.
   [128](8) 
          Hey, something happened again!
   [129](9) 
          Yup... eth3 came back online. The root bridge will provide
          connectivity for this segment again, so that we can disable
          this port.
   [130](10) [131](12) [132](13) 
          Same story for eth2, eth1 and eth0.
   [133](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 [134]Example
   22. If somebody can offer a explanation why the root bridge is so
   quiet in messaging please [135]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 [136]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.
     _________________________________________________________________
   
7.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 [137]Example 23 you will see the
   messages from the master-bridge mbb-1, and in [138]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 po
rt 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 po
rt 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 po
rt 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 po
rt 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 po
rt 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 po
rt 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 po
rt 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 po
rt 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
     _________________________________________________________________
   
Appendix 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
   [139]Uwe Bhme.
   
   Table Appendix A-1. NIC Information
   Name Value Comment
   3c509b Etherlink III ++
   3c905b +++ Never heard about any problem
   3c905c ++ Never heard about any problem
   HP J2585A - - System hang-up after ifconfig
   HP J2585B ++
   
   Table Appendix A-2. Valuing Of NIC Information
   Value Meaning
   - - - 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 without any report or experience
   + 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
     _________________________________________________________________
   
Appendix B. Recommended Reading

   Here you will some recommendations which documents you should read
   before you start to setup a bridge.
   
   [140]The bridge home-page
          Will give you recent information about the bridging code and
          the bridge utilities.
          
   [141]NET3-4-HOWTO
          Describes how to install and configure the Linux networking
          software and associated tools.
          
   [142]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).
     _________________________________________________________________
   
Appendix C. FAQ

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

   1. [143]Hardware
          
        [144]What hardware do I need to run a bridge with 2-n NICs. 
        [145]Can you please recommend some tools to measure a 2-port
                linux bridge throughput. 
                
   2. [146]Software
          
        [147]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.

References

   Visible links
   1. bridge-stp-howto/BRIDGE-STP-HOWTO.html#LICENSE
   2. bridge-stp-howto/BRIDGE-STP-HOWTO.html#WHAT-IS-A-BRIDGE
   3. bridge-stp-howto/BRIDGE-STP-HOWTO.html#RULES-ON-BRIDGING
   4. bridge-stp-howto/BRIDGE-STP-HOWTO.html#PREPARING-THE-BRIDGE
   5. bridge-stp-howto/BRIDGE-STP-HOWTO.html#GET-THE-FILES
   6. bridge-stp-howto/BRIDGE-STP-HOWTO.html#APPLY-THE-PATCHES
   7. bridge-stp-howto/BRIDGE-STP-HOWTO.html#CONFIGURE-THE-KERNEL
   8. bridge-stp-howto/BRIDGE-STP-HOWTO.html#COMPILE-THE-KERNEL
   9. bridge-stp-howto/BRIDGE-STP-HOWTO.html#COMPILE-THE-UTILS
  10. bridge-stp-howto/BRIDGE-STP-HOWTO.html#SET-UP-THE-BRIDGE
  11. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SYNOPSIS
  12. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BASIC-SETUP
  13. bridge-stp-howto/BRIDGE-STP-HOWTO.html#ADVANCED-BRIDGE
  14. bridge-stp-howto/BRIDGE-STP-HOWTO.html#STP
  15. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCHAINS
  16. bridge-stp-howto/BRIDGE-STP-HOWTO.html#PRACTICAL-EXAMPLE
  17. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN510
  18. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN529
  19. bridge-stp-howto/BRIDGE-STP-HOWTO.html#SEE-IT-WORK
  20. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRIDGE-TESTS
  21. bridge-stp-howto/BRIDGE-STP-HOWTO.html#NIC-INFO
  22. bridge-stp-howto/BRIDGE-STP-HOWTO.html#RECOMMENDED-READING
  23. bridge-stp-howto/BRIDGE-STP-HOWTO.html#FAX
  24. COPYRIGHT.html
  25. http://sunsite.unc.edu/LDP/LICENSE.html
  26. bridge-stp-howto/BRIDGE-STP-HOWTO.html#RULES-ON-BRIDGING
  27. bridge-stp-howto/BRIDGE-STP-HOWTO.html#STP
  28. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCHAINS
  29. bridge-stp-howto/BRIDGE-STP-HOWTO.html#RECOMMENDED-READING
  30. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BASIC-SETUP
  31. http://www.kernel.org/mirrors/
  32. http://www.openrock.net/bridge/
  33. ftp://openrock.net/bridge/patches/bridge-0.0.5-against-2.2.14.diff
  34. ftp://openrock.net/bridge/patches/bridge-0.0.5-against-2.2.15.diff
  35. bridge-stp-howto/BRIDGE-STP-HOWTO.html#SET-UP-THE-BRIDGE
  36. http://www.openrock.net/bridge/
  37. ftp://openrock.net/bridge/bridge-utils/bridge-utils-0.9.1.tar.gz
  38. http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX.html
  39. bridge-stp-howto/BRIDGE-STP-HOWTO.html#KERNEL-COMPILE-COMMANDS
  40. bridge-stp-howto/BRIDGE-STP-HOWTO.html#UTILS-COMPILE-COMMANDS
  41. bridge-stp-howto/BRIDGE-STP-HOWTO.html#UTILS-COPY-BINARIES
  42. bridge-stp-howto/BRIDGE-STP-HOWTO.html#UTILS-COPY-MANPAGE
  43. http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX.html
  44. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-ADDBR
  45. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-DELBR
  46. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-ADDIF
  47. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-DELIF
  48. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SHOW
  49. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SHOW-OUTPUT
  50. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SHOWBR
  51. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SHOWBR
  52. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SHOWMACS
  53. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETAGEING
  54. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETBRIDGEPRIO
  55. bridge-stp-howto/BRIDGE-STP-HOWTO.html#STP
  56. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETFD
  57. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETGCINT
  58. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETHELLO
  59. bridge-stp-howto/BRIDGE-STP-HOWTO.html#STP
  60. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETMAXAGE
  61. bridge-stp-howto/BRIDGE-STP-HOWTO.html#STP
  62. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETPATHCOST
  63. bridge-stp-howto/BRIDGE-STP-HOWTO.html#STP
  64. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-STP
  65. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETBRIDGEPRIO
  66. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETHELLO
  67. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETPATHCOST
  68. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-STP
  69. bridge-stp-howto/BRIDGE-STP-HOWTO.html#STP
  70. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRIDGE-INIT-SCRIPT
  71. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN409
  72. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN426
  73. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN435
  74. bridge-stp-howto/BRIDGE-STP-HOWTO.html#PRACTICAL-EXAMPLE
  75. http://openrock.net/bridge/
  76. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCH-ADDBR
  77. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCH-ADDIF-ETH0
  78. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCH-ADDIF-ETH1
  79. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCH-IFCONFIG
  80. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCH-ADDCHAIN
  81. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCH-ADDBR
  82. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCH-ADDCHAIN
  83. bridge-stp-howto/BRIDGE-STP-HOWTO.html#IPCH-DEN-ETH0
  84. bridge-stp-howto/BRIDGE-STP-HOWTO.html#OLD-BRIDGE-HARDWARE-SETUP
  85. bridge-stp-howto/BRIDGE-STP-HOWTO.html#STP
  86. http://openrock.net/bridge
  87. bridge-stp-howto/BRIDGE-STP-HOWTO.html#STP
  88. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MULTI-BRIDGE-HARDWARE-SETUP
  89. bridge-stp-howto/BRIDGE-STP-HOWTO.html#OLD-BRIDGE-HARDWARE-SETUP
  90. bridge-stp-howto/BRIDGE-STP-HOWTO.html#APPLY-KERNEL-PATCH
  91. bridge-stp-howto/BRIDGE-STP-HOWTO.html#APPLY-BRIDGE-PATCH
  92. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MENUCONFIG-BRIDGE-MODULE-SELECTION
  93. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MODULES-CONF-NIC-SAMPLE-MBB1
  94. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MODULES-CONF-NIC-SAMPLE-MBB2
  95. bridge-stp-howto/BRIDGE-STP-HOWTO.html#CREATE-BRIDGE
  96. bridge-stp-howto/BRIDGE-STP-HOWTO.html#SET-ROOT-BRIDGE
  97. bridge-stp-howto/BRIDGE-STP-HOWTO.html#ADDIF-ETH0
  98. bridge-stp-howto/BRIDGE-STP-HOWTO.html#ADDIF-ETH1
  99. bridge-stp-howto/BRIDGE-STP-HOWTO.html#ADDIF-ETH2
 100. bridge-stp-howto/BRIDGE-STP-HOWTO.html#ADDIF-ETH3
 101. bridge-stp-howto/BRIDGE-STP-HOWTO.html#UP-ETH0
 102. bridge-stp-howto/BRIDGE-STP-HOWTO.html#UP-ETH1
 103. bridge-stp-howto/BRIDGE-STP-HOWTO.html#UP-ETH2
 104. bridge-stp-howto/BRIDGE-STP-HOWTO.html#UP-ETH3
 105. bridge-stp-howto/BRIDGE-STP-HOWTO.html#HELLO-1
 106. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MAXAGE-4
 107. bridge-stp-howto/BRIDGE-STP-HOWTO.html#FORWARDDELAY-4
 108. bridge-stp-howto/BRIDGE-STP-HOWTO.html#DELIF-ETH3
 109. bridge-stp-howto/BRIDGE-STP-HOWTO.html#DELIF-ETH2
 110. bridge-stp-howto/BRIDGE-STP-HOWTO.html#DELIF-ETH1
 111. bridge-stp-howto/BRIDGE-STP-HOWTO.html#DELIF-ETH0
 112. bridge-stp-howto/BRIDGE-STP-HOWTO.html#DESTROY-BRIDGE
 113. bridge-stp-howto/BRIDGE-STP-HOWTO.html#REMOVE-MODULE
 114. bridge-stp-howto/BRIDGE-STP-HOWTO.html#SAMPLE-BRIDGE-STATUS-MBB1
 115. bridge-stp-howto/BRIDGE-STP-HOWTO.html#SAMPLE-BRIDGE-STATUS-MBB2
 116. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MESSAGES-FROM-INIT-2-AT-MBB-1
 117. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MESSAGES-FROM-INIT-2-AT-MBB-2
 118. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETBRIDGEPRIO
 119. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MBB-2-MESSAGES-OF-BRIDGE-TEST
 120. bridge-stp-howto/BRIDGE-STP-HOWTO.html#SEE-OTHER-BRIDGE
 121. bridge-stp-howto/BRIDGE-STP-HOWTO.html#KEEP-ONE-INTERFACE
 122. bridge-stp-howto/BRIDGE-STP-HOWTO.html#PULL-PLUG-ETH3
 123. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETMAXAGE
 124. bridge-stp-howto/BRIDGE-STP-HOWTO.html#ENTER-LISTEN-STATE
 125. bridge-stp-howto/BRIDGE-STP-HOWTO.html#ENTER-LEARN-STATE
 126. bridge-stp-howto/BRIDGE-STP-HOWTO.html#ENTER-FORWARD-STATE
 127. bridge-stp-howto/BRIDGE-STP-HOWTO.html#TOPOLOGY-CHANGE-DETECT
 128. bridge-stp-howto/BRIDGE-STP-HOWTO.html#TOPOLOGY-CHANGED-AGAIN
 129. bridge-stp-howto/BRIDGE-STP-HOWTO.html#ROOT-IS-BACK
 130. bridge-stp-howto/BRIDGE-STP-HOWTO.html#FROM-PULL-TO-BACK-ETH2
 131. bridge-stp-howto/BRIDGE-STP-HOWTO.html#FROM-PULL-TO-BACK-ETH1
 132. bridge-stp-howto/BRIDGE-STP-HOWTO.html#FROM-PULL-TO-BACK-ETH0
 133. bridge-stp-howto/BRIDGE-STP-HOWTO.html#RETRANSMIT-TCN-BPDU
 134. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MBB-1-MESSAGES-OF-BRIDGE-TEST
 135. mailto:uwe@bnhof
 136. bridge-stp-howto/BRIDGE-STP-HOWTO.html#MBB-2-MESSAGES-OF-BRIDGE-TEST
 137. bridge-stp-howto/BRIDGE-STP-HOWTO.html#TEST-MESSAGES-OF-MASTER-BRIDGE
 138. bridge-stp-howto/BRIDGE-STP-HOWTO.html#TEST-MESSAGES-OF-BACKUP-BRIDGE
 139. mailto:uwe@bnhof.de
 140. http://openrock.net/bridge/
 141. http://www.linuxdoc.org/HOWTO/NET3-4-HOWTO.html
 142. http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html
 143. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN842
 144. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN845
 145. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN852
 146. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN858
 147. bridge-stp-howto/BRIDGE-STP-HOWTO.html#AEN861

   Hidden links:
 148. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SHOWBR
 149. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETBRIDGEPRIO
 150. bridge-stp-howto/BRIDGE-STP-HOWTO.html#BRCTL-SETMAXAGE
