spanning tree  TCPIP
This is a discussion on spanning tree  TCPIP ; The Dude wrote:
> Another thing that I would like to add is that switches are faster
> devices than routers. However, many network administrators do not
> like STP on because BPDUs slow the network down. Think about applying
...

Re: spanning tree
The Dude wrote:
> Another thing that I would like to add is that switches are faster
> devices than routers. However, many network administrators do not
> like STP on because BPDUs slow the network down. Think about applying
> STP to routers that are slower devices than switches. Anyway, the OP
> can try for himself and I would be happy to hear the results!
Hmmm, my calendar reads 2006 and not 1986. Switches are faster than
routers? That hasn't been the case for quite some time. If you are
counting at microsecond granularity and you are counting about
cutthrough vs storeforward dribble, then yes, you may have a case.
But I have a feeling you were regurgitating marketing (old one at that)
FUD.
Many admins don't know enough about STP, so they fear what they do not
understand. Ask any admin "who's the root bridge?"
BPDU certainly can't slow down your network. After all, it's one frame
every two seconds. How can that hurt?

hsb
"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not be able to
reply to emails sent to my account. Please post a followup instead.
************************************************** ******************

Re: spanning tree
In article ,
Hansang Bae wrote:
>Hmmm, my calendar reads 2006 and not 1986. Switches are faster than
>routers? That hasn't been the case for quite some time. If you are
>counting at microsecond granularity and you are counting about
>cutthrough vs storeforward dribble, then yes, you may have a case.
>But I have a feeling you were regurgitating marketing (old one at that)
>FUD.
Compare the aggregate forwarding rate and backplane rate in the
Cisco Catalyst 3750 kin to that of Cisco's routers. In order to
find anything comparable, you have to go to the Cisco 7600 or
some of the Cisco 12000 series. Even if you say that the Cisco 6500
is really a router, you cannot match the Catalyst 2950 or 3550 or
3750 forwarding speed until you get to the Supervisor 720.
*none* of the 6500 line cards exceeds 8 Gb/s backplane speed
(that's all that's supported by the switching fabric).
Sure a fully tricked out 6500 has an amazing aggregate forwarding
rate, but to take advantage of it at gigabit rates you have to
overbuy and underpopulate.

Re: spanning tree
Walter Roberson wrote:
[snip]
> Sure a fully tricked out 6500 has an amazing aggregate forwarding
> rate, but to take advantage of it at gigabit rates you have to
> overbuy and underpopulate.
which is exactly what we do on a constant basis!

hsb
"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not be able to
reply to emails sent to my account. Please post a followup instead.
************************************************** ******************

Re: spanning tree
>
> > So that's why distancevector or linkstate algorithms
> > are used. Presumably, at Layer 2, using the shortest path is not as
> > critical, although that may be changing.
>
> Indeed. And by the same token, routing protocols analogous to those
> used at L3 could potentially be used for L2 as well. I think Radia
> has some thoughts on that  see:
>
> http://research.sun.com/minds/20050208/
>
STP also includes "cost" during path computation. Why do they say that
STP doesn't choose the optimal path ?

Re: spanning tree
In article <1156910661.239041.281190@p79g2000cwp.googlegroups. com>,
Ask wrote:
>STP also includes "cost" during path computation. Why do they say that
>STP doesn't choose the optimal path ?
STP always builds a tree. If T is the root of the tree and X and Y are
leaves of different branches of the tree, then the traffic between
X and Y always goes through T, even if there is a direct connection
between X and Y (that got pruned by STP.)
STP is loopfree over all IP traffic, but sometimes there are
potential shortcuts for selected IP traffic but which STP does not
take into account.

Re: spanning tree
"Ask" wrote:
> STP also includes "cost" during path computation. Why do they say that
> STP doesn't choose the optimal path ?
STP forms the spanning tree with minimal overall cost. Which means, as
you work away from the root node to other nodes, you always look for the
lowest cost link to reach the next *unlabeled* node. Every time a node
gets connected to the tree, it gets labeled. So once connected to the
tree, a labeled node can no longer be a candidate to be added to the
tree (or that would create a loop).
Okay, so now you have this tree in which only the lowest cost links were
used when a choice had to be made. But all you can say about this tree
is that the cost from the root node to any other node must be the lowest
possible. However, the path between two arbitrary nodes in the tree will
not necessarily be the lowest cost, right?
Take the example where a frame needs to go between two nodes, each of
which is at the end of a branch. The two nodes may actually be adjacent,
connected by a single blocked link, and yet to send a frame between the
two, you might have to go all the way back to the root node and out
again.
So that's why STP doesn't optimize the path cost between any two
arbitrary nodes. Routing protocols do.
Bert

