Help : Stacking Issues in 2930
02-14-2019 04:33 AM
Here is the issue im facing right now
I'm stacking "3" 2930 switches in chain topology
spilt-policy is set to all-members up
the top switch is commander, middle is member, bottom is standby
i have 2 uplinks to the core network (one to the top switch & one to the bottom Switch)
I'm simulating the following scenario:
The middle switch fails which will lead to stack spilit. both the top switch and the bottom switch will be commander. till here everything is fine and spanning tree will takecare of unblocking the other uplink. so no users affected from top switch and bottom switch.
the problem comes when i connect the middle switch back, as i will have 2 commander in the stack.
what is happening is one of the commandar will reboot to be a member which will cause all users connected to that switch to be affected as well.
is there anyway to reform the stack without having any one of them to reboot.(abart from using ring topology)
please note that im still in testing phase before deploying to production network. but in production i will have 7 switches stacked together and all stacking cables which i have is 1 meter so i don't have enough length for ring topology
appreciate your help as it's my last test before move to production
Re: Help : Stacking Issues in 2930
02-14-2019 09:49 AM
The stack merge process that takes place when a fragment rejoins a stack requires the member to reboot prior to syncing with the active Commander. There is no method at this time to avoid a reboot in this scenario.
As you mentioned, the ring topology would address the 'one switch down' issue, but if this isn't an option for you, my recommendation is to use link aggregation wherever possible to ensure connectivity even in the event of loss of an individual VSF member.