Disclaimer
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.
Liability Disclaimer
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.
Posting
Hi Leo, the version we are running is 12.2(55)SE1 which I don't believe is too old.
I know many subscribe to "if it ain't broke, don't fix it", yet subsequent patch releases are usually for things that were broke and are now fixed (hopefully with out breaking something else - which I've seen even Cisco do). Personally, I hate spending time analyzing a "new" problem issue, to find it's a known bug that was fixed 2 years ago. As Leo notes, 12.2(55)SE7 appears rather solid. So if you're happy with the features in that release, I too would suggest moving to that release.
I agree when I run sh run or other large commands, switch stack does take a few seconds to respond. But I'm wandering if it's also having any issues in the control plane. We have a large number of servers on these 8 switches. Could they be experiencing slowness or lag just with normal data flow?
I've never worried too much about cli command time on a 3750 stack or other devices. In fact I have several 6509s populated with seven 96 port cards - port range across all their 672 ports takes some time. CRS-1s, I've used, often are very "sluggish" at the cli. If the scheduler is doing things "right", time for execution of the cli commands shouldn't interfere with other control plane functions, as ideally cli command execution would have a lower priority.
As to having a large number of servers, or a large number of hosts, much depends on whether your 3750 stack is using StackWise or StackWisePlus. The former performs "roughly" like an Ethernet hub, the latter, for unicast, performs (very) "roughly" like a bus (or perhaps token ring). The latter also has twice the raw stack bandwidth of the former. Neither performs like a chassis fabric.
Basically, for StackWise, if your stack's aggregate concurrent bandwidth can exceed 32 Gbps, you may see performance issues. For this reason, breaking a large StackWise stack might increase data plane performance. For StackWisePlus (unicast), you're probably better stacking units up to stack max, although ideally really busy hosts that pass traffic to each other, would be on the same stack member (or perhaps stack member ring adjacent).
Also on a related note, is there any harm in having a large number of servers on a single VLAN? We are talking approx. 160.
Generally same issues whenever hosts share the same collision domain. I.e. "servers", alone shouldn't matter too much, unless they have some atypical traffic.
