Splitting up a 9-stack of 3750x switches

[bhatley]

I have a stack of 9 3750X switches that is having some performance and CPU peaking issues.  The suggestion was to split the stack in to two or three stacks and cluster them.  Will the three stacks keep their configs when I re-cable them? And, is that even a reasonable suggestion?

Thanks

[Reza Sharifi]

No, it will not keep the config.  when you divide one stack to 3, now each stack will have its own master and members.  The config will change and the ports need will be renumbered.  For example:

In a stack of 9 switches the last switch port numbering start with 9/0/1, 9/0/2, etc..

Once you put this switch in a different stack it may become switch 3, so the numbering will change to 3/0/1, 3/0/2, etc..

Be careful, if this is production environment, converting from 1 stack to 3 or 2 will cause a major outage for you.

HTH

[bhatley]

Thanks Reza for the reply.

I am comfortable with the renumbering, but I am still not quite sure what I will find on the "new" stack created when I split the stack.  I will be simply bypassing 3 switches in one of my racks by changing the cable routing.  Will the "new" stack think it is the old one and elect a master requiring me to remove stack members, change it's IP address, and renumber the ports, etc?  Or will it think it is a new stack and I will need to use the console to access the config to set it up? 

Thanks so much.  

[Reza Sharifi]

Will the "new" stack think it is the old one and elect a master requiring me to remove stack members, change it's IP address, and renumber the ports, etc?

Yes, you would need to figure out which switch is going to be the master, but before you do that you need to unprovision the switches, reboot them and than reprovision them again to work with the new stack.  It is like staring a new stack, but the different is now you need to renumber the switches.  Again, if this is in production you need long outage for this to work.

HTH

[Joseph W. Doherty]

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

If you split your stack of nine into three stacks of three, I believe each stack would "happily" run just as the stack members were originally configured.  (I'm assuming the stack members are correctly re-interconnected with their stack cables.)  Member switches should retain their original member numbers (although they can be reconfigured, as Reza notes).

The major issue, though, would be each stack of three believing it to be the original stack, for example, each stack of three would have the same hostname and IPs for interfaces still found within the stack of three, etc.  You wouldn't want to have more than one of these broken apart stacks on the same network at the same time until all conflicting parameters were reconfigured to avoid issues.

Again, as long as you don't try to have more than one stack of three on the network at the same time, until it's been reconfigured, you can reconfigure each stack while it's on-line.

[Leo Laohoo]

In addition to what Reza has posted, keep your switch stack to a size of seven.  If you go higher than seven, you'll see performance issue takes it's toll.

[Joseph W. Doherty]

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

What kind of performance issues and what's peaking the CPU?

The reason I ask, large stacks often slow down when processing the CLI, but the doesn't mean, necessarily, that frame/packet forwarding is impacted.  Also, processes are prioritized, so even if the CPU were running at 100% all the time, again, it doesn't mean, necessarily, that frame/packet forwarding is impacted.

When you split a stack, you also lose the additional bandwidth provided by the stack cables.  If your 3750 units were original generation, i.e. using StackWise, everything is flooded to the stack, and the sender removes frames from the stack, so a large busy stack can overload the stack ring.  However, your 3750Xs use StackWisePlus, that not only offers twice the stack ring bandwidth, but also uses the stack ring much "smarter" (at least for unicast).

So yes, splitting a stack might be a worthwhile suggestion, but there are some non-obvious trade-offs.  Others include, when you create additional logical units, that has implications for routing and/or STP performance too, etc.  It can be reasonable suggestion when you understand the trade-offs and your traffic flows.

BTW, there are configuration options that do impact 3750 operational performance.  The most important is insuring there's no TCAM resource exhaustion by using the most suitable SDM template.  Or, subtle configuration options as, for example, selecting which stack member will be the stack master (for example, Cisco recommends the stack master should not have stack uplinks).