Wired Intelligent Edge

 View Only
  • 1.  VSX Live-Upgrade using Central and CLI

    Posted 20 hours ago
      |   view attached

    Overview

    Central today doesn't have a built-in process to initiate a live upgrade of a pair of VSX switches. This post will show you how to combine New Central and Switch CLI console access to enable a live upgrade.

    Summary:

    ·       Use the Central Dashboard menu to push and pre-download the new firmware to the CX switches using the firmware policy profile and schedule a reboot for a later date, as we do not want to initiate the reboot workflow from Central instead utilize the VSX Live Upgrade (LU) workflow via switch CLI. Steps and UI snapshots shown in the Firmware Deployment section below.

    ·       Next, after the pre-download step above, initiate the VSX live-upgrade workflow from the VSX primary switch CLI pointing to the new firmware pre-downloaded to the secondary memory partition on the devices. This is shown in the Live Upgrade from CLI section below.

    ·       Use the Initial and Completion CLI checks on the devices including Audit Trail and Health Metrics in Central dashboard for full Live Upgrade monitoring and execution.

    Prerequisites:

    Switch pair that supports VSX – CX 6400, 8xxx, 9xxx, 10k.

    In this example, a pair of CX8320 switches (AGG-1 & 2) for a Site is configured in VSX mode.

    Initial Checks

    1.     Confirm VSX is running properly
    show vsx status

    AGG-1# show vsx status

    VSX Operational State

      ISL channel             : In-Sync

      ISL gmt. channel        : operational

      Config Sync Status      : In-Sync

      NAE                     : peer_reachable

      HTTPS Server            : peer_reachable

    Attribute           Local               Peer

    ------------        --------            --------

    ISL link            lag250              lag250

    ISL version         2                   2

    System MAC          aa:bb:cc:dd:ee:ff   aa:bb:cc:dd:ee:ff

    Platform            8320                8320

    Software Version    TL.10.16.1006       TL.10.16.1006

    Device Role         primary             secondary

    2.     Check firmware image files, and default boot image

    Show images

    AGG-1# show images    

    ----------------------------------------------------------------------

    AOS-CX Primary Image

    ----------------------------------------------------------------------

    Version : TL.10.16.1006                

    Size    : 425 MB                       

    Date    : 2025-08-22 14:28:55 UTC      

    SHA-256 : 9f579dafb372512149fa4d7d346451832f0b67135fcefd81d5ab4efa03cf6515   

    ----------------------------------------------------------------------

    AOS-CX Secondary Image

    ----------------------------------------------------------------------

    Version : TL.10.18.0001                

    Size    : 541 MB                       

    Date    : 2026-05-21 16:35:21 UTC      

    SHA-256 : 487a39d5d9471be64754b80b5b247856f07eb917735cf8ff4853323f5141626c     

    Default Image : primary                      

    Boot Profile Timeout : 5 seconds

    ------------------------------------------------------

    Management Module 1/1 (Active)

    ------------------------------------------------------

    Active Image       : primary                      

    Service OS Version : TL.01.16.0002                

    BIOS Version       : TL-01-0013                  

    Firmware Deployment

    Use Central to push out the new firmware version with the pre-download option checked and an upgrade date for much later since we don't want Central to initiate the VSX Live upgrade reboot and instead use the VSX LU CLI workflow initiated from the primary VSX switch as shown in the next section.

    Use Central to push the new firmware version for the VSX switches. In this example, a single firmware policy profile was created and assigned in Central for scope Global and device function Aggregation switch.

    Furthermore, depending upon your Aggregation/Core switching design and VSX device type, one can further control the scope of the firmware policy applied at different hierarchical levels and device function as needed.

    Note: Important to note here that after the firmware has been pre-downloaded to the switches and the VSX Live Upgrade from CLI has been fully completed, that the firmware policy on Central can be paused to avoid it trying to upgrade/reboot the switches again at the later/future date set (see snapshot on it towards the end of document.)


     

    Live-Upgrade from CLI

    Check if the new firmware has been deployed to the correct partition on each VSX member

    sh images

    sh images vsx-peer
     
    New firmware sometimes come with additional low-level updates that need to be applied from the service-OS. Run this command to check if any service-OS components need to be updated: 

    show needed-updates

    However, in this situation, the default boot image will still be pointing to the current firmware, and even the command sh needed-updates next-boot will not indicate changes.

    Therefore, always enable unsafe updates to ensure that any new low-level updates are applied. Run this command on both VSX members:
    allow-unsafe-updates 30

    Furthermore, given the VSX switches are fully managed by Central, you will need to enable support-mode to make configuration changes via CLI:

    hpe-anw-central support-mode

    Initiate the Live-upgrade workflow:
    vsx update-software boot-bank secondary

    AGG-1(config)# vsx update-software boot-bank secondary

    This command will upgrade both VSX primary and secondary systems, using pre-staged image, from 'TL.10.16.1006' to 'TL.10.18.0001' installed in secondary bank

    on both devices, then reboot them in sequence. The VSX secondary will reboot first,

    followed by primary.

    Continue (y/n)? Y

    Do you want to save the current configuration (y/n)? y

    The running configuration is saved to the startup configuration.

    VSX Primary Software Update Status: Waiting for VSX secondary to complete reboot

    VSX Secondary Software Update Status: Reboot started

    VSX ISL Status: Down

    Progress [##############################............................................................]

    The running configuration is saved to the startup configuration.

    VSX Primary Software Update Status: Reboot started

    VSX Secondary Software Update Status: Image updated successfully

    VSX ISL Status: Up

    Progress [###################################################################.]

    Secondary VSX system updated completely. Rebooting primary.

     AGG-1(config)#

    Jun15 20:22:36 hpe-mgmtmd[26810]: RebootLibPh1: Reboot reason:VSX software update

    The whole process will usually take a few minutes, depending on the switch type, number of modules and components to be updated from service-os.

    Completion checks

    The Live-Upgrade with the latest firmware is now complete! The system should be running normally, and dual-connected devices should not have had any impact (other than reduced available bandwidth).

    It is worth checking that the system has come up normally - run through the same post-upgrade checks that you always use. For instance, run through these commands and check for any irregularities:

    show vsx status

    show event -r

    sh mac-address-table count

    sh ip route summary

    Central UI should now show the updated firmware version (below).

     

    Monitoring of Live Upgrade

    Furthermore, besides CLI checks, Central UI also provides additional visibility and a historical record of all the VSX Live Upgrade steps executed using the Audit Trail and Health Metrics features as shown below.



    Note: Currently for system-initiated reboots or unplanned reboots, Central will continue to show the switch reboot alert for up to 6hours before being auto cleared. And given this VSX LU was executed on the switch CLI and not from Central, it shows as an unplanned reboot alert and recorded for 6hours before being cleared as seen in above the VSX switches Health Metric card. While for user-initiated reboot or planned firmware Switch Upgrade, Central should not show a reboot alert and it should be suppressed during the upgrade process.

    Also as noted above that after the VSX LU has been completed, that the Firmware Policy created on Central with the future reboot date be paused. Otherwise, Central will try and again reboot the VSX switches at the later date defined in the firmware policy which is not the intent and this will cause disruption in services and traffic on the switches at that time.

    References

    Classic Central VSX Live Upgrade workflow –

     https://airheads.hpe.com/discussion/howto-vsx-live-update-with-central

    Attachment(s)



  • 2.  RE: VSX Live-Upgrade using Central and CLI

    Posted 15 hours ago

    very helpful. Thanks for sharing



    ------------------------------
    If my post was useful accept solution and/or give kudos.
    Any opinions expressed here are solely my own and not necessarily that of HPE or Aruba.
    ------------------------------