Network firmware management: from scattered versions to organised upgrade campaigns.
Knowing that firmware is behind is only the beginning. ConnectMyAssets shows the version each network device runs and the one it should run, keeps your images in one library, and carries out firmware upgrade campaigns in waves, reviewed before launch and verified step by step, without ever restarting both members of an MLAG, vPC or VSX pair at the same time.
Review before launch, then launch now or at a date
MLAG, vPC and VSX pairs never upgraded together
Every vendor, model and version of the fleet, and the target each device should run.
5vendor profiles with an upgrade procedure
1 000devices at most per campaign
Now or laterlaunch at once or at the date you choose
MLAG · vPC · VSXpairs never upgraded on both members at once
USE CASES
Firmware upgrades without the spreadsheet
Close a critical vulnerability fast
A CVE hits a firmware line you run: add the fixed image to the library, see every device behind it, and launch a pilot wave then the rest of the fleet.
Standardise versions across sites
Set one target per model on the top group, or a different one for a site that needs it, and follow the convergence of the fleet on the Versions page.
Upgrade data centre pairs safely
Campaigns know your MLAG, vPC and VSX pairs and never restart both members at once, so the service stays up during the upgrade.
Night-time maintenance windows
Review the campaign during the day and schedule it for the change window: it starts at the date you chose, and the journal of every device is waiting for you in the morning.
CAPABILITIES
Firmware management: from version visibility to the campaign
The Versions page shows who is behind, the library keeps the images, and every campaign is reviewed before launch and followed device by device.
01
Identify devices behind
The target of a device is the most recent active image that applies to its vendor, its model and its group. The Versions page shows the fleet by vendor, model and version, with how many devices are up to date and how many are behind; the CMDB offers firmware status and target as columns and filters.
02
An image library shared by group
Upload each image once, with the models it is for; its SHA-256 and MD5 are computed on upload. An image owned by a group can apply to the groups below, so a region shares its images with its sites.
03
The vulnerabilities of each image
Each image of the library shows its CVEs by severity, so you choose the target version knowing what it fixes and what it still carries. The choice stays yours: no image is hidden.
04
Review before launch
Before any launch, the review lists the devices per image with every line that will be typed, the devices left out and why, and the MLAG, vPC or VSX pairs involved. If the fleet changed in the meantime, nothing starts until you review again.
05
Launch now or at a date
Start the campaign immediately or schedule it for your maintenance window. A scheduled campaign can be cancelled until it starts, and a running one can be stopped.
06
An upgrade verified end to end
Configuration backup, flash space check, image copy from ConnectMyAssets, digest verification, install, save, reload, then a check of the version actually running and a new collection. Every step and every answer of the device is logged.
07
Campaigns in waves, pairs protected
Run a pilot wave, then wider ones, each up to 1 000 devices. Both members of an MLAG, vPC or VSX pair are never upgraded at the same time, and failed devices are retried in one action.
08
Permissions per group
Reading versions, managing images and upgrading devices are three separate permissions per group of network devices. A campaign only takes the devices its author may upgrade, and every action is audited.
SEE IT IN ACTION
From the devices that are behind to a reviewed campaign, in a few clicks.
HOW IT WORKS
How a firmware campaign runs
For network engineers: what is typed, where the image comes from and what happens on failure.
Only the vendor procedure is typed
What is typed on a device comes from its vendor profile and nothing else: no free text reaches the command line, and an unexpected question from the device stops the line instead of being answered blindly.
The image is served by ConnectMyAssets
The device fetches its image from the file service of ConnectMyAssets over SSH (SCP or SFTP), with a one-time credential drawn for that device and that transfer only, accepted from its management address.
One writer per device
A script, a ZTP provisioning and a firmware upgrade never run on the same device together, and a device being upgraded is not collected. The number of devices upgraded at once follows your sizing profile.
A failure stops that device, and says why
If a step fails, that device stops there with the step and the reason; the others continue. The configuration saved before the upgrade stays in its history, and on AOS-CX and ProCurve the previous image remains in the other bank.
A PRACTICAL WORKFLOW
From firmware behind to an upgrade campaign
01
Identify
Find the devices behind their target version on the Versions page.
02
Prepare
Add the image to the library and review the campaign.
03
Launch
Launch now or at a date, in successive waves.
04
Verify
Check the version running after the reload and retry the failures.
FAQ
Your questions, answered.
Prepare your project and define your scope.
Which vendors do firmware campaigns support?
Upgrade campaigns cover five vendor profiles today: Cisco IOS and IOS XE switches, Cisco NX-OS, Aruba AOS-CX, Aruba ProCurve (ArubaOS-Switch) and Huawei VRP. The Versions page tracks the firmware of every inventoried device, and more vendor procedures follow.
Should the entire fleet be upgraded at once?
No. Organise the upgrade in waves: a pilot group, then wider campaigns, each up to 1 000 devices, launched now or at a date. MLAG, vPC and VSX pairs are protected: both members never reload together. Validate the vendor prerequisites of each release on a spare device first.
What is checked before a campaign is launched?
The review shows every device with the image it will get and the lines that will be typed, the devices left out (no permission, vendor not supported, already up to date, already in a campaign, no credential) and the pairs involved. On each device, the flash space is checked and the image digest verified before anything is installed.
How does this relate to CVEs and EoL/EoS management?
CVE tracking informs security priorities, including the vulnerabilities of the images in the library. Firmware management handles versions and upgrade campaigns. EoL/EoS management identifies the devices whose support lifecycle calls for renewal. Together, they help choose between upgrading and replacing.
