Cloud Managed Networks

When CNX firmware policies go GA on your cluster is HPE's call, so your HPE SE or TAC is the one to give you a date for EU-Central3. While you've got them, log VSX awareness in the firmware policy as a feature request. Rebooting both peers at once rather defeats the point of VSX.

Until then you don't need Central to stage anything. From the VSX primary, vsx update-software tftp://<server>/<image> vrf mgmt downloads to the alternate bank on both peers and reboots them in turn, secondary first. If the image is already on both, vsx update-software boot-bank primary|secondary (whichever bank you staged it in) runs the same sequence. The AOS-CX 10.16 VSX guide lists the pre-checks (ISL in sync, keepalive established, loop-protect action tx-disable on the MC LAGs): https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/vsx/Content/Chp_Upg/upg-swi-usi-vsx-upd-sof-com-10.htm 

If you'd rather keep it in Central, put each peer in its own device group and give each one its own policy in a separate window.

Amazing how many places CNX is a step back from Classic. Why make it even more cumbersome and difficult to update VSX than before? :-(
Now I have to stand up a TFTP server and download the images manually, or search for the exact Central URL to fetch it from. Before I could at least stage it with a simple click.

When CNX firmware policies go GA on your cluster is HPE's call, so your HPE SE or TAC is the one to give you a date for EU-Central3. While you've got them, log VSX awareness in the firmware policy as a feature request. Rebooting both peers at once rather defeats the point of VSX.

Until then you don't need Central to stage anything. From the VSX primary, vsx update-software tftp://<server>/<image> vrf mgmt downloads to the alternate bank on both peers and reboots them in turn, secondary first. If the image is already on both, vsx update-software boot-bank primary|secondary (whichever bank you staged it in) runs the same sequence. The AOS-CX 10.16 VSX guide lists the pre-checks (ISL in sync, keepalive established, loop-protect action tx-disable on the MC LAGs): https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/vsx/Content/Chp_Upg/upg-swi-usi-vsx-upd-sof-com-10.htm 

If you'd rather keep it in Central, put each peer in its own device group and give each one its own policy in a separate window.

Amazing how many places CNX is a step back from Classic. Why make it even more cumbersome and difficult to update VSX than before? :-(
Now I have to stand up a TFTP server and download the images manually, or search for the exact Central URL to fetch it from. Before I could at least stage it with a simple click.

Original Message:
Sent: Sep 23, 2026 10:55 AM
From: DB86
Subject: CNX firmware policies - features and availability

When CNX firmware policies go GA on your cluster is HPE's call, so your HPE SE or TAC is the one to give you a date for EU-Central3. While you've got them, log VSX awareness in the firmware policy as a feature request. Rebooting both peers at once rather defeats the point of VSX.

Until then you don't need Central to stage anything. From the VSX primary, vsx update-software tftp://<server>/<image> vrf mgmt downloads to the alternate bank on both peers and reboots them in turn, secondary first. If the image is already on both, vsx update-software boot-bank primary|secondary (whichever bank you staged it in) runs the same sequence. The AOS-CX 10.16 VSX guide lists the pre-checks (ISL in sync, keepalive established, loop-protect action tx-disable on the MC LAGs): https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/vsx/Content/Chp_Upg/upg-swi-usi-vsx-upd-sof-com-10.htm 

If you'd rather keep it in Central, put each peer in its own device group and give each one its own policy in a separate window.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

Amazing how many places CNX is a step back from Classic. Why make it even more cumbersome and difficult to update VSX than before? :-(
Now I have to stand up a TFTP server and download the images manually, or search for the exact Central URL to fetch it from. Before I could at least stage it with a simple click.

Original Message:
Sent: Sep 23, 2026 10:55 AM
From: DB86
Subject: CNX firmware policies - features and availability

When CNX firmware policies go GA on your cluster is HPE's call, so your HPE SE or TAC is the one to give you a date for EU-Central3. While you've got them, log VSX awareness in the firmware policy as a feature request. Rebooting both peers at once rather defeats the point of VSX.

Until then you don't need Central to stage anything. From the VSX primary, vsx update-software tftp://<server>/<image> vrf mgmt downloads to the alternate bank on both peers and reboots them in turn, secondary first. If the image is already on both, vsx update-software boot-bank primary|secondary (whichever bank you staged it in) runs the same sequence. The AOS-CX 10.16 VSX guide lists the pre-checks (ISL in sync, keepalive established, loop-protect action tx-disable on the MC LAGs): https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/vsx/Content/Chp_Upg/upg-swi-usi-vsx-upd-sof-com-10.htm 

If you'd rather keep it in Central, put each peer in its own device group and give each one its own policy in a separate window.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

Amazing how many places CNX is a step back from Classic. Why make it even more cumbersome and difficult to update VSX than before? :-(
Now I have to stand up a TFTP server and download the images manually, or search for the exact Central URL to fetch it from. Before I could at least stage it with a simple click.

When CNX firmware policies go GA on your cluster is HPE's call, so your HPE SE or TAC is the one to give you a date for EU-Central3. While you've got them, log VSX awareness in the firmware policy as a feature request. Rebooting both peers at once rather defeats the point of VSX.

Until then you don't need Central to stage anything. From the VSX primary, vsx update-software tftp://<server>/<image> vrf mgmt downloads to the alternate bank on both peers and reboots them in turn, secondary first. If the image is already on both, vsx update-software boot-bank primary|secondary (whichever bank you staged it in) runs the same sequence. The AOS-CX 10.16 VSX guide lists the pre-checks (ISL in sync, keepalive established, loop-protect action tx-disable on the MC LAGs): https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/vsx/Content/Chp_Upg/upg-swi-usi-vsx-upd-sof-com-10.htm 

If you'd rather keep it in Central, put each peer in its own device group and give each one its own policy in a separate window.

" Before I could at least stage it with a simple click."

Well, say goodbye to that.  Apparently HPE doesn't want anything to be simple anymore.  No more "simple clicks".

Amazing how many places CNX is a step back from Classic. Why make it even more cumbersome and difficult to update VSX than before? :-(
Now I have to stand up a TFTP server and download the images manually, or search for the exact Central URL to fetch it from. Before I could at least stage it with a simple click.

When CNX firmware policies go GA on your cluster is HPE's call, so your HPE SE or TAC is the one to give you a date for EU-Central3. While you've got them, log VSX awareness in the firmware policy as a feature request. Rebooting both peers at once rather defeats the point of VSX.

Until then you don't need Central to stage anything. From the VSX primary, vsx update-software tftp://<server>/<image> vrf mgmt downloads to the alternate bank on both peers and reboots them in turn, secondary first. If the image is already on both, vsx update-software boot-bank primary|secondary (whichever bank you staged it in) runs the same sequence. The AOS-CX 10.16 VSX guide lists the pre-checks (ISL in sync, keepalive established, loop-protect action tx-disable on the MC LAGs): https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/vsx/Content/Chp_Upg/upg-swi-usi-vsx-upd-sof-com-10.htm 

If you'd rather keep it in Central, put each peer in its own device group and give each one its own policy in a separate window.