Wired

Hello airheads,

Our core switches are 5406Rzl2 each with dual management modules. I was under the impression that I could upgrade the code (using some mix of redundancy and other features) with minimal downtime. Around the Internet, I've seen various ramblings of things tried but never any definite yes or no. Is there a way to accomplish this?

Greetings!

The 5400R has dual management modules for redundancy (if one MM fails, the second takes over instantaneously), which can also be used to perform switch software upgrades with reduced downtime by loading a new software image, booting the standby MM onto the new version, then performing a redundancy switchover to swap to the standby MM. 

If you have a pair of 5400Rs stacked using VSF (front plane stacking), the VSF Fast Software Upgrade feature uses an automated sequenced reboot process to minimize downtime for devices with redundant links (at least one link per VSF member chassis). 

hi

see attachment

Thanks

Attachment(s)

ArubaOS-Switch - VSF Fast Software Upgrade.pdf   695 KB 1 version

I'm hoping to try this during our maintenance window next week, but according to TAC...

#copy sftp flash user ftpuser ftp.server.ip KB_16_08_0003.swi secondary 

#boot set-default flash primary 

#write memory 

#boot standby 

#show redundancy (wait for sync) 

#redundancy switchover 

...will upgrade with very little to no downtime. In their lab, there were no pings dropped. I'll add my results next week.

I'm really curious too...I'm planning a similar update on our Aruba 5400R zl2 with dual MMs and NonStop Switching redundancy enabled and the procedure I was able to detail is basically the same you just wrote in few lines:

I discussed L2/L3 traffic disruption theoretically on an Aruba 5400R zl2 with Dual MM and NonStop switching redundancy enabled (theoretically because I was without any pervious hands-on experience on the subject) here and also lightly here...my take is that Layer 2 traffic disruption should be nearly equal to zero (sub second disruption = basically no ping loss), Layer 3 traffic disruption should be instead not completely equal to zero...but I haven't been able to understand how much (in seconds) it will potentially be.

Mike, what were the results? Can you quantify what you're network disruption was, if any?

Apparently, my original TAC info was faulty. As I experienced in my testing, there was downtime (IIRC ~90 seconds). The expanation from TAC below.

I was able to find out that while trying to upgrade firmware even if there are two MM modules and Non stop switching is enabled the other software updated to standby is different from the software already present in active MM. Here the software are mismatched , so when you go ahead and do a redundancy switchover command is executed the active MM will give control to standby which finishes booting and will become active but the behavior noticed will be of warm standby. This is clearly explained in one of the documents I referred to. I will specify the link of the document in this email. Also Apologies for the information provided earlier. I was able to noticed that when the software in active and standby MM are same during redundancy switchover after switching to standby only the active MM will reboot and the ping is continuous with no drops in L2 and L3 (This is a condition that happens during failover) but during image mismatch when you do a redundancy switchover after switching to standby the active MM and the whole chassis reboots and this is known behavior and a limitation on the 5400R switches.

Link : 
http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c04943210-3.pdf

Refer Page 566 " Other software mismatch condition" and Appendix A " Chassis redundancy (HPE 5400R Switches)"
Also in Page 558 "About setting the rapid switchover stale timer " is specified.

Hi Mike, sorry...just a question: NonStop Switching redudancy mode (if active <-- where Configured Mode = Current Mode) doesn't admit that MM1 and MM2 run with mismatched software versions...that's just to say...if the NonStop Switching redudancy mode is just enabled the valid scenario falls into the case described with this TAC statement:

...when the software in active and standby MM are same during redundancy switchover after switching to standby only the active MM will reboot and the ping is continuous with no drops in L2 and L3 (This is a condition that happens during failover)...

So, just to be clear, wasn't really your system in NonStop Switching redudancy mode (so it was really in Warm Standby)?

What I mean is...did you started your upgrade journey with an Aruba 5406R zl2 switch where its "redudancy status" was similar to (software versions listed are those of my system, YMMV):

5412Rzl2# show redundancy 

 Configured Mode: Nonstop Switching 
 Current Mode   : Nonstop Switching

 Rapid Switchover Stale Timer : 90
 Failovers     : 2
 Last Failover : Wed May 16 11:57:53 2018

Slot Module Description                       State    SW Version    Boot Image
---- ---------------------------------------- -------- ------------- ----------
MM1  HP J9827A Management Module 5400Rzl2     Active   KB.16.05.0007 Primary  
MM2  HP J9827A Management Module 5400Rzl2     Standby  KB.16.05.0007 Primary  

5412Rzl2# show redundancy detail 

  Slot Role     Module Up Since     State Since         State            
  ---- -------- ------------------- ------------------- -----------------
  MM1  Active   05/16/18 14:41:30   05/16/18 14:48:53   Active           
  MM2  Standby  05/16/18 14:49:26   05/16/18 14:50:47   Standby          
 
 Failover Log:

  Slot Role     Time                Reason         
  ---- -------- ------------------- ---------------
  MM2  Active   05/16/18 11:57:52   Switchover     
  MM1  Active   05/16/18 11:50:09   Switchover     

5412Rzl2# show flash
Image             Size (bytes) Date     Version 
----------------- ------------ -------- --------------
Primary Image    :    33511892 03/27/18 KB.16.05.0007        
Secondary Image  :    33511892 03/27/18 KB.16.05.0007       

Boot ROM Version 
----------------
Primary Boot ROM Version   : KB.16.01.0006
Secondary Boot ROM Version : KB.16.01.0006

Default Boot Image   : Primary
Default Boot ROM     : Primary

5412Rzl2# show version
Management Module 1: Active

Image stamp:    /ws/swbuildm/rel_venice_qaoff/code/build/bom(swbuildm_rel_venice_qaoff_rel_venice)
                Mar 26 2018 23:16:09
                KB.16.05.0007
                847
Boot Image:     Primary

Boot ROM Version:    KB.16.01.0006
Active Boot ROM:     Primary


Management Module 2: Standby
Image stamp:    /ws/swbuildm/rel_venice_qaoff/code/build/bom(swbuildm_rel_venice_qaoff_rel_venice)
                Mar 26 2018 23:16:09
                KB.16.05.0007
                847
Boot Image:     Primary

Or what else?

Apart from what TAC wrote you (which is usually found on any ArubaOS-Switch guides) also this (old) article looks interesting to read.

I think that yours is the scenario in which I started but cannot recall at this point. I'll give that HPE artcle a read and perhaps try it this winter when I look at upgrades. Thanks!