How To: Firmware Upgrade on an VSF-Stack

Having created a VSF stack of Aruba 2930Fs, the immediate need of firmware maintenance is obviously raising the question of how!. Dealing with that, luckily a new software had been released and I was able to test.

Daring the result … it was shocking simple and runs as every other Aruba / Procurve firmware upgrade and you just have to cover the second vsf stack member.


vsf member 1
copy tftp flash 192.168.2.5 WC_16_07_0002.swi primary
vsf member 2
copy tftp flash 192.168.2.5 WC_16_07_0002.swi primary

 

Verify the upload with a show flash the firmware image something like, even you may ckeck the according member context again:


Image Size (bytes) Date Version
----------------- ------------ -------- --------------
Primary Image : 29328334 09/05/18 WC.16.07.0002
Secondary Image : 29072623 06/22/18 WC.16.06.0006


Boot ROM Version
----------------
Primary Boot ROM Version : WC.16.01.0004
Secondary Boot ROM Version : WC.16.01.0004


Default Boot Image : Primary
Default Boot ROM : Primary

and then simply


#boot system flash primary

Following the boot process on the serial interface output of the master looks pretty much like any firmware upgrade you may have done on one of these switches. Nevertheless they perform a failover, including serial output, which feels a bit strange. After that you may check the result in every memebers context again.


LABVSF01(config)# vsf member 1
LABVSF01(vsf member-1)# show version


Image stamp:
/ws/swbuildm/rel_xanadu_zeus_qaoff/code/build/lvm(swbuildm_rel_xanadu_zeus_qaof
f_rel_xanadu_zeus)
Sep 5 2018 11:54:18
WC.16.07.0002
794
Boot Image: Primary


Boot ROM Version: WC.16.01.0004
Active Boot ROM: Primary


LABVSF01(vsf member-1)# vsf member 2
LABVSF01(vsf member-2)# show version


Image stamp:
/ws/swbuildm/rel_xanadu_zeus_qaoff/code/build/lvm(swbuildm_rel_xanadu_zeus_qaof
f_rel_xanadu_zeus)
Sep 5 2018 11:54:18
WC.16.07.0002
794
Boot Image: Primary


Boot ROM Version: WC.16.01.0004
Active Boot ROM: Primary

Confirming that both stack nodes now run on the desired new firmware version 16.07.0002 in this case.

A simple reload did not do the job as in the single switch case and resulted in a “firmware version missmatch” and reloads on the secondary old software image. This looked strangely on the serial console since the session was forwarded to the current master always and the missmatch could only be observed for a short peiod in time, till the stack recovered itself.

So far the described procedure worked in a couple of test cycles.

 

Kyp. F.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.