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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
