Wired Intelligent Edge

Hi, I was reading about the new ISSU feature provided by ArubaOS-CX 10.10 and currently available only on Aruba CX 6400 Switch series when equipped with two Management Modules.

This suggestion (see here) about performing ISSU on a VSX deployment:

"VSX environments: In order to minimize a potential downtime, it is strongly recommended that in a VSX topology ISSU is performed at different times for each switch. E.g., run ISSU on the primary switch, verify that it was successful, and then perform ISSU for the secondary switch."

which is totally reasonable, make me to ask if VSX Live Upgrade and ISSU approaches can be played together in a orchestrated way or the fact that ISSU was engineered to let an hitless AOS-CX software update a single Chassis (with dual MMs), that standpoint doesn't couple well with the idea of using it also on a VSX deployment and its specific way of performing (fully automated and orchestrated) software updates of its VSX Members. Any opinion?

I know that, considering the specific case of a VSX, instead of relying on the VSX Live Upgrade procedure we are still free to proceed the old way (first upgrading the VSX Secondary then the VSX Primary, manually)...and so this can be coupled - as suggested in the above note - with applying first the ISSU on the VSX Secondary and only then on VSX Primary to complete the whole update procedure.

Mine is an attempt to understand - added complexity of operations apart - how much resilient is a VSX of Aruba 6400 with dual MMs if we introduce and manually perform the ISSU approach on each VSX Member compared to not introducing it at all and continue to live with the VSX Live Upgrade feature.

Maybe I'm trying a way to compare how better is (from a operational/management standpoint) is a VSX of Aruba 6400 with dual MMs on each VSX Members (with or without using ISSU) and a standalone Aruba 6400 with dual MMs and, again, operationally speaking, using ISSU during software updates. I know that isn't fair to compare a standalone Chassis versus VSX...but the VSX Live Upgrade and ISSU made me think.

Just thinking...

Any opinion?
Original Message:
Sent: Oct 01, 2022 08:39 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi, I was reading about the new ISSU feature provided by ArubaOS-CX 10.10 and currently available only on Aruba CX 6400 Switch series when equipped with two Management Modules.

This suggestion (see here) about performing ISSU on a VSX deployment:

"VSX environments: In order to minimize a potential downtime, it is strongly recommended that in a VSX topology ISSU is performed at different times for each switch. E.g., run ISSU on the primary switch, verify that it was successful, and then perform ISSU for the secondary switch."

which is totally reasonable, make me to ask if VSX Live Upgrade and ISSU approaches can be played together in a orchestrated way or the fact that ISSU was engineered to let an hitless AOS-CX software update a single Chassis (with dual MMs), that standpoint doesn't couple well with the idea of using it also on a VSX deployment and its specific way of performing (fully automated and orchestrated) software updates of its VSX Members. Any opinion?

I know that, considering the specific case of a VSX, instead of relying on the VSX Live Upgrade procedure we are still free to proceed the old way (first upgrading the VSX Secondary then the VSX Primary, manually)...and so this can be coupled - as suggested in the above note - with applying first the ISSU on the VSX Secondary and only then on VSX Primary to complete the whole update procedure.

Mine is an attempt to understand - added complexity of operations apart - how much resilient is a VSX of Aruba 6400 with dual MMs if we introduce and manually perform the ISSU approach on each VSX Member compared to not introducing it at all and continue to live with the VSX Live Upgrade feature.

Maybe I'm trying a way to compare how better is (from a operational/management standpoint) is a VSX of Aruba 6400 with dual MMs on each VSX Members (with or without using ISSU) and a standalone Aruba 6400 with dual MMs and, again, operationally speaking, using ISSU during software updates. I know that isn't fair to compare a standalone Chassis versus VSX...but the VSX Live Upgrade and ISSU made me think.

Just thinking...

Hi, this is interesting and got me to read about the 2 of them a little bit more.

I got a doubt on my own lol

Do you know if Live-upgrade actually upgrade the redundant management module, if any?
Original Message:
Sent: Oct 28, 2022 03:00 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Any opinion?
Original Message:
Sent: Oct 01, 2022 08:39 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi, I was reading about the new ISSU feature provided by ArubaOS-CX 10.10 and currently available only on Aruba CX 6400 Switch series when equipped with two Management Modules.