Re: spanning tree
"Walter Roberson" wrote:
> STP always builds a tree. If T is the root of the tree and X and Y are
> leaves of different branches of the tree, then the traffic between
> X and Y always goes through T,
It's possible for traffic between two nodes X and Y in the tree not to
have to go throught the root, even if X and Y are leaves.
X Y
\ /
\ /
W


T
Bert

Re: spanning tree
In article ,
Albert Manfredi wrote:
>"Walter Roberson" wrote:
>> STP always builds a tree. If T is the root of the tree and X and Y are
>> leaves of different branches of the tree, then the traffic between
>> X and Y always goes through T,
>It's possible for traffic between two nodes X and Y in the tree not to
>have to go throught the root, even if X and Y are leaves.
>X Y
> \ /
> \ /
> W
> 
> 
> T
But then X and Y are on the same branch of the tree, branch T/W.
I used the best concise wording that I had time for.

Re: spanning tree
"Walter Roberson" wrote:
>>> STP always builds a tree. If T is the root of the tree and X and Y
>>> are
>>> leaves of different branches of the tree, then the traffic between
>>> X and Y always goes through T,
>>It's possible for traffic between two nodes X and Y in the tree not to
>>have to go throught the root, even if X and Y are leaves.
>
>>X Y
>> \ /
>> a \ /b
>> W
>> 
>> 
>> T
>
> But then X and Y are on the same branch of the tree, branch T/W.
>
> I used the best concise wording that I had time for.
The term "branch" refers to any arc (or edge  same thing) between any
two nodes in the spanning tree. The term is not restricted to mean only
arcs that connect directly to the root, at least not that I've ever
seen. And a leaf is a vertex. A leaf does not incorporate an arc.
http://www.rwc.uc.edu/koehler/comath/32.html
Therefore, leaves X and Y connect to two different branches of the tree,
which I labeled "a" and "b" above. Yet frames between X and Y do not
have to go through the root.
Drawing a larger spanning tree, with more depth, might make the point
clearer.
Bert

Re: spanning tree
In article ,
Albert Manfredi wrote:
>Drawing a larger spanning tree, with more depth, might make the point
>clearer.
Somehow, I don't think that drawing a larger spanning tree, with more
depth, would make any clearer the point that I used the most
concise wording that I had time for.
When I'm fitting in an answer to a technical question in the few
minutes between having readed myself for work and the arrival of the
next bus, I don't always have time to enter a graph theory lecture
about cutpoints.

Re: spanning tree
"Walter Roberson" wrote:
> Somehow, I don't think that drawing a larger spanning tree, with more
> depth, would make any clearer the point that I used the most
> concise wording that I had time for.
>
> When I'm fitting in an answer to a technical question in the few
> minutes between having readed myself for work and the arrival of the
> next bus, I don't always have time to enter a graph theory lecture
> about cutpoints.
Well, then let me make it simple.
This statement:
"STP always builds a tree. If T is the root of the tree and X and Y are
leaves of different branches of the tree, then the traffic between X and
Y always goes through T, even if there is a direct connection between X
and Y (that got pruned by STP.)"
is not factual. Specifically, it is this part that is not true:
"If T is the root of the tree and X and Y are leaves of different
branches of the tree, then the traffic between X and Y always goes
through T, ..."
I showed an X and a Y that were leaves of different branches of the
tree, and yet frames DID NOT have to go through the root to travel
between X and Y.
Bert

Re: spanning tree
In article ,
Albert Manfredi wrote:
>"Walter Roberson" wrote:
>> Somehow, I don't think that drawing a larger spanning tree, with more
>> depth, would make any clearer the point that I used the most
>> concise wording that I had time for.
>Well, then let me make it simple.
>This statement:
>
>"STP always builds a tree. If T is the root of the tree and X and Y are
>leaves of different branches of the tree, then the traffic between X and
>Y always goes through T, even if there is a direct connection between X
>and Y (that got pruned by STP.)"
>
>is not factual.
Well, then let me make it simple.
The statement was correct with the definition of "different branches"
that I was using at the time I wrote the message, which was in a hurry.
Words do not have only one unique meaning.
My statement was open to interpretation, and under some interpretations
it was wrong. But there's nothing unusual about that: English is a
language of ambiguities, and if one argues extensively enough, one can
probably find fault with anything.
> This statement: [...] is not factual.
Well, some of what you posted earlier in the thread was "not factual"
in the interpretations that *I* would normally use, but it seemed unlikely
to me to be worth the time to argue it out.