Spanning-Tree Limitations

[smcline06]

I am currently studying for my CCNA and during a CBT Nugget video it mentions Spanning-Tree is really only effective to around 4-5 daisy chained switches. I am wondering if this is the case and to what extent would spanning tree not be viable to use?

Thank you in advanced, you all here have already been so much help

[Peter Paluch · Accepted solution]

Hi Sean,

The STP is capable of handling any switched topology with a default maximum diameter of 18 or less switches (the limit of 18 is given by the fact that BPDUs are in fact stored only for max_age-message_age seconds where the message_age is a BPDU hop counter set to 0 on root bridge and incremented on each subsequent STP bridge). The statement that STP is effective only for 4-5 switches is, in my opinion, an overstatement. It protects any reasonable switched topology against bridging loops. An overly large switched domain would become problematic for another reasons, not just because of STP

Best regards,

Peter

[glen.grant]

In a correctly designed and implemented network you will never come close to spanning tree's limitations, if you do its very poorly designed..

[Philip Ratzsch]

Additional bit of knowledge - if memory serves, the default spanning-tree timers were based on some assumptions of a network with a diameter of seven switches.  The diameter can (at least when I last looked) be changed, but rarely does there seem to be a need to - especially with RPVST being as quick as it is.

As to your question about spanning-tree in general, it seems that the push now is to have routed interfaces between devices where possible.  It used to be that switching was significantly faster than routing, and as gear improves that's not really the case anymore.  I'm sure there are benchmarks somewhere that will show a slight difference in some uses but nothing to really be alarmed about.  As you may have guessed or already seen, spanning-tree doesn't know your intentions and when you plug something into the network it can cause STP to reconverge, sometimes with less-than-desireable results - with routed interfaces, it's significantly easier to direct traffic flows.

In fairness, there are still things than can go wrong in a primarily routed network, but in my experience they're generally easier to plan, predict, and manage.

[lamav]

Philip:

I agree on the diameter of 7.

But I think you need to qualiffy your statement about the push "now" to deploy routed access layers. That push began a good 5 years ago and has since been all but formally abandoned by Cisco for data center/server farm access layers. In fact, its exactly the opposite. With the development of cloud computing infrastructures, there is a need to expand the L2 domain across the entire data center (Fabric Path/TRILL), and between data centers, too (OTV). The approach now is to "flatten" the network through horizontal expansion of the switched network and increasing the bi-sectional bandwidth by removing the need to block inter-switch links, not by deploying routed access layers. L3 boundaries shrink the size of the switched domain and of the virtualized clusters that form the cloud infrastructure.

Victor

[Philip Ratzsch]

Victor,

You're right, that should have been stated a bit differently. The push to layer 3 networks was taken from the SWITCH book published by Cisco Press:

"Over the next few years, the trend in the campus is to move to a pure  Layer 3 environment consisting of inexpensive Layer 3 switches."

Specifically, the chapter that can be seen here: http://www.ciscopress.com/articles/article.asp?p=1608131

Obviously as with any network design, YMMV with the intended use-case.

I think it's important to also point out that just because something appears to be layer 2-adjacent (as many cloud computing things must appear) doesn't necessarily mean that all links between the two actual resources are layer 2 links.  OTV, which you mentioned, is an encapulating protocol and by it's very nature is masking the true network design.  A VPN is the same way - when I'm connected to a resource via a VPN tunnel I appear layer 2-adjacent but I may be going through any number of routed interfaces to get there.

[lamav]

Philip:

The book does not need to state anything differently. It is specifically referring to the "campus," not the data center. That is also why I was very specific in my repsonse to you regarding where expanding the L2 domain is desirable.

As for your point about VPNs, it has little to do with what we are talking about. Your point was that a routed access layer is "now" part of a push to mitigate the need for STP - and that is absolutely incorrect in the data center.

As for the campus, a routed access layer can impede some applications, like VDI. So, even that has to be done carefully.

Regards

[Philip Ratzsch]

Victor,

Just to clarify, I was saying that _I_ should have stated that a bit differently, as with my sentence construction involving the word 'now' - that wasn't intended to mean that there is an aggressive push from Cisco across every possible use-case to use layer three links.  You're right, this has gotten a bit off topic so I'll just wish you best of luck on your CCNA, Sean!