This suggestion (see here) about performing ISSU on a VSX deployment:

"VSX environments: In order to minimize a potential downtime, it is strongly recommended that in a VSX topology ISSU is performed at different times for each switch. E.g., run ISSU on the primary switch, verify that it was successful, and then perform ISSU for the secondary switch."

which is totally reasonable, make me to ask if VSX Live Upgrade and ISSU approaches can be played together in a orchestrated way or the fact that ISSU was engineered to let an hitless AOS-CX software update a single Chassis (with dual MMs), that standpoint doesn't couple well with the idea of using it also on a VSX deployment and its specific way of performing (fully automated and orchestrated) software updates of its VSX Members. Any opinion?

I know that, considering the specific case of a VSX, instead of relying on the VSX Live Upgrade procedure we are still free to proceed the old way (first upgrading the VSX Secondary then the VSX Primary, manually)...and so this can be coupled - as suggested in the above note - with applying first the ISSU on the VSX Secondary and only then on VSX Primary to complete the whole update procedure.

Mine is an attempt to understand - added complexity of operations apart - how much resilient is a VSX of Aruba 6400 with dual MMs if we introduce and manually perform the ISSU approach on each VSX Member compared to not introducing it at all and continue to live with the VSX Live Upgrade feature.

Maybe I'm trying a way to compare how better is (from a operational/management standpoint) is a VSX of Aruba 6400 with dual MMs on each VSX Members (with or without using ISSU) and a standalone Aruba 6400 with dual MMs and, again, operationally speaking, using ISSU during software updates. I know that isn't fair to compare a standalone Chassis versus VSX...but the VSX Live Upgrade and ISSU made me think.

Just thinking...

Hi Ulises,

To answer your question:

"Do you know if Live-upgrade actually upgrade the redundant management module, if any?"

we should understand what is going to happen when we simply perform a manual update of a standalone chassis of Aruba CX 6400 equipped with two MMs deployed in a Active/Standby configuration (thus without ISSU): the Chassis will be instructed to reboot after the new AOS-CX software image is saved into the Primary or Secondary Flash memory area of the AMM (and we all expect that new flashed AOS-CX software image is also automatically copied into the corresponding SMM Flash memory area, as example...if the new AOS-CX software image is going to be saved into the Standby flash area of the AMM...then the very same operation should automatically happen on the SMM under the AMM administration...then the whole chassis will reboot and, post reboot, the AMM and the SMM are aligned as they were exactly before the chassis rebooted...eventually the alternate Flash memory areas not touched by the software update could be aligned too, on the AMM it should be enough to copy again the new AOS-CX Software Image into the Flash memory area not touched by the whole process...but this is eventually a secondary step once the new software is checked to run flawlessly for some time).

So, coming back to your question, given that VSX Live Upgrade is related to an orchestrated way of updating the VSX Cluster software and given that it automates manual operations between the two VSX Members (also introducing specific controls and features), I expect that performing a VSX Live Upgrade against an Aruba 6400 VSX Cluster where each chassis has two MMs operating in Active/Standby mode, will necessarily update both MMs on each chassis (that, again, will reboot).

From this point of view performing a VSX Cluster software update using the manual way (old way, no VSX Live Upgrade) will produce the very same outcome (AMM and SMM will be aligned with the same AOS-CX software version on their corresponding updated Image area, Primary or Secondary). 

Totally different is the case of VSX Live Upgrade with ISSU on each Aruba 6400 Chassis (with two MMs).


Original Message:
Sent: Oct 31, 2022 02:27 PM
From: Ulises Cazares
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi, this is interesting and got me to read about the 2 of them a little bit more.

I got a doubt on my own lol

Do you know if Live-upgrade actually upgrade the redundant management module, if any?
Original Message:
Sent: Oct 28, 2022 03:00 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Any opinion?
Original Message:
Sent: Oct 01, 2022 08:39 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi, I was reading about the new ISSU feature provided by ArubaOS-CX 10.10 and currently available only on Aruba CX 6400 Switch series when equipped with two Management Modules.

This suggestion (see here) about performing ISSU on a VSX deployment:

"VSX environments: In order to minimize a potential downtime, it is strongly recommended that in a VSX topology ISSU is performed at different times for each switch. E.g., run ISSU on the primary switch, verify that it was successful, and then perform ISSU for the secondary switch."

which is totally reasonable, make me to ask if VSX Live Upgrade and ISSU approaches can be played together in a orchestrated way or the fact that ISSU was engineered to let an hitless AOS-CX software update a single Chassis (with dual MMs), that standpoint doesn't couple well with the idea of using it also on a VSX deployment and its specific way of performing (fully automated and orchestrated) software updates of its VSX Members. Any opinion?

I know that, considering the specific case of a VSX, instead of relying on the VSX Live Upgrade procedure we are still free to proceed the old way (first upgrading the VSX Secondary then the VSX Primary, manually)...and so this can be coupled - as suggested in the above note - with applying first the ISSU on the VSX Secondary and only then on VSX Primary to complete the whole update procedure.

Mine is an attempt to understand - added complexity of operations apart - how much resilient is a VSX of Aruba 6400 with dual MMs if we introduce and manually perform the ISSU approach on each VSX Member compared to not introducing it at all and continue to live with the VSX Live Upgrade feature.

Maybe I'm trying a way to compare how better is (from a operational/management standpoint) is a VSX of Aruba 6400 with dual MMs on each VSX Members (with or without using ISSU) and a standalone Aruba 6400 with dual MMs and, again, operationally speaking, using ISSU during software updates. I know that isn't fair to compare a standalone Chassis versus VSX...but the VSX Live Upgrade and ISSU made me think.

Just thinking...

Hi @parnassus, thanks for your answer.

I think too that the Live Upgrade process should upgrade de SMM, I'm just not sure because I haven't been able to do it.

Talking about what you initially wrote, knowing what both processes do and the limitations for ISSU, I think i would to the following in case a upgarde is needed:

1.- Use ISSU while in the same major version if the chassis have only ver 1 LCs
2.- Whenever I need to go to a major version use Live-Upgrade or if the chassis have ver 2 LCs


And about which one is "better"... Personally, I'd go with ISSU (limitations apart) because it alternates both Managemnet Modules so you know, in every upgrade, that both MMs are good.

What do you think?

Regards
​
Original Message:
Sent: Nov 02, 2022 11:37 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi Ulises,

To answer your question:

"Do you know if Live-upgrade actually upgrade the redundant management module, if any?"

we should understand what is going to happen when we simply perform a manual update of a standalone chassis of Aruba CX 6400 equipped with two MMs deployed in a Active/Standby configuration (thus without ISSU): the Chassis will be instructed to reboot after the new AOS-CX software image is saved into the Primary or Secondary Flash memory area of the AMM (and we all expect that new flashed AOS-CX software image is also automatically copied into the corresponding SMM Flash memory area, as example...if the new AOS-CX software image is going to be saved into the Standby flash area of the AMM...then the very same operation should automatically happen on the SMM under the AMM administration...then the whole chassis will reboot and, post reboot, the AMM and the SMM are aligned as they were exactly before the chassis rebooted...eventually the alternate Flash memory areas not touched by the software update could be aligned too, on the AMM it should be enough to copy again the new AOS-CX Software Image into the Flash memory area not touched by the whole process...but this is eventually a secondary step once the new software is checked to run flawlessly for some time).

So, coming back to your question, given that VSX Live Upgrade is related to an orchestrated way of updating the VSX Cluster software and given that it automates manual operations between the two VSX Members (also introducing specific controls and features), I expect that performing a VSX Live Upgrade against an Aruba 6400 VSX Cluster where each chassis has two MMs operating in Active/Standby mode, will necessarily update both MMs on each chassis (that, again, will reboot).

From this point of view performing a VSX Cluster software update using the manual way (old way, no VSX Live Upgrade) will produce the very same outcome (AMM and SMM will be aligned with the same AOS-CX software version on their corresponding updated Image area, Primary or Secondary).

Totally different is the case of VSX Live Upgrade with ISSU on each Aruba 6400 Chassis (with two MMs).


Original Message:
Sent: Oct 31, 2022 02:27 PM
From: Ulises Cazares
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi, this is interesting and got me to read about the 2 of them a little bit more.

