Max bridge diameter as per 802.1D

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi all,

I was wondering what (technical) reason there might be for the maximum
bridge diameter of 7 bridges as per IEEE 802.1D? What I could guess is
that protocols such as (R,M)STP would have some timings in them and
propagation throughout a network brings its diameter and time together
then. Is it just that? Assuming one would not run STP --for whatever
reason-- could a bridge diameter be larger than 7 then?

I'd appreciate if someone would share their insight on bridge diamter and
its 802.1D limit with me.

TIA, /Tom.

--
Thomas Bahls | "Wege entstehen dadurch, daß man sie geht."
Greifswald, Germany | -- Franz Kafka

ICQ #119230485 +++ PGP Key 0x6E70B6AE +++ http://solitaryhiker.net/
11 answers Last reply
More about bridge diameter
  1. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Thomas Bahls <tbahls@arcor.de> wrote:
    > Hi all,

    > I was wondering what (technical) reason there might be for the maximum
    > bridge diameter of 7 bridges as per IEEE 802.1D? What I could guess is
    > that protocols such as (R,M)STP would have some timings in them and
    > propagation throughout a network brings its diameter and time together
    > then. Is it just that? Assuming one would not run STP --for whatever
    > reason-- could a bridge diameter be larger than 7 then?

    Ask yourself how many machines you want in a flat network, where any
    one of them might start spewing broadcasts and bring the other ones down,
    where everyone may grab an ip-address thus blocking the "rightful user"
    of that ip. Ask yourself if you like the idea of running without STP
    risking everything if a loop is (accidently) created somewhere.

    > I'd appreciate if someone would share their insight on bridge diamter and
    > its 802.1D limit with me.

    Route where possible, bridge when it does not matter.

    > TIA, /Tom.

    > --
    > Thomas Bahls | "Wege entstehen dadurch, daß man sie geht."
    > Greifswald, Germany | -- Franz Kafka

    > ICQ #119230485 +++ PGP Key 0x6E70B6AE +++ http://solitaryhiker.net/


    --
    Peter Håkanson
    IPSec Sverige ( At Gothenburg Riverside )
    Sorry about my e-mail address, but i'm trying to keep spam out,
    remove "icke-reklam" if you feel for mailing me. Thanx.
  2. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <40ca1a66$0$22991$9b4e6d93@newsread2.arcor-online.net>,
    tbahls@arcor.de says...
    > Hi all,
    >
    > I was wondering what (technical) reason there might be for the maximum
    > bridge diameter of 7 bridges as per IEEE 802.1D? What I could guess is
    > that protocols such as (R,M)STP would have some timings in them and
    > propagation throughout a network brings its diameter and time together
    > then. Is it just that? Assuming one would not run STP --for whatever
    > reason-- could a bridge diameter be larger than 7 then?
    >
    > I'd appreciate if someone would share their insight on bridge diamter and
    > its 802.1D limit with me.


    You can pull up Rich Seifert's posts on this matter. Groups.google.com


    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
  3. Archived from groups: comp.dcom.lans.ethernet (More info?)

    On Sat, 12 Jun 2004 03:33:30 GMT, Hansang Bae wrote:

    >You can pull up Rich Seifert's posts on this matter. Groups.google.com

    Thanks, have done so meanwhile.
    http://groups.google.com/groups?num=50&hl=de&lr=&ie=UTF-8&q=%22rich+seifert%22+bridge+diameter+group%3Acomp.dcom.lans.ethernet&btnG=Suche
    The sources seem to be rather old but probably still applicable. If no-one
    else has more/other insight, I'll assume that 7 is a rather useful and
    strongly recommended value but no dogma. So one might experience probs
    when exceeding 7 but it could be supposed to work in general, or with some
    timing tweaks (e.g., for STP).

    That'd be correct?

    Thanks,
    /Tom.

    --
    Thomas Bahls | "Wege entstehen dadurch, daß man sie geht."
    Greifswald, Germany | -- Franz Kafka

    ICQ #119230485 +++ PGP Key 0x6E70B6AE +++ http://solitaryhiker.net/
  4. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Hej Peter,

    On Fri, 11 Jun 2004 22:51:53 +0000 (UTC), in comp.dcom.lans.ethernet you
    wrote:

    >Ask yourself how many machines you want in a flat network, where any
    >one of them might start spewing broadcasts and bring the other ones down,
    >where everyone may grab an ip-address thus blocking the "rightful user"
    >of that ip. Ask yourself if you like the idea of running without STP
    >risking everything if a loop is (accidently) created somewhere.
    [...]
    >Route where possible, bridge when it does not matter.

    Wise words, without a doubt. What I am asked to think about is nothing
    like an "enterprise Ethernet" network so the former point will be somewhat
    less severe, /me thinks. Worthwhile considering, anyway. ;-) So thanks for
    commenting.


    Tack och ha det bra!
    /Tom

    --
    Thomas Bahls | "Wege entstehen dadurch, daß man sie geht."
    Greifswald, Germany | -- Franz Kafka

    ICQ #119230485 +++ PGP Key 0x6E70B6AE +++ http://solitaryhiker.net/
  5. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <40cab831$0$22989$9b4e6d93@newsread2.arcor-online.net>,
    Thomas Bahls <tbahls@arcor.de> wrote:

    > On Sat, 12 Jun 2004 03:33:30 GMT, Hansang Bae wrote:
    >
    > >You can pull up Rich Seifert's posts on this matter. Groups.google.com
    >
    > Thanks, have done so meanwhile.
    > http://groups.google.com/groups?num=50&hl=de&lr=&ie=UTF-8&q=%22rich+seifert%22
    > +bridge+diameter+group%3Acomp.dcom.lans.ethernet&btnG=Suche
    > The sources seem to be rather old but probably still applicable. If no-one
    > else has more/other insight, I'll assume that 7 is a rather useful and
    > strongly recommended value but no dogma. So one might experience probs
    > when exceeding 7 but it could be supposed to work in general, or with some
    > timing tweaks (e.g., for STP).
    >
    > That'd be correct?
    >

    That'd be correct.


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
  6. Archived from groups: comp.dcom.lans.ethernet (More info?)

    On Sat, 12 Jun 2004 16:10:59 -0700, in comp.dcom.lans.ethernet you wrote:

    >That'd be correct.

    Thanks, Rich. A very clear and straight, but nevertheless also helpful
    f'up of yours. ;-)

    Tx, /Tom.

    --
    Thomas Bahls | "Wege entstehen dadurch, daß man sie geht."
    Greifswald, Germany | -- Franz Kafka

    ICQ #119230485 +++ PGP Key 0x6E70B6AE +++ http://solitaryhiker.net/
  7. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Thomas Bahls <tbahls@arcor.de> wrote in message news:<40ca1a66$0$22991$9b4e6d93@newsread2.arcor-online.net>...
    > Hi all,
    >
    > I was wondering what (technical) reason there might be for the maximum
    > bridge diameter of 7 bridges as per IEEE 802.1D? What I could guess is
    > that protocols such as (R,M)STP would have some timings in them and
    > propagation throughout a network brings its diameter and time together
    > then. Is it just that? Assuming one would not run STP --for whatever
    > reason-- could a bridge diameter be larger than 7 then?
    >
    > I'd appreciate if someone would share their insight on bridge diamter and
    > its 802.1D limit with me.

    The limit is there to ensure that STP operates correctly, and is
    due to the *maximum* time that it is *possible* for a frame to take
    to traverse the network.

    IIRC the 802.1d Standard says that a bridge must not hold a frame
    for more than a second. I guess then that the STP timers
    were set to allow 7 seconds for a frame to get across the
    network.

    NO NO NO NO NO!!!

    That was not a bad guess but the time is not for the traversal
    of frames but for the propagation of BPDUs. I seem to recall
    that BPDUs are sent from the root bridge and each bridge
    processes those received from the direction of the root and
    then sends out its own BPDUs away from the root.

    Clearly in modern LANS packets do not *usually* get delayed by
    anything like that however the standard was written in
    an attempt to guarantee that STP would operate correctly
    in all circumstances.
    In view of the ubiquity of STP I think that the attempt
    succeeded.

    Lost STP frames result in loops.

    I would guess (more guessing) that Rich Seifert's book has
    material on this.

    If you are not using STP i.e. you have a loop free topology then
    you do not need to worry about the limitation.

    This would apply if only parts of the topology were loop free.
    You could have a core running STP and then string together
    as many switches as you liked with STP disabled.

    I am not saying that this design will lead to a long life of
    contentedness but it would work.

    You would want to check out very carefully the behaviour
    of switches with STP disabled if you wanted more than one STP zone.
    The switches not running STP might pass STP through or block it
    I don't know which.

    Thinking about any of this for more than two seconds in the
    context of a Western corporate network could get you sacked
    if you worked for me. There are however I am sure cases
    where it would be appropriate to consider it.
  8. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Thomas Bahls <tbahls@arcor.de> wrote in message news:<40cab831$0$22989$9b4e6d93@newsread2.arcor-online.net>...
    > On Sat, 12 Jun 2004 03:33:30 GMT, Hansang Bae wrote:
    >
    > >You can pull up Rich Seifert's posts on this matter. Groups.google.com
    >
    > Thanks, have done so meanwhile.
    > http://groups.google.com/groups?num=50&hl=de&lr=&ie=UTF-8&q=%22rich+seifert%22+bridge+diameter+group%3Acomp.dcom.lans.ethernet&btnG=Suche
    > The sources seem to be rather old but probably still applicable. If no-one
    > else has more/other insight, I'll assume that 7 is a rather useful and
    > strongly recommended value but no dogma. So one might experience probs
    > when exceeding 7 but it could be supposed to work in general, or with some
    > timing tweaks (e.g., for STP).
    >
    > That'd be correct?
    >
    > Thanks,
    > /Tom.

    For a high-profile case on what happened with a large
    spanning tree diameter without the necessary configuration, see:
    http://www.bnug.org/drhal.htm
    http://home.caregroup.org/templatesnew/departments/BID/network_outage/

    Anoop
  9. Archived from groups: comp.dcom.lans.ethernet (More info?)

    "Anoop Ghanwani" <anoop@alumni.duke.edu> wrote:

    > For a high-profile case on what happened with a large
    > spanning tree diameter without the necessary configuration, see:
    > http://www.bnug.org/drhal.htm
    > http://home.caregroup.org/templatesnew/departments/BID/network_outage/

    I have to assume that BPDUs were prevented from flowing properly by the
    extra data load the one researcher added? While the report said that the
    7-hop "limit" of 802.1D had been violated, it did not explain why this
    became a problem all at once. They apparently had 10 hops in a VLAN they
    had set up for net management. It's not clear to me why data load on
    presumably non-net-management VLANs would have brought the whole thing
    down. Unless maybe the extra load prevented BPDUs from flowing in that
    management VLAN.

    Bert
  10. Archived from groups: comp.dcom.lans.ethernet (More info?)

    "Albert Manfredi" <albert.e.manfredi@nospam.com> wrote in message news:<HzD638.C96@news.boeing.com>...
    > "Anoop Ghanwani" <anoop@alumni.duke.edu> wrote:
    >
    > > For a high-profile case on what happened with a large
    > > spanning tree diameter without the necessary configuration, see:
    > > http://www.bnug.org/drhal.htm
    > > http://home.caregroup.org/templatesnew/departments/BID/network_outage/
    >
    > I have to assume that BPDUs were prevented from flowing properly by the
    > extra data load the one researcher added? While the report said that the
    > 7-hop "limit" of 802.1D had been violated, it did not explain why this
    > became a problem all at once. They apparently had 10 hops in a VLAN they
    > had set up for net management. It's not clear to me why data load on
    > presumably non-net-management VLANs would have brought the whole thing
    > down. Unless maybe the extra load prevented BPDUs from flowing in that
    > management VLAN.

    It wasn't clear to me either after reading the article, but it seems
    like it had to do with the BPDUs not making it all the way across
    the network. If you look at the PowerPoint slides in the second link,
    it seems to suggest that it was a combination of having a large spanning
    tree diameter, and some other things like a memory leak in one of the
    switches. It also seems like there wasn't just one issue that was considered
    the cause of the meltdown, so they just listed all of the issues that
    were brought to their attention. The information in the articles
    is sketchy so it's hard for a reader to come to any specific conclusions.
    I just thought I'd forward it on as interesting reading since the
    topic of spanning tree diameter came up.

    Anoop
  11. Archived from groups: comp.dcom.lans.ethernet (More info?)

    "Anoop Ghanwani" <anoop@alumni.duke.edu> wrote:

    > For a high-profile case on what happened with a large
    > spanning tree diameter without the necessary configuration, see:
    > http://www.bnug.org/drhal.htm
    > http://home.caregroup.org/templatesnew/departments/BID/network_outage/

    > It wasn't clear to me either after reading the article, but it seems
    > like it had to do with the BPDUs not making it all the way across
    > the network. If you look at the PowerPoint slides in the second link,
    > it seems to suggest that it was a combination of having a large
    spanning
    > tree diameter, and some other things like a memory leak in one of the
    > switches. It also seems like there wasn't just one issue that was
    considered
    > the cause of the meltdown, so they just listed all of the issues that
    > were brought to their attention. The information in the articles
    > is sketchy so it's hard for a reader to come to any specific
    conclusions.
    > I just thought I'd forward it on as interesting reading since the
    > topic of spanning tree diameter came up.

    It was interesting indeed to read the accounts. It's sort of important
    to know what the problem was, if one wants to learn from that
    experience.

    Another possibility is that switches were added to the network over
    time, without adjusting the STP configuration. For example, perhaps
    switches were added which increased the diameter, but the BPDU lifetime
    was not increased from the default setting of, I would guess, 7.5. This
    sort of thing. If BPDUs are unable to reach all the switches under
    somewhat stressful load conditions, then you'll have any number of
    switches attempting to become the root of a new tree. I would think,
    though, that the network would have recovered when the "broke the
    camel's back" extra load was removed.

    Anyway, neither 802.1D nor 802.1w (STP and RSTP) have a hard limit of 7
    hops, as the accounts implied, and that network only had 10 hops. In
    principle, that alone should not have caused such a hard failure, unless
    combined with other problems and/or misconfiguration. (I just noticed,
    BTW, that both 802.1D and 802.1w are no longer freely available at the
    IEEE standards site. Must be that 6 month moratorium after a new edition
    has been released.)

    Bert
Ask a new question

Read More

Ethernet Card Networking