I worked for a company once, that had a stack of 9 3750's. I would not recommend doing this. I would personally recommend a max of 4 or 5. The stack of 9 3750's had all sorts of problems; granted it could have been caused by a bug I suppose. Just my personal opionion.
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Like, Peter, unaware of any recommendation. Several years ago, I worked in a environment where (original series) 3750s were occasionally stacked to their max of nine. Don't recall any notable issues. However, it you scan these forums, some seem to have issues with large stacks, e.g. like John's post.
Peter mentions no performance degradation. In our deployment for user edge switches, we didn't see any performance issues, but in theory as stackrings are not fabrics, a large stack may run into stackring performance issues sooner than smaller stacks. (NB: This is more likely with StackWise vs. StackWisePlus, as the former floods all traffic to the ring.)
BTW, if you're buying new, you might want to carefully compare 4510 series to large 3750 stack. The 4510 might be less expensive and likely offer better performance. Also if you're buying new, you might want to examine the new 3850-X series, although at the moment they don't support stacks of more than four units.
I recall working on a 3750E stack acting as a collapsed core/distribution layer. It comprised 7 x 48-port switches. The CLI was very slow to respond. This can be quite un-nerving at times, especially when you enter an important command and nothing happens for a second or two - it seems like eternity! To be fair, it wasn't fit for purpose in my view. Whilst there hadn't been any actual failures, their campus was simply too busy for that topology.
VB, also bear in mind your traffic patterns in relation to the stack ring. You can help mitigate this to some degree - i.e. placing top talkers on the same stack member, so that traffic is switched on the local backplane and not the stack ring. You do need StackWise Plus for this though. Legacy StackWise will place all traffic on the ring, even if the ingress and egress ports are on the same stack member.
What's your stack doing at the moment? Is it access-layer, for example?
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...