I got a doubt on my own lol

Do you know if Live-upgrade actually upgrade the redundant management module, if any?
Original Message:
Sent: Oct 28, 2022 03:00 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Any opinion?
Original Message:
Sent: Oct 01, 2022 08:39 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi, I was reading about the new ISSU feature provided by ArubaOS-CX 10.10 and currently available only on Aruba CX 6400 Switch series when equipped with two Management Modules.

This suggestion (see here) about performing ISSU on a VSX deployment:

"VSX environments: In order to minimize a potential downtime, it is strongly recommended that in a VSX topology ISSU is performed at different times for each switch. E.g., run ISSU on the primary switch, verify that it was successful, and then perform ISSU for the secondary switch."

which is totally reasonable, make me to ask if VSX Live Upgrade and ISSU approaches can be played together in a orchestrated way or the fact that ISSU was engineered to let an hitless AOS-CX software update a single Chassis (with dual MMs), that standpoint doesn't couple well with the idea of using it also on a VSX deployment and its specific way of performing (fully automated and orchestrated) software updates of its VSX Members. Any opinion?

I know that, considering the specific case of a VSX, instead of relying on the VSX Live Upgrade procedure we are still free to proceed the old way (first upgrading the VSX Secondary then the VSX Primary, manually)...and so this can be coupled - as suggested in the above note - with applying first the ISSU on the VSX Secondary and only then on VSX Primary to complete the whole update procedure.

Mine is an attempt to understand - added complexity of operations apart - how much resilient is a VSX of Aruba 6400 with dual MMs if we introduce and manually perform the ISSU approach on each VSX Member compared to not introducing it at all and continue to live with the VSX Live Upgrade feature.

Maybe I'm trying a way to compare how better is (from a operational/management standpoint) is a VSX of Aruba 6400 with dual MMs on each VSX Members (with or without using ISSU) and a standalone Aruba 6400 with dual MMs and, again, operationally speaking, using ISSU during software updates. I know that isn't fair to compare a standalone Chassis versus VSX...but the VSX Live Upgrade and ISSU made me think.

Just thinking...

Hi @ulises.cazares

(1) OK, also consider that ISSU feature and procedure seems to be totally tailored (it is tailored) for standalone Chassis operation when a Chassis owns two MMs and various other ISSU related requirements are fulfilled (stay within the same AOS-CX branch, currently supports the usage of A/B Line Cards and not C, etc.).

(2) But Live Upgrade procedure can be applied specifically to a VSX deployment and not when you're playing with just one Chassis: so if you speak of VSX Live Upgrade you're speaking about VSX Cluster and so you will fall back into the case of a VSX Live Upgrade operation against a VSX Cluster without implementing the ISSU on each Chassis - Aruba does not recommended it indeed - because the VSX Live Upgrade and ISSU are not orchestrated procedures neither can be considered totally independent one from the other (that's why Aruba recommends to perform ISSU on VSX Standby first then, once ISSU finished, repeat the ISSU procedure on VSX Primary, that's just a more sophisticated way of doing thing - because of the ISSU part on each Chassis - as we did them manually well before the VSX Live Upgrade feature existed).

"Personally, I'd go with ISSU (limitations apart) because it alternates both Managemnet Modules so you know, in every upgrade, that both MMs are good"

