Max bridge diameter as per 802.1D

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.

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.
********************************************************************

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...
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/

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/

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...
> +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

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/

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.

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...
> 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/...

Anoop

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/...

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

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/...
>
> 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

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/...

> 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