Wired Intelligent Edge

 View Only
last person joined: yesterday 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Expand all | Collapse all

Upgrading 6400 chassis and 6300M

This thread has been viewed 48 times
  • 1.  Upgrading 6400 chassis and 6300M

    Posted Feb 01, 2023 05:00 AM
    Hi,
    I will be upgrading 6400 chassis and 6300M switches for the first time. What is the safe, easy and straightforwward approach to image upgrade. 

    Thanks


  • 2.  RE: Upgrading 6400 chassis and 6300M

    EMPLOYEE
    Posted Feb 01, 2023 07:00 AM
    Hi!

    Better start here - https://www.arubanetworks.com/techdocs/AOS-CX/10.11/PDF/fundamentals_6300-6400.pdf , Chapter 10. Then if you have specific questions, we can help.

    Very informative video about the topic - AOS-CX CLI series: Software upgrades and factory defaulting the switch

    If you decide to go with ISSU for 6400, there is quite a good video illustrating the process - Aruba AOS-CX 10.10 Update - In-Service Software Upgrade (ISSU) for CX 6400


    ------------------------------
    Ivan Bondar
    ------------------------------



  • 3.  RE: Upgrading 6400 chassis and 6300M

    Posted Feb 01, 2023 08:01 AM
    Thanks for the reply. My current version is FL.10.07.0030.  I can only go to v10.09.1010. (ArubaOS-CX_6400-6300_10_09_1010.swi) but not 10.11.x yet. I understand that there are two types of releases. Let me know if this is the correct path. 

    Is the procedure and file same for both 6300M and 6405/6410 chassis? I am planning to do it remotely without console access. Is it typically safe?


  • 4.  RE: Upgrading 6400 chassis and 6300M

    EMPLOYEE
    Posted Feb 01, 2023 08:09 AM
    Check the release notes of 10.11 here - https://www.arubanetworks.com/techdocs/AOS-CX/10.11/RN/rn_6300-6400_10-11-0001.pdfhttps://www.arubanetworks.com/techdocs/AOS-CX/10.11/RN/rn_6300-6400_10-11-0001.pdf

    This table will be useful to you:

    If you decide to go with 10.11 (and since you are on 10.07 it seems you are OK running SSR versions), then first you need to upgrade to 10.08 and just then to 10.11.

    You can upgrade from the remote, but if something goes wrong, then you will need console connection, but there is nothing new here, it's always like this with any switch, any vendor.

    ------------------------------
    Ivan Bondar
    ------------------------------



  • 5.  RE: Upgrading 6400 chassis and 6300M

    MVP GURU
    Posted Feb 01, 2023 08:54 AM
    The OP could also upgrade from 10.07 (SSR) to 10.10 (LSR) in just one step...it is supported.





  • 6.  RE: Upgrading 6400 chassis and 6300M

    EMPLOYEE
    Posted Feb 01, 2023 10:30 AM
    Absolutely! It is reflected in the table too:


    But that's a valuable mention, because many people think that SSR releases are doomed to be upgraded to another SSRs only :)))

    ------------------------------
    Ivan Bondar
    ------------------------------



  • 7.  RE: Upgrading 6400 chassis and 6300M

    Posted Feb 01, 2023 10:55 AM
    Thanks for the valuable information, guys. Is it a requirment to go the initial release of 10.10 first and then go to the updated 10.10 release or I can go directly to the latest 10.10?


  • 8.  RE: Upgrading 6400 chassis and 6300M

    MVP GURU
    Posted Feb 01, 2023 11:58 AM
    Hi!

    "Is it a requirment to go the initial release of 10.10 first and then go to the updated 10.10 release or I can go directly to the latest 10.10?"

    No, it isn't a requirement indeed you can plan an upgrade path from any AOS-CX 10.07 build your switches are currently running into to the latest AOS-CX 10.10 build available (as of today, this build is the ArubaOS-CX 10.10.1030) without necessarily going to ArubaOS-CX 10.10.0002 first (the 10.10.0002 was the GA build of AOS-CX 10.10).

    Speaking about a standalone Aruba 6400 (maybe with Dual MMs?) will worth a discussion around the newly introduced ISSU functionality but this discussion could start only once your Aruba 6400 is upgraded to AOS-CX 10.10 (not before).


  • 9.  RE: Upgrading 6400 chassis and 6300M

    Posted Feb 02, 2023 01:12 AM
    Thanks for the information. I will directly go to ArubaOS-CX 10.10.1030 in that case. 

    Is it a requirement to do the update through console? I am planning to do via ssh but I cannot confirm that connectivity will be required to answer any question on the prompt after it reboots. From my many years of Cisco experience, you lose the connectivity once switch goes into reboot and then you re-establish the connection. All videos I have watched showing console upgrades only. 

    Upon reboot the switch asks to select profile. This is concerning me. 



  • 10.  RE: Upgrading 6400 chassis and 6300M

    MVP GURU
    Posted Feb 02, 2023 05:22 AM
    Generally, it's not required to perform an update procedure using the Serial console - during a "normal" update, the boot phase should not require any valuable human interaction - and simply using a SSH connection should be enough and you shouldn't be too concerned (OK, you will be blind not seeing console messages at boot) but, as you know, "normal" meaning is quite questionable.

    As example, in case of an upgrade (AOS-CX 10.x -> 10.y) or when a switch component (module) requires a non-safe update [*] to be applied, I agree with you that is highly recommended to proceed via Serial Console to exactly see what the switch is going to perform (and how long it takes) during the busy boot phase.

    [*] See the allow-unsafe-updates command suggested for any update/upgrade procedure on recent Release Notes and also have a look at this old thread: https://community.arubanetworks.com/community-home/digestviewer/viewthread?MID=33772





  • 11.  RE: Upgrading 6400 chassis and 6300M

    Posted Feb 02, 2023 07:35 AM
    This is very important point you raised. I was created a MOP for the first tiome upgrade and I have the following steps:

    # boot set-default secondary
    Note: on subsequent upgrade you might need to change the above to 'primary', or as needed

    #boot system
    Default boot image set to secondary.
    Checking if the configuration needs to be saved...
    Checking for updates needed to programmable devices...
    Done checking for updates.

    2 device(s) need to be updated during the boot process.
    The estimated update time is between 2 and 3 minute(s).
    There may be multiple reboots during the update process.
    1 non-failsafe device(s) also need to be updated.
    Please run the 'allow-unsafe-updates' command to enable these updates.
    This will reboot the entire switch and render it unavailable
    until the process is complete.
    Continue (y/n)? n

    When ready to update the system, if a non-failsafe device update is needed, make sure the system
    will not have any power interruption during the process. Invoke the

    # config
    switch(config)# allow-unsafe-updates 30

    Continue (y/n)? y

    #boot system secondary

    This will reboot the entire switch and render it unavailable
    until the process is complete.
    Continue (y/n)? y

    Now my question is that if unsafe-update is identified,  at what point do I need to check and how that the components are being updated.  When do I proceed with reload? Do I need to be on console if this happens?


  • 12.  RE: Upgrading 6400 chassis and 6300M

    MVP GURU
    Posted Feb 02, 2023 11:50 AM
    Hi! I believe there are a way to look for a firmware update not already applied (thus just pending) by using the show needed-updates command BUT I'm not sure there is a way to understand in advance if a particular ArubaOS-CX software build is going to require an unsafe update (a non failsafe device update), if so, there are two ways: like you did (by observing warning messages) and enabling the allow-unsafe-updates only when it is explicitly required or enabling it every time an update/upgrade is executed. Another way is to don't enable it and look for needed-updates a posteriori (but it's not a practice I would suggest to follow).