Technically speaking, also performing a manual MMs switchover - when the SMM becomes the new AMM - should let us to understand that the SMM is in good working conditions (otherwise the switchover operation can't even start)...but it's not like a successful ISSU.
Original Message:
Sent: Nov 02, 2022 12:32 PM
From: Ulises Cazares
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi @parnassus, thanks for your answer.

I think too that the Live Upgrade process should upgrade de SMM, I'm just not sure because I haven't been able to do it.

Talking about what you initially wrote, knowing what both processes do and the limitations for ISSU, I think i would to the following in case a upgarde is needed:

1.- Use ISSU while in the same major version if the chassis have only ver 1 LCs
2.- Whenever I need to go to a major version use Live-Upgrade or if the chassis have ver 2 LCs


And about which one is "better"... Personally, I'd go with ISSU (limitations apart) because it alternates both Managemnet Modules so you know, in every upgrade, that both MMs are good.

What do you think?

Regards
​
Original Message:
Sent: Nov 02, 2022 11:37 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi Ulises,

To answer your question:

"Do you know if Live-upgrade actually upgrade the redundant management module, if any?"

we should understand what is going to happen when we simply perform a manual update of a standalone chassis of Aruba CX 6400 equipped with two MMs deployed in a Active/Standby configuration (thus without ISSU): the Chassis will be instructed to reboot after the new AOS-CX software image is saved into the Primary or Secondary Flash memory area of the AMM (and we all expect that new flashed AOS-CX software image is also automatically copied into the corresponding SMM Flash memory area, as example...if the new AOS-CX software image is going to be saved into the Standby flash area of the AMM...then the very same operation should automatically happen on the SMM under the AMM administration...then the whole chassis will reboot and, post reboot, the AMM and the SMM are aligned as they were exactly before the chassis rebooted...eventually the alternate Flash memory areas not touched by the software update could be aligned too, on the AMM it should be enough to copy again the new AOS-CX Software Image into the Flash memory area not touched by the whole process...but this is eventually a secondary step once the new software is checked to run flawlessly for some time).

So, coming back to your question, given that VSX Live Upgrade is related to an orchestrated way of updating the VSX Cluster software and given that it automates manual operations between the two VSX Members (also introducing specific controls and features), I expect that performing a VSX Live Upgrade against an Aruba 6400 VSX Cluster where each chassis has two MMs operating in Active/Standby mode, will necessarily update both MMs on each chassis (that, again, will reboot).

From this point of view performing a VSX Cluster software update using the manual way (old way, no VSX Live Upgrade) will produce the very same outcome (AMM and SMM will be aligned with the same AOS-CX software version on their corresponding updated Image area, Primary or Secondary).

Totally different is the case of VSX Live Upgrade with ISSU on each Aruba 6400 Chassis (with two MMs).


Original Message:
Sent: Oct 31, 2022 02:27 PM
From: Ulises Cazares
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi, this is interesting and got me to read about the 2 of them a little bit more.

I got a doubt on my own lol

Do you know if Live-upgrade actually upgrade the redundant management module, if any?
Original Message:
Sent: Oct 28, 2022 03:00 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Any opinion?
Original Message:
Sent: Oct 01, 2022 08:39 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.10 ISSU and VSX interoperability (Aruba CX 6400 Switch Series)

Hi, I was reading about the new ISSU feature provided by ArubaOS-CX 10.10 and currently available only on Aruba CX 6400 Switch series when equipped with two Management Modules.

This suggestion (see here) about performing ISSU on a VSX deployment:

"VSX environments: In order to minimize a potential downtime, it is strongly recommended that in a VSX topology ISSU is performed at different times for each switch. E.g., run ISSU on the primary switch, verify that it was successful, and then perform ISSU for the secondary switch."

which is totally reasonable, make me to ask if VSX Live Upgrade and ISSU approaches can be played together in a orchestrated way or the fact that ISSU was engineered to let an hitless AOS-CX software update a single Chassis (with dual MMs), that standpoint doesn't couple well with the idea of using it also on a VSX deployment and its specific way of performing (fully automated and orchestrated) software updates of its VSX Members. Any opinion?

I know that, considering the specific case of a VSX, instead of relying on the VSX Live Upgrade procedure we are still free to proceed the old way (first upgrading the VSX Secondary then the VSX Primary, manually)...and so this can be coupled - as suggested in the above note - with applying first the ISSU on the VSX Secondary and only then on VSX Primary to complete the whole update procedure.

Mine is an attempt to understand - added complexity of operations apart - how much resilient is a VSX of Aruba 6400 with dual MMs if we introduce and manually perform the ISSU approach on each VSX Member compared to not introducing it at all and continue to live with the VSX Live Upgrade feature.

Maybe I'm trying a way to compare how better is (from a operational/management standpoint) is a VSX of Aruba 6400 with dual MMs on each VSX Members (with or without using ISSU) and a standalone Aruba 6400 with dual MMs and, again, operationally speaking, using ISSU during software updates. I know that isn't fair to compare a standalone Chassis versus VSX...but the VSX Live Upgrade and ISSU made me think.

Just thinking...