diff --git a/LDP/howto/docbook/BRIDGE-STP-HOWTO/BRIDGE-STP-HOWTO.sgml b/LDP/howto/docbook/BRIDGE-STP-HOWTO/BRIDGE-STP-HOWTO.sgml new file mode 100644 index 00000000..e09f1e79 --- /dev/null +++ b/LDP/howto/docbook/BRIDGE-STP-HOWTO/BRIDGE-STP-HOWTO.sgml @@ -0,0 +1,2519 @@ +MAC"> +STP"> +ARP"> + +]> + +
+ + Linux BRIDGE-STP-HOWTO + About The Linux Modular Bridge And STP + + + + + Uwe + Böhme + +
+ Johann-Heinrich-Abt-Straße 7 + 95213 + Münchberg + Germany + +49/9251 960877 + +49/9251 960878 + uwe@bnhof.de +
+ + + + + Lennert + Buytenhenk + + He made the bridge fly. + + + bridge code maintainer and developer + gnu.org +
+ buytenh@gnu.org +
+ + The source, a lot of useful advice,documentation of STP, + comments to message logs, typo correction,devices and encouragement. + + + + + 2000 + + Uwe Böhme + + + + Still draft + + + + v0.00 + + 01 June 2000 + + U.B. + + Initial Release. + + + + + v1.01 + + 07 June 2000 + + U.B. + + Applied patch from Lennert. + Corrected some syntactical errors. + Completed some brctl commands. + Added test output and description. + + + + + v1.02 + + 08 June 2000 + + U.B. + + More typo and grammar corrections. + + + + + v1.03 + + 09 June 2000 + + U.B. + + The usual typo. + Applied Lennert's explanations about the message logs of the pull-the-plug-test. + + + + + v1.04 + + 11 June 2000 + + U.B. + + The usual typo. + Applied ultimate test dumps. + + + + + v1.05 + + 17 June 2000 + + U.B. + + System freeze remark. Modified style sheet. + + + + + v0.01 + + 25 June 2000 + + 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. + + + + + + + All files are copyrighted by their mentioned + author or organization as mentioned in the file. + This file may be distributed or modified + according to the terms of + LDP + Copyright. + + is based on the introduction to + the BRIDGE-HOWTO by + + Christopher + Cole + +
+ + cole@coledd.com + + +
+ + + Published v1.11, 7 September 1998 with LDP-Copyright. + + + + + + + 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? + + + + + + 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://sunsite.unc.edu/LDP/LICENSE.html + + + + + + 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. + + + + 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 . + + + + 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 + . + + + + + + 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 + . + + + + + + + + + + + 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. + + + + + + If one of the points mentioned above is not clear to you now, + don't continue reading. + Read the documents listed in + 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 . + 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. + + + + + + + Preparing The Bridge + This section describes what you need and how you do to prepare + your bridge. + + + + 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 + The Linux Kernel + Archive Mirror System for a close by mirror and down-load + it from there. + + + + + + Bridge patches + + + 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.openrock.net/bridge/. + Identify the file by the kernel number. + + + + 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 + + + + bridge-0.0.5-against-2.2.14.diff + + + + 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 . + You can also download them from + http://www.openrock.net/bridge/. + The current one (as of this writing) is bridge-utils-0.9.1.tar.gz. + bridge-utils-0.9.1.tar.gz. + + + + + + + + + Apply The Patches + + + 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://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX.html + + + + + 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 +. +. + + + + + + + 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 +. + + + + + + + Compile The Kernel + + Compile your kernel . + 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. + + + + Commands To Compile Your Kernel + +root@mbb-1:/usr/src/linux-2.2.14 # make dep clean zImage modules modules_install zlilo +... + + + + + + + + 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. + + + + 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 + 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 + + + + 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 . + + + + 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 + + + + + + + + + Set Up The Bridge + setup + + 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://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. + + + + <command>brctl</command> Command Synopsis + + + +root@mbb-1:~ # brctl +commands: + addbr <bridge> add bridge + addif <bridge> <device> add interface to bridge + delbr <bridge> delete bridge + delif <bridge> <device> delete interface from bridge + show show a list of bridges + showbr <bridge> show bridge info + showmacs <bridge> show a list of mac addrs + + setageing <bridge> <time> set ageing time + setbridgeprio <bridge> <prio> set bridge priority + setfd <bridge> <time> set bridge forward delay + setgcint <bridge> <time> set garbage collection interval + sethello <bridge> <time> set hello time + setmaxage <bridge> <time> set max message age + setpathcost <bridge> <port> <cost> set path cost + setportprio <bridge> <port> <prio> set port priority + stp <bridge> <state> {dis,en}able stp + + + + + + + + + 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. + + + + Creating A Instance + + + + + The corresponding shutdown command is + brctl delbr bridgename. + + brctl delbr bridgename + will only work, if there are no more interfaces added to the + instance you want to delete. + + + + + + + + + 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 + + + + + + + The brctl show command gives you a summary + about the overall bridge status, and the instances running as + shown in . + If you are interested in detailed information about a instance and + it's interfaces you will have to check . + + + + Output Of <command>brctl show</command> + + + + + + + + + The brctl showbr bridgename + command gives you a summary about a bridge instance and it's enslaved + interfaces. + + + + Output Of <command>brctl showbr <userinput>bridgename</userinput></command> + + + + + + + + + The brctl showmacs bridgename + command gives you a list of &mac;-addresses of the + interfaces which are enslaved in bridgename. + + + + Output Of <command>brctl showmacs <userinput>bridgename</userinput></command> + + + + + + + + + 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. + + + + + + + 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 + . + + + + + + + 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. + + + + + + + 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. + + + + + + + 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 + . + + + + + + + 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 + . + + + + + + + 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 + . + 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. + + + + + + With this parameter you can enable or disable the Spanning Tree + Protocol. + + + + + + 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 + . + + + + + + + + + + Basic Setup + + The standard configuration should consist of: + + + + + + Create the bridge interface. + + + + + + + Add interfaces to the bridge. + + + + + + + Zero IP the interfaces. + + + + + + + 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. + + + + + + + + A more sophisticated setup script you will find at + . + + + + + 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. + + + + + + + + + + + Advanced Bridge Features + + Here we will cover some advanced features of the new bridge code. + + + + Spanning Tree Protocol + STP + + + 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 + + + + + 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. + + + + + 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 + . + + + + + + 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. + + + + If you want to do this, you will need to apply the + special ip-chain-bridge-patch (also available at + 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'. + + + + 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. + + + + + A Simple Bridge Firewall Setup + + +Example: +# brctl addbr br0 +# brctl addif br0 eth0 +# brctl addif br0 eth1 +# ifconfig br0 10.0.0.254 +# ipchains -N br0 +# ipchains -A br0 -s 10.0.0.1/8 -i eth0 -j DENY + + + + + + Creating a bridge interface named br0 + + + + + Placing eth0 and eth1 into the bridge. + + + + + Assigning a regular IP address to the bridge. + The IP is taken from private network 10.X.X.X (Class A). + + + + + Creating a ip-chain named br0 + + + + + + + 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). + + + + + + + Denying all trafic with source 10.X.X.X on eth0. + + + + + + + + + + + + + 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 + . + + +
+ Hardware setup Of The Old Bridge Scenario + Old Bridge 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 + 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://openrock.net/bridge + IMHO he's doing a great job. Thanks a lot. + + + + + Hardware-setup + + The ideas and hints I got from the mailing list discussion shown in + lead to a new hardware-setup shown in + . + 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. + + +
+ Hardware Setup Of The Multi bridge Scenario + Multi bridge 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 + 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. + + + + + + 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 + . + + + + 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 + . + + + + 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 + . + + + + 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 + and + . + 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. + + + + <filename>/etc/modules.conf</filename> of <emphasis>mbb-1</emphasis> + +# Aliases - specify your hardware +alias eth0 3c59x +alias eth1 hp100 +alias eth2 hp100 +alias eth3 hp100 + + + + + <filename>/etc/modules.conf</filename> of <emphasis>mbb-2</emphasis> + +# 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. + + + 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. + + + + + + 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 + brctl setbridgeprio mueb 0 || return=$rc_failed + brctl addif mueb eth0 || return=$rc_failed + brctl addif mueb eth1 || return=$rc_failed + brctl addif mueb eth2 || return=$rc_failed + brctl addif mueb eth3 || return=$rc_failed + ifconfig eth0 0.0.0.0 || return=$rc_failed + ifconfig eth1 0.0.0.0 || return=$rc_failed + ifconfig eth2 0.0.0.0 || return=$rc_failed + ifconfig eth3 0.0.0.0 || return=$rc_failed + brctl sethello mueb 1 || return=$rc_failed + brctl setmaxage mueb 4 || return=$rc_failed + brctl setfd mueb 4 || return=$rc_failed + + echo -e "$return" + ;; + stop) + echo "Shutting down service bridge mueb" + brctl delif mueb eth3 || return=$rc_failed + brctl delif mueb eth2 || return=$rc_failed + brctl delif mueb eth1 || return=$rc_failed + brctl delif mueb eth0 || return=$rc_failed + brctl delbr mueb || return=$rc_failed + rmmod bridge || return=$rc_failed + + 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 + + + + + + + + This command creates a new virtual interface (bridge instance) + with the name mueb and also brings up the + bridge module. + + At least my system it does. + Maybe you have to enable the kernel module loader. + + + + + + + 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. + + + In the init script of the backup bridge this line in missing, + leaving it with the default priority of 100. + + + + + + Enslaves the Ethernet interface to become a port in the + bridge. + + + + + Takes away any possibly disturbing IP-address and brings the + interface up. + + + + + Setting the hello time of the bridge to one second makes it + possible to reduce the maxage value of the bridges inside the + network. + + + + + Setting the time the a bridge is waiting before starting the + takeover process to a shorter period. + + + + + Forcing the bridge to forward earlier than the default time. + + + + + Take the Ethernet out of the bridging instance. + + + + + Destroy the bridge instance. + + + + + 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. + + + + + + See It Work + + Here I want to show and explain about how the running bridge shows + up. + The output of + bridge@mbb-1 is the output of the + primary bridge, while you see in + the output of the backup + bridge waiting to take over. + + + + 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 + + + + + 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 + and in + 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 ), + 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. + + + + <acronym>mbb-1</acronym> Messages From + <command>init 2</command> + +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 + + + + + + <acronym>mbb-2</acronym> Messages From + <command>init 2</command> + +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 + + + + + + + + Bridge Tests + + To check if really all the promised features are working, I did + some crude test. + The message logs are shown here in. + + + + 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 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 . + + + + The thing I did, was making the tests, and publishing the dump. + The one writing the nice explanations was Lennert again. + + + + + <acronym>mbb-2</acronym> 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 +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 +Jun 8 06:07:15 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 4(eth3) +Jun 8 06:07:15 mbb-2 kernel: mueb: port 4(eth3) entering listening state +Jun 8 06:07:19 mbb-2 kernel: mueb: port 4(eth3) entering learning state +Jun 8 06:07:23 mbb-2 kernel: mueb: port 4(eth3) entering forwarding state +Jun 8 06:07:23 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu +Jun 8 06:08:51 mbb-2 kernel: mueb: topology change detected, sending tcn bpdu +Jun 8 06:08:51 mbb-2 kernel: mueb: port 4(eth3) entering blocking state +Jun 8 06:09:22 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 3(eth2) +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 +Jun 8 06:10:41 mbb-2 kernel: mueb: neighbour 0000.08:00:06:28:15:f6 lost on port 2(eth1) +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) +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 + + + + What Lennert Told About This + + + 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]. + + + + + 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. + + + + + The plug on eth3 was pulled. + Here you can see that the message age timer expired + (). + 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. + + + + + 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. + + + + + 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. + + + + + Okay, here we go. + Pray for us. + + + + + 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. + + 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. + + + + + + + + Hey, something happened again! + + + + + + Yup... eth3 came back online. + The root bridge will provide connectivity for this segment + again, so that we can disable this port. + + + + + Same story for eth2, eth1 and eth0. + + + + + 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 . + If somebody can offer a explanation why the root bridge is so quiet in + messaging please tell me. + + + + <acronym>mbb-2</acronym> 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 ). + Well, okay. + We will set lower timeouts on our &mac;C table for a short period of + time, and we will propagate this topology change throughout the + network. + + + + + + + + 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 you will see + the messages from the master-bridge mbb-1, and in + you see what + happened the same time at the backup-bridge mbb-2. + + + + Test Messages Of Master Bridge <acronym>mbb-1</acronym> + +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 + + + + + + + + Test Messages Of Backup Bridge <acronym>mbb-2</acronym> + +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 + + + + + + + + + + + + + + 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 + Uwe Böhme. + + + + 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 + ++ +   + + + +
+ + + 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 + + + + +
+ + + + + + Recommended Reading + + Here you will some recommendations which documents you should read + before you start to setup a bridge. + + + + + + The bridge home-page + + Will give you recent information about the bridging code and + the bridge utilities. + + + + + + NET3-4-HOWTO + + Describes how to install and configure the Linux networking + software and associated tools. + + + + + + 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). + + + + + + + + + + + + FAQ + + Here you will find some of the frequently asked questions connected + to bridging. + + + + FAQ + + + 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. + + + + + + + + + + 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. + + + + + + + + + + + + + + +
diff --git a/LDP/howto/docbook/BRIDGE-STP-HOWTO/hardware-setup.png b/LDP/howto/docbook/BRIDGE-STP-HOWTO/hardware-setup.png new file mode 100644 index 00000000..42338471 Binary files /dev/null and b/LDP/howto/docbook/BRIDGE-STP-HOWTO/hardware-setup.png differ diff --git a/LDP/howto/docbook/BRIDGE-STP-HOWTO/old-hardware-setup.png b/LDP/howto/docbook/BRIDGE-STP-HOWTO/old-hardware-setup.png new file mode 100644 index 00000000..0d8dbd66 Binary files /dev/null and b/LDP/howto/docbook/BRIDGE-STP-HOWTO/old-hardware-setup.png differ