Aruba & ProVision-based
cancel
Showing results for 
Search instead for 
Did you mean: 

5406R VSF firmware upgrade process

 
itcoop
Occasional Advisor

5406R VSF firmware upgrade process

I currently have a pair of 5406R with v3 modules and dual MMs.  Our initial installation was a simple migration from a legacy ZL series: both remain autonomous L2, STP, LACP, switches running VRRP.  All of the edge equipment in this rack has dual network connections (minimum of one to each switch) and can work around switch reboots as they happen.

  We use Comware extensively over our field networks.  All POPs have a minimum of two Comware devices running IRF and they do a decent job for us.  When reviewing VSF in the KB16 relase notes, it appears that VSF and IRF are somewhat related; however, the VSF technical documentation regarding firmware updates are not as specific and detailed as IRF docs.

In an IRF stack (ISSU incompatible), the firmware update is pushed to all members, the primary is rebooted and command fails-over to the secondary.  When the primary is up with the new firmware, it directs the reboot of the secondary, takes over as primary, and reboots the remaining members one at a time. Slick.

Firmware reboots are the no.1 preventable cause of network downtime; this is what I'd like to mitigate.  My question is regarding the advantages of VSF stacking my two 5406R. My current non-VSF 5406R config running dual MMs is pretty quick (redundancy switchover).

How is firmware updated when using VSF on 5400R?

3 REPLIES
parnassus
Honored Contributor

Re: 5406R VSF firmware upgrade process

Hi, with 16.03 VSF FSU (Fast Software Upgrade) was introduced (I wrote my findings here): in any case (VSF FSU or not), MM redudancy (Non Stop Switching or Warm Standby) is - actually - mutually exclusive with VSF, in other words...implementing VSF requires you disable (better: remove) the 2nd MM on both VFS members.

itcoop
Occasional Advisor

Re: 5406R VSF firmware upgrade process

Thank you, parnassus, for the prompt reply and intelligence.

  I overlooked that VSF Fast Software Upgrade feature in the documentation somehow.  It describes exactly what I’m looking for.  Thank you.

 Your notes from the link HPE ArubaOS-Switch Management and Configuration Guide for KA/KB.16.03 (January 2017) Chapter 30 "VSF Fast Software Upgrade" now appears at Chapter 23 page 575.  http://h20566.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=7074783&docLocale=en_US&docId=emr_na-c05365312 As you noted above, the release notes describe that my redundant MMs should be removed if migrating to VSF. This is may be an acceptable trade-off. 

Now to define the trade-off…

In your opinion, given my current non-VSF configuration of autonomous switches using redundant MMs, STP, VRRP, Track, et. al., can you suggest advantages or disadvantages of migrating to a VSF stack?  It seems that I would have to reconfigure at least one switch adding to potential downtime - so, there is a cost.  Knowing my configuration, would you recommend staying using my current autonomous configs or would you stack and rebuild using VSF?

My dilemma is to keeping a working (but complex) config vs. migrating to a relatively simplification of what I already have.  Based on this fast software upgrade process, I feel that VSF may be a better way for me to go.

Thanks again for your reply.

parnassus
Honored Contributor

Re: 5406R VSF firmware upgrade process

Hello, yep...I should have posted a link of the cited manual (as I usually do): very often documentation is revised (I was referring to 1st Edition "5200-2921"  of early January, you to the 2nd one "5200-2921a" of late January which is more recent) and so pages/chapters can change.

Back to VSF. AFAIK VSF was engineered (count as advantages) to:

  • eliminate the need for L2 redundancy protocols such as Spanning Tree Protocol (STP)
  • eliminate the need for L3 redundancy protocols such as Virtual Routing Redundancy Protocol (VRRP)
  • provide a simplified topology (one virtual switch fabric) and a simplified management

said so VSF technology could be a natural development path of your core infrastructure giving that you have already dual homed hosts on it and your actual Aruba 5400R zl2 hardware met all expected VSF related requirements (you will lose non V3 zl2 Modules and, for sure, two MMs...MMs lost can be bad thing or not, it depends on how much you relay on dual MM chassis redudancy and how much you're used to it).

On the VSF side there are physical requirements (especially on VSF Port members and their distribution across node's modules when you plan to aggregate more physical ports to enhance bandwidth and resilience between the two VSF Members) and logical requirements (working in "V3 mode only" with only V3 zl2 Modules) that may/may not have an impact on your plans.

Probably the best way to decide if a VSF deployment is good or not is to consider all VSF related Pro/Cons with respect to continuing to manage a complex scenario you're using today...not forgetting, as you wrote, that a planning for reconfiguration will be necessary (one of your two 5400R zl2 units should be factory defaulted - in any case that unit will lost its configuration - before joining the VSF Stack as Standby member either using the VSF Discovered Configuration Mode join procedure or using the VSF Provisioned Configuration Mode join procedure) that because VSF uses a strict running-configuration synchronization mechanism and all of its members (two nodes) will receive and run the running configuration of the VSF Commander enabled node.