Wired Intelligent Edge

last person joined: yesterday 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Back to discussions
Expand all | Collapse all

Help : Stacking Issues in 2930

This thread has been viewed 2 times

  • 1.  Help : Stacking Issues in 2930

    Posted Feb 14, 2019 07:33 AM

    Hello,

    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



  • 2.  RE: Help : Stacking Issues in 2930

    EMPLOYEE
    Posted Feb 14, 2019 12:49 PM

    Greetings!

     

    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.