Wired Intelligent Edge

 View Only

  • 1.  Firmware upgrade - VSF and VSX stacks

    Posted Jul 07, 2026 01:47 PM

    Dear all,

    I have a network environment consisting of two Aruba CX 8100 switches configured in a VSX High Availability (HA) pair, and two Aruba CX 6300M switches configured as a VSF stack. I need to upgrade the firmware for both the VSX pair and the VSF stack.

    While I have received the recommended stable firmware versions from TAC, this is my first time upgrading Aruba switches, and I have a few concerns based on my research.

    I understand that Aruba switches feature dual boot banks (primary and secondary). To perform the upgrade, I plan to copy the new firmware to the currently unused boot partition (e.g., if the switch is running on the primary image, I will upload the new firmware to the secondary partition).

    Could you please clarify the following questions?

    1. VSF Stack Upgrade

     Do I need to use the "allow-unsafe-updates 30" command during the stack upgrade, or should I only use it if it is explicitly stated in the release notes?

     To boot from the new firmware on the secondary partition, what is the correct command sequence? Should I use:

    boot system secondary

    or

    boot set-default secondary

    boot system

    1. VSX Pair Upgrade

     My plan is to copy the recommended firmware to the appropriate boot bank on each switch and then trigger the VSX orchestration. If the new firmware is loaded into the secondary boot bank, is the correct command:

    vsx update-software boot-bank secondary

    1. Upgrade Paths (Recommended by TAC)

     VSX Pair (CX 8100): Upgrading directly from 10.12.0006 to 10.13.1161.

     VSF Stack (CX 6300M): Upgrading sequentially from 10.13.1040 to 10.14.1061, and then from 10.14.1061 to 10.16.1040.

    Any guidance, best practices, or validation of these steps would be greatly appreciated.

    Best regards,

    Sachith



  • 2.  RE: Firmware upgrade - VSF and VSX stacks

    Posted 24 days ago

    Hi Sachith, plan's mostly right, a few fixes.

    allow-unsafe-updates is minutes, not seconds. It also got renamed to allow-non-failsafe-updates in 10.15.1010, so your two 6300M hops will want different commands. Don't run it on spec. Do boot system secondary, answer n at the prompt, and see whether it actually flags a non-failsafe device. show needed-updates next-boot secondary tells you the same thing without the preview.

    boot system secondary does both, sets the bank and reboots, so you don't need boot set-default first. And vsx update-software boot-bank secondary is correct. Pre-stage the image into the secondary bank on both switches, then run it from the primary.

    Paths are fine. 10.12 to 10.13 direct is supported, and so is 10.13 straight to 10.16, so the 10.14 hop isn't required unless TAC had a specific reason for it. 10.13 and 10.16 are long-support branches while 10.14 and 10.15 aren't, so I wouldn't park on 10.14 either way.

    For the VSF stack, copy the image to the conductor and it syncs to the members automatically, then one boot system reboots the whole stack. Don't reboot members individually mid-upgrade. Check show vsf topology first, because two members on a single link rather than a ring can split on reboot.

    For the VSX pair, confirm show vsx brief shows the ISL in-sync and keepalive established before you start. The gotcha on a first VSX upgrade is that the sub-second impact everyone quotes only applies to dual-homed MCLAG devices. Anything single-homed to the node that's rebooting drops for the full reboot, so walk your orphan ports before the window.



    ------------------------------
    Dustin Burns

    Lead Mobility Engineer @Worldcom Exchange, Inc.

    ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
    If my post was useful accept solution and/or give kudos
    ------------------------------



  • 3.  RE: Firmware upgrade - VSF and VSX stacks

    Posted 23 days ago

    Following up on the version paths, since I went and checked the documentation properly.

    The 10.13.1161 release notes are the document to use. Its Products Supported table lists the 8100 SKUs, R9W94A through R9W97A, with a minimum software version of 10.12.0001, and the Upgrade information section in that same document imposes no source version restriction at all. No stepping stone, no "you must be on X first." So going direct from 10.12.0006 to 10.13.1161 is fine and you are well clear of the floor.

    Fair warning if you go looking for confirmation in the 10.12.0006 notes themselves: they have been withdrawn. The links 404 and the whole 10.12 release notes directory is gone from the doc site, so you are not searching wrong.

    One thing to add to what I said about allow-unsafe-updates. The rename to allow-non-failsafe-updates at 10.15.1010 is confirmed in the Command History table, and the max is 120 minutes under either spelling. What is not documented anywhere, in either direction, is whether the old form still parses on newer builds. There is no deprecation note and no removal entry. So use tab or ? at the prompt on the actual switch rather than trusting a runbook.



    ------------------------------
    Dustin Burns

    Lead Mobility Engineer @Worldcom Exchange, Inc.

    ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
    If my post was useful accept solution and/or give kudos
    ------------------------------

    Original Message