Re: [c-nsp] Catalyst 3750 stacks with many members
Kevin Graham [EMAIL PROTECTED] writes: My biggest single gripe is Cisco's own internal games with them with product handicapping such as the lack of a 3750E equivalent to the 3650E-12D and a higher-densitity or 'E' version of the 3750G-12S). (It would also be really nice to see an ISSU equivalent for these...) Indeed, Cisco seems to be completely out of the loop when it comes to non-modular fiber switches. Competing vendors can do 48 1Gbps SFP in one rack unit, and the best Cisco can do is 12... /Benny ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
Got some personal mails all in support of the stacking, saw only negative mails on the list, interesting... Price difference between 2x 3750 and a 6504 is not so small and a 6504 with one supervisor is still a single point of failure where a cluster of 2 switches would give me redundancy. Everyone thanks for the answer, still not sure what we are going to do. Wim Holemans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Tinka Sent: maandag 17 november 2008 2:10 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Catalyst 3750 stacks with many members On Monday 17 November 2008 05:20:25 Pshem Kowalczyk wrote: As a result of that we do not put stacks any more. If we need more ports we simply join them using ethernet cables (and etherchannels) and manage independently of each other. It has always been my personal opinion that inter-switch trunking or migrating to a small, single-chassis, multi-line-card based platform (e.g., 6504-E) would offer far less headache than Stacking, and keep things simple. Given the feedback from folk on this thread so far, I think we did well to avoid stacks. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
On Mon, Nov 17, 2008 at 09:34:55AM +0100, Holemans Wim wrote: Got some personal mails all in support of the stacking, saw only negative mails on the list, interesting... Price difference between 2x 3750 and a 6504 is not so small and a 6504 Sure, but you were talking about stacks of 7. We've run stacks of 2 for years without trouble. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
On Mon, Nov 17, 2008 at 12:30:44PM +0900, Ian Henderson wrote: Also, the stacking cables seem very fragile - even if they are screwed in properly, a bump can cause the stack to go haywire. This is very true. The connectors that Cisco uses for the backplane interconnection are unusually fragile. We only have two switch 3750 stacks and they work great when the stacking cables work. The one foot cables that come with the switches are great. They are short and light enough that the crappy connectors don't cause a problem. However, I've had at least four pairs of the three meter cables for switches located in adjacent racks. Of those four, only one pair ever worked correctly. On the other hand, Juniper's EX-4200 is awesome. The cables use PCI-Express connectors that are far sturdier than Cisco's proprietary connectors. We've using them in production, have hot-extended the chassis, and tested stacking cable failure. Works great. We're only using them for ethernet layer 2 - no layer 3 or MPLS. Lots of 802.3ad aggregation groups and some crazy MSTP mappings. -- Ross Vandegrift [EMAIL PROTECTED] If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
The one foot cables that come with the switches are great. They are short and light enough that the crappy connectors don't cause a problem. I have a suspicion that Cisco wanted to fix this. The 3750E's were initially a 3780, and were renamed late enough that several product photos had the original name. Note that all of the CBS31xx's use a much different, and simpler connector. This may have been a simple matter of form-factor (certainly the BladeCenter version doesn't have the physical real estate). The different name and different connector suggest that compatibility with StackWise/3750 was a late-stage change that also necessitated reverting to the older cable. ...with regard to SP CPU, really crude test suggest that the PPC405 on 3750E's is about half of the speed of the MPC8245 common on 4500 sups, so yes, if you're running very large stacks, presumably this will be an issue. (Furthest I've taken them is 6 w/ no CDP/LLDP and simple IGP). Being able to redeploy these into so many different configurations makes these far, far more useful than any of the modular chassis (where you end up having to eat chassis+sup, or chassis+dual-sup to get equivalent sparing). I still regret the places I put in 4506's instead of 3750's. My biggest single gripe is Cisco's own internal games with them with product handicapping such as the lack of a 3750E equivalent to the 3650E-12D and a higher-densitity or 'E' version of the 3750G-12S). (It would also be really nice to see an ISSU equivalent for these...) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
On Mon, Nov 17, 2008 at 12:53:46PM -0800, Kevin Graham wrote: Being able to redeploy these into so many different configurations makes these far, far more useful than any of the modular chassis (where you end up having to eat chassis+sup, or chassis+dual-sup to get equivalent sparing). I still regret the places I put in 4506's instead of 3750's. And forget eating a slot with sups - call me when a chassis based switch can be physically split into multiple parts and located in different locations... -- Ross Vandegrift [EMAIL PROTECTED] If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
Ross Vandegrift wrote: On Mon, Nov 17, 2008 at 12:53:46PM -0800, Kevin Graham wrote: Being able to redeploy these into so many different configurations makes these far, far more useful than any of the modular chassis (where you end up having to eat chassis+sup, or chassis+dual-sup to get equivalent sparing). I still regret the places I put in 4506's instead of 3750's. And forget eating a slot with sups - call me when a chassis based switch can be physically split into multiple parts and located in different locations... VSS: http://www.cisco.com/en/US/products/ps9336/index.html ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
Could you/someone elaborate on 'failure of one part is a failure of the stack' ? I thought Cisco just pushed this construction to get more redundancy/uptime in the network ? We were planning to replace some single switches with a lot of dual-line channels with a cluster of 2 of these 36xx or 37xx switches so we could split the channels over 2 switches and have still connection when one of the switches failed. Reading the recent negative comments on switch stacking I start wondering if this is a wise decision... Wim Holemans Network Services University of Antwerp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jamie rishaw Sent: vrijdag 14 november 2008 20:55 To: Dale Shaw Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Catalyst 3750 stacks with many members Yeah.. Replace them. With Chassis(es). Stacks are just a bad idea. Failure of one part of the stack is a failure of the stack. A 65xx serves just as well, better even; cheaper, more reliably, and with less BS.. I'm in the middle of tossing (however many letters are, inclusive, between a and s) stacks, moving to 65xx chassis(es) with 10/100 // triplespeed blades... moving to paired '09's. Cue the happy singing birds and obama 'yes we chassis' glory in 3.. 2.. 1.. -j On Fri, Nov 14, 2008 at 12:19 PM, Dale Shaw [EMAIL PROTECTED][EMAIL PROTECTED] wrote: Hi all, We have a few large (6 member) cat3750 stacks in our environment, most in L2 edge/access roles, and most providing PoE to cisco IP phones. -- ..!google!arpa.com!j ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
Hi, 2008/11/17 Holemans Wim [EMAIL PROTECTED]: Could you/someone elaborate on 'failure of one part is a failure of the stack' ? Usually it means that if a single device falls over the whole stack goes. I thought Cisco just pushed this construction to get more redundancy/uptime in the network ? I believe that despite the idea being quite good the implementation was always troubled with issues and never actually lived up to the expectations. We were planning to replace some single switches with a lot of dual-line channels with a cluster of 2 of these 36xx or 37xx switches so we could split the channels over 2 switches and have still connection when one of the switches failed. Reading the recent negative comments on switch stacking I start wondering if this is a wise decision... Over the years we've seen multiple issues with stacked switches: 1. Random reloads of the stack (usually snmp would report a high CPU use just before, but not always) 2. Unidirectional forwarding through vlans spanning multiple elements of the stack. 3. Mac address issues - stale mac not timing out properly, inability to learn a new mac. 4. Master election issues when the stack boots. Whether it was a race condition or wrong alignment of the planets - every now and then we would get a stack with multiple master switches that would refuse to talk to the rest of the stack. As a result of that we do not put stacks any more. If we need more ports we simply join them using ethernet cables (and etherchannels) and manage independently of each other. kind regards Pshem ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
On Monday 17 November 2008 05:20:25 Pshem Kowalczyk wrote: As a result of that we do not put stacks any more. If we need more ports we simply join them using ethernet cables (and etherchannels) and manage independently of each other. It has always been my personal opinion that inter-switch trunking or migrating to a small, single-chassis, multi-line-card based platform (e.g., 6504-E) would offer far less headache than Stacking, and keep things simple. Given the feedback from folk on this thread so far, I think we did well to avoid stacks. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
3750 Stacks work pretty well for me. But CDP is definitely crap. I remember forgetting to disable it once on a 6500 ; and the BGP wouldn't work anymore. The problem is not the stack ; the problem is CDP... Patrick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
Mark Tinka wrote: On Monday 17 November 2008 05:20:25 Pshem Kowalczyk wrote: As a result of that we do not put stacks any more. If we need more ports we simply join them using ethernet cables (and etherchannels) and manage independently of each other. It has always been my personal opinion that inter-switch trunking or migrating to a small, single-chassis, multi-line-card based platform (e.g., 6504-E) would offer far less headache than Stacking, and keep things simple. Given the feedback from folk on this thread so far, I think we did well to avoid stacks. Out of curiosity, I never see the 4500 chassis mentioned; why is that? ~Seth ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Catalyst 3750 stacks with many members
Hi all, We have a few large (6 member) cat3750 stacks in our environment, most in L2 edge/access roles, and most providing PoE to cisco IP phones. Does anyone have any tips as to how to make large stacks more reliable? We're seeing really high CPU and have found you need to be really careful doing anything that has the potential to swamp the CPU -- the other day I crashed a stack master by clearing the CDP neighbour table (a bit silly in hindsight, given the number of CDP table entries [phones], but I was troubleshooting a stale neighbour problem). Does changing to the 'VLANs' SDM template for switch stacks in this role make any difference? These stacks don't do any routing, or traffic ACLs. We've tried 12.2(40)SE, 12.2(44)SE2 and 12.2(44)SE3. Our biggest stack is 7 members. You're supposed to be able to stack 9 of these things (and I don't recall reading about any caveats), so it's a bit concerning. Disabling certain functionality (e.g. CDP) to stabilise is one thing, but long term it would be nice if it 'just worked'. cheers, Dale ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
Yeah.. Replace them. With Chassis(es). Stacks are just a bad idea. Failure of one part of the stack is a failure of the stack. A 65xx serves just as well, better even; cheaper, more reliably, and with less BS.. I'm in the middle of tossing (however many letters are, inclusive, between a and s) stacks, moving to 65xx chassis(es) with 10/100 // triplespeed blades... moving to paired '09's. Cue the happy singing birds and obama 'yes we chassis' glory in 3.. 2.. 1.. -j On Fri, Nov 14, 2008 at 12:19 PM, Dale Shaw [EMAIL PROTECTED][EMAIL PROTECTED] wrote: Hi all, We have a few large (6 member) cat3750 stacks in our environment, most in L2 edge/access roles, and most providing PoE to cisco IP phones. -- ..!google!arpa.com!j ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
On Fri, 2008-11-14 at 10:19 -0800, Dale Shaw wrote: We have a few large (6 member) cat3750 stacks in our environment, most in L2 edge/access roles, and most providing PoE to cisco IP phones. Does anyone have any tips as to how to make large stacks more reliable? The largest we've used was a 6 member stack. No CPU wise. No large number of CDP neighbors though. Probably no help, but we've started moving away from stacking. Having to manage X or 2*X switches isn't that different for a non small X -- you need some tools to manage several switches concurrently anyway. The failure scenarios are more clean using stand alone units and regular RSTP for us. It would be very sweet if one could use the stack ports as regular interfaces between switches. That would be a cheap high bandwidth connection in a U topology. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 3750 stacks with many members
split the stacks into smaller groups From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Dale Shaw [EMAIL PROTECTED] Sent: Friday, November 14, 2008 1:19 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Catalyst 3750 stacks with many members Hi all, We have a few large (6 member) cat3750 stacks in our environment, most in L2 edge/access roles, and most providing PoE to cisco IP phones. Does anyone have any tips as to how to make large stacks more reliable? We're seeing really high CPU and have found you need to be really careful doing anything that has the potential to swamp the CPU -- the other day I crashed a stack master by clearing the CDP neighbour table (a bit silly in hindsight, given the number of CDP table entries [phones], but I was troubleshooting a stale neighbour problem). Does changing to the 'VLANs' SDM template for switch stacks in this role make any difference? These stacks don't do any routing, or traffic ACLs. We've tried 12.2(40)SE, 12.2(44)SE2 and 12.2(44)SE3. Our biggest stack is 7 members. You're supposed to be able to stack 9 of these things (and I don't recall reading about any caveats), so it's a bit concerning. Disabling certain functionality (e.g. CDP) to stabilise is one thing, but long term it would be nice if it 'just worked'. cheers, Dale ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
