Device Upgrades

Network device upgrades in Avalon allow you to upload and activate NOS (Network Operating System) images on your devices in a centralized and controlled manner. Avalon manages the entire process: disk space verification, image transfer, checksum validation, and activation according to vendor-specific procedures.

Prerequisites

Before upgrading a device, you must upload NOS images to Avalon and associate them with a device family. Once this association is complete, the image becomes available for all devices whose model is linked to that device family.

For more details on uploading images, see the Device images page.

Access Methods

Avalon provides three entry points to launch an upgrade, and they do not behave alike: the first two name an image, the third states an intention.

• From the site map: Select one or more devices, right-click, and choose a service from the NosImages category. The image is picked from a list. For more details on device interactions from the map, see the Working with a site map page.

• From the scheduler (Schedule): Schedule an upgrade for deferred execution. The image is picked from the same list.

• From an engineering rule: The rule names no image. Each device receives the target image declared on its own device model, in Inventory then Device Models. One rule therefore covers a mixed fleet, and a model with no target declared is simply left out rather than failing the rule. See the Engineering page.

Why the third one exists

Written as a campaign, an upgrade names one image and has to be relaunched for every model. Written as a rule, it says "every device runs the image decided for its model", and the decision lives in the catalogue where it is made once. Failure thresholds, a deployment cutoff date and ordering by criticality are available on all three.

Available Services

uploadnosimage

Performs a simple upload of the image to the device without activating it. Useful for pre-positioning an image before a maintenance window.

Option	Description
Image	The NOS image to transfer
auto_cleanup	Automatically cleans the disk if space is insufficient. Supported on Cisco devices in INSTALL MODE and BUNDLE MODE.
VRF	The VRF to use for retrieving the image via TFTP from Avalon

activatenosimage

Activates an image that was previously uploaded by Avalon.

Option	Description
Image	The NOS image to activate
minimize_disruption	Enables a hitless upgrade process (e.g., ISSU on Cisco)
VRF	The VRF to use for retrieving the image via TFTP from Avalon

What the image list offers

From the map and from the scheduler, the list offers only the last image Avalon uploaded successfully, and only when it differs from the one currently active. An image put on the device by any other means is not offered.

An engineering rule does not go through that list: it names the target declared on the device model, whatever put the file there. Before reloading, Avalon then checks that the image is on the disk, that it is in its own catalogue, and that its checksum matches. Any of the three failing stops the operation without touching the device.

upgradevice

Performs upload and activation in a single operation. This is the most commonly used service for a complete upgrade.

Option	Description
Image	The NOS image to deploy
minimize_disruption	Enables a hitless upgrade process (e.g., ISSU on Cisco)
auto_cleanup	Automatically cleans the disk if space is insufficient. Supported on Cisco devices in INSTALL MODE and BUNDLE MODE.
VRF	The VRF to use for retrieving the image via TFTP from Avalon

Checks Performed on Cisco IOS and IOS XE

The two diagrams below describe the Cisco sequence, and only that one. Install and bundle boot modes, the configuration register, ISSU and the two-step installation commit are Cisco notions with no equivalent elsewhere: Aruba OS-CX works with two image banks, primary and secondary, and follows the procedure described in its own section further down.

Within Cisco, the sequence does not depend on where the update was launched from: the map, a schedule and an engineering rule all go through exactly these steps. Every refusal happens before anything is written to the device.

Transfer phase

From the request to the image sitting on the disk. uploadnosimage stops here; upgradevice carries straight on to the next diagram.

graph TD
    Start[Upload requested] --> FS{File system<br/>readable?}
    FS -->|No| Stop[Stopped<br/>nothing written to the device]
    FS -->|Yes| Present{Image already<br/>on the disk?}
    Present -->|Yes, checksum differs| Stop
    Present -->|Yes, checksum matches| Ready[Image in place<br/>offered for activation]
    Present -->|No| Space{Enough space,<br/>or auto_cleanup?}
    Space -->|No| Stop
    Space -->|Yes| Register{Register correct,<br/>where required?}
    Register -->|Cannot be set| Stop
    Register -->|Yes| Transfer[Transfer over TFTP<br/>progress watched live]
    Transfer --> Sum{Checksum matches<br/>the catalogue?}
    Sum -->|No| Stop
    Sum -->|Yes| Ready

Activation phase

From the request to a device running the new release. activatenosimage starts here, on an image already on the disk.

graph TD
    Act[Activation requested] --> Same{Already runs<br/>the target release?}
    Same -->|Yes| Done[Success, no reload]
    Same -->|No| Asked{minimize_disruption<br/>requested?}
    Asked -->|Yes| Eligible{Model, redundancy,<br/>version path,<br/>prerequisites?}
    Eligible -->|No| Stop[Stopped<br/>nothing changed, no reload]
    Eligible -->|Yes| ISSU[ISSU<br/>about 1s of disruption]
    Asked -->|No| Checks{On disk, in catalogue,<br/>checksum matching?}
    Checks -->|No| Stop
    Checks -->|Yes| Mode{Boot mode?}
    Mode -->|Bundle| Boot[New image first<br/>current one second as fallback]
    Mode -->|Install| Reload[Full reload]
    Boot --> Reload
    ISSU --> Verify{Running release<br/>matches the target?}
    Reload --> Verify
    Verify -->|No, or unreadable| Failed[Failure<br/>came back on the previous release]
    Verify -->|Yes| Commit{Two-step install<br/>left to commit?}
    Commit -->|Commit refused| Failed
    Commit -->|No, or committed| Saved[Configuration saved<br/>upgrade complete]

What the diagram does not show

The image already on the disk. Nothing is transferred, and this is the one case nothing else verifies: the file was put there by an earlier attempt, by another run, or by hand, and its checksum is the only thing that says whether it is the image that was asked for.

It still counts as a successful upload, and that matters: the map and the scheduler offer for activation the last image Avalon uploaded successfully, so an image found in place and verified becomes the one they propose. Without that, a transfer that had nothing to do would leave the image unselectable and force a pointless re-transfer.

The fallback in the boot order. In bundle mode the currently active image is written second, so a device that cannot boot the new one comes back on the one it was running. Avalon then reports a failure: the reload happened, but not the upgrade.

The two-step installation. When the device answers that the package is already added, the activation is confirmed only after the reload. Without that confirmation the device reverts to its previous release on its own after a delay, with nothing announcing it, so a refused commit is a failure even though the device is running the new release at that moment.

Who decides what. In install mode the device validates the package and refuses one that is incomplete; Avalon adds nothing. In bundle mode the device boots whatever it is pointed at and checks nothing, which is why the three checks exist on that path only.

And none of this applies to Aruba. There, activation means designating a bank to boot from, the device holds two images at all times, and the rollback is the other bank rather than a boot order. See the Aruba section below.

Aruba OS-CX: the sequence

Nothing above applies here. A CX switch holds two image banks, primary and secondary, and it always keeps both: activating means designating which one to boot from, and recovering from a bad image means booting the other. There is no boot order to write, no configuration register, no ISSU, and no rollback to arm, because the other bank is the rollback.

graph TD
    Start[Upload requested] --> Disk{Image already<br/>on a bank?}
    Disk -->|Cannot be read| Stop[Stopped<br/>nothing written to the device]
    Disk -->|Yes| Ready[Nothing to transfer]
    Disk -->|No| Bank{Which bank<br/>is active?}
    Bank -->|Unreadable| Stop
    Bank -->|Known| Target[Target is the OTHER bank<br/>the running one is never touched]
    Target --> Copy[Copy into that bank<br/>over the chosen VRF]
    Copy --> Timeout{Transfer finished<br/>in time?}
    Timeout -->|No| Stop
    Timeout -->|Yes| Sum{Checksum of the bank<br/>matches?}
    Sum -->|No| Stop
    Sum -->|Yes| Ready

graph TD
    Act[Activation requested] --> Which{Which bank HOLDS<br/>the requested image?}
    Which -->|Neither| Stop[Stopped<br/>upload it first]
    Which -->|The active one| Done[Success, no reboot<br/>already running it]
    Which -->|The other one| Boot[Boot on that bank]
    Boot --> Accepted{Command<br/>accepted?}
    Accepted -->|No| Stop
    Accepted -->|Yes| Down{Device actually<br/>went down?}
    Down -->|Never went down| Failed[Failure<br/>the command was accepted but nothing rebooted]
    Down -->|Yes| Up{Back online,<br/>and reachable over SSH?}
    Up -->|No| Failed
    Up -->|Yes| Verify{Running version<br/>matches the image?}
    Verify -->|No| Failed
    Verify -->|Yes| Saved[Upgrade complete]

The bank is chosen from what the banks hold, never by flipping the active one. Asking to activate an image the device already runs therefore ends in a success without a reboot, and the version read from the target bank is written back to Avalon, realigning an inventory that had lost track.

VSX is refused when the two chassis do not boot the same bank, and Avalon checks that before transferring anything: the pair would otherwise be left inconsistent. The VSX orchestration command itself is deliberately not used here.

On VSF, the stack synchronises the image to its members on its own, and boot system reboots the whole stack. Avalon does not wait for that sync to finish, which is why rebooting a member mid-sync is the one way to make it fail to rejoin.

No automatic rollback on Aruba OS-CX

Unlike Cisco in bundle mode, where the previously active image is written second in the boot order and the device falls back on it by itself, AOS-CX offers nothing equivalent. The other bank is left untouched, so the previous image is still there, but booting back on it is a manual operation that takes someone on site or a console. Plan the maintenance window accordingly: a device that does not come back will not recover on its own.

What Avalon handles, per vendor and model

Two questions decide everything: is the model supported at all, and which boot mode does the device run. The boot mode is not a property of the model but of the device: Avalon reads it from the running image, packages.conf meaning install mode and anything else meaning bundle. A model that supports both therefore appears in both columns.

No image rollback, on any platform

No driver brings the previous image back on its own when an activation fails. On AOS-CX the other bank is left intact, so a bad image is recovered by booting back on it. On IOS and IOS XE recovery goes through the console. Either way it takes someone on site or a console session, and that is what the maintenance window has to account for.

The automatic rollback Avalon does arm is a configuration one, and it belongs to Config Sets: configure replace ... time on IOS, checkpoint auto on AOS-CX. Neither ever applies to an image.

Cisco IOS and IOS XE

Model	Supported	Install	Bundle	ISSU	Notes
C9400, C9500	yes	yes	yes	yes	ISSU requires Stackwise Virtual or a dual supervisor
C9200, C9300	yes	yes	yes	no	The usual install-mode platforms
C3850, C3650 (C38)	yes	yes	yes	no
C3560 (C356)	yes	no	yes	no	Classic IOS
C2960C, C2960X	yes	no	yes	no	Classic IOS, no configuration register check needed
C9600	no				Covered by the register and drive rules but absent from the supported list: an upgrade is refused before starting
Catalyst 4500, 4500-X (C45)	yes	no	yes	no	The configuration register is read and set before the transfer
Cisco IOL	yes	no	yes	no	EVE-NG lab platform, file system unix:
ISR 4000, ASR 1000, C1100	no				Not in the supported list: an upgrade is refused before starting
Anything else Cisco IOS	no				Same, and the file system cannot be determined either

Stacks and redundancy

A Stackwise Virtual or VSS pair with a dual supervisor is refused, deliberately: the procedure differs and is not implemented. A plain Stackwise stack is supported, and the disk space check as well as the auto cleanup run on every member.

Aruba OS-CX

Model	Supported	Procedure	Notes
CX standalone	yes	Two image banks, primary and secondary
CX in VSX	yes	Both chassis must boot the same bank	Avalon verifies this before transferring anything and refuses otherwise
CX in VSF	yes

Other vendors

Vendor	Image transfer and activation
Cisco NX-OS	not implemented, declared as such
HP Comware, HP ProCurve	not implemented
Huawei VRP	not implemented
Arista EOS	not implemented
Palo Alto PAN-OS, Stormshield	not implemented, declared explicitly on the driver

What "not implemented" means

The service is not missing by accident: the driver declares the method as unavailable, so asking for an upgrade on those platforms answers a clear refusal rather than failing halfway. The rest of what Avalon does on them, inventory, connectivity, configuration backup where available, is unaffected.

Accepted image formats

Only two, and any other extension is refused at upload: .bin for Cisco, .swi for Aruba OS-CX. A .tar archive has to be expanded first, Avalon writing a boot path to the file it transferred rather than running the archive extraction procedure of the device.

Specific procedures

Cisco

Auto Cleanup

Automatic disk cleanup (auto_cleanup) is supported on Cisco IOS / IOS XE devices in both boot modes:

Install mode:

• Avalon runs the platform's native cleanup command to remove inactive packages.

Bundle mode:

• Avalon scans all drives on the device, including secondary members in a Stackwise or stack configuration.
• For each drive, the search covers both the root directory and subfolders.
• Only two images are kept: the currently running image and the target image (the one being uploaded). All other .bin files are removed.

ISSU (In-Service Software Upgrade)

ISSU is an upgrade method that minimizes service disruption. Unlike a standard upgrade that causes a full reload (~10 minutes of downtime), ISSU leverages hardware redundancy on dual-supervisor equipment to perform a "hot" upgrade with approximately 1 second of traffic disruption. The total process takes about 20 minutes.

ISSU is triggered by enabling the minimize_disruption option in the upgradevice or activatenosimage services. If the device meets all eligibility criteria, Avalon uses the ISSU procedure. Otherwise the operation fails and the device is left untouched: there is no silent fallback to a standard upgrade. Asking for minimize_disruption means accepting about a second of disruption, not ten minutes of downtime, so Avalon refuses rather than substituting a procedure you did not ask for.

Supported Platforms

ISSU is currently supported on Cisco IOS XE only, for the following models:

• Catalyst 9500 (C95): in Stackwise Virtual topology
• Catalyst 9400 (C94): in Stackwise Virtual topology or dual-supervisor configuration (SSO without SVL)

Eligibility Criteria

All of the following conditions must be met for ISSU to proceed:

Criterion	C9500 (Stackwise Virtual)	C9400 (dual-supervisor)
Model	Catalyst 9500 (C95)	Catalyst 9400 (C94)
Technology	Stackwise Virtual	Dual-supervisor (SSO)
Minimum version	IOS XE 16.9.2	IOS XE 16.9.2
Boot mode	Install mode (packages.conf)	Install mode (packages.conf)
Redundancy	SSO (Stateful Switchover) active	SSO (Stateful Switchover) active
Topology	2 SVL switches in Ready state	Chassis with 2 supervisors in Ready state
Autoboot	manual_boot = no on both Active and Standby	manual_boot = no on both Active and Standby
ISSU state	Enabled, no operation in progress	Enabled, no operation in progress
Packages	All in Committed state	All in Committed state
Disk space	Sufficient space on bootflash: and stby-bootflash:	Sufficient space on bootflash: and stby-bootflash:

If any criterion is not met, Avalon names which one in the transaction and stops the operation. All four checks, the model, the redundancy, the version path and the prerequisites, lead to the same outcome: a failure before anything is written. To go ahead regardless, launch again without minimize_disruption, which makes it an explicit choice.

Incompatible commands

Some configuration commands are incompatible with ISSU. Avalon detects and automatically removes them from the running-config before launching the procedure. The configuration is then saved for the removal to take effect.

Commands identified to date (Cisco documentation + field experience):

• snmp-server enable traps license
• ip http banner
• snmp enable traps energywise

Info

This list may evolve with future IOS XE versions.

Valid Upgrade Paths

ISSU does not support arbitrary version jumps. The following rules apply:

• IOS XE 16.x: upgrades within the same minor (e.g., 16.9.x to 16.9.y) or from 16.9.x to 16.12.x only
• IOS XE 17.x: upgrades within Extended Maintenance releases (17.3, 17.6, 17.9, 17.12, 17.15, 17.18) or within the same minor
• No downgrades are supported
• No major branch crossing (16.x to 17.x is not allowed via ISSU)
• Minimum source release: 16.9.2. Anything older is refused

IOS XE 26.x and later

The paths above cover 16.x and 17.x. A device running a newer branch, 26.x among them, is refused ISSU with an explicit message, ISSU validation not defined for version 26.x, and the operation the operation stops there, with no fallback. Validating the ISSU paths of that branch is in progress: until then, an upgrade of a 26.x device must be launched without minimize_disruption.

How It Works

When ISSU is triggered, Avalon performs the following steps:

1. Pre-flight checks: Avalon validates all eligibility criteria listed above
2. ISSU activation: Avalon launches the ISSU procedure on the device
3. Active monitoring: Avalon continuously monitors ISSU progress (timeout: 40 minutes)
4. Switchover: The standby supervisor upgrades first, then takes over as active. The former active supervisor upgrades and becomes standby. Traffic disruption is approximately 1 second during the switchover
5. Reconnection: After the switchover, Avalon reconnects to the device
6. Post-upgrade validation: Avalon verifies that the new version is active and that the device state is clean
7. Configuration save: The running configuration is saved

ISSU vs Standard Upgrade

Aspect	Standard upgrade	ISSU
Downtime	~10 min (full reload)	~1 second
Total duration	~10-15 min	~20 min
Hardware requirements	Minimal	Dual supervisor SSO (+ SVL for C9500)
Supported models	C2960X, C38, C45, C92-95	C94 (SVL or dual-sup), C95 (SVL)
Automatic rollback on failure	No	Yes

Rollback

If ISSU fails during the process, Avalon automatically attempts to abort the operation and restore the device to a known state.

Aruba

CX in VSX

For Aruba CX devices configured in VSX (Virtual Switching Extension), specific rules apply:

• All operations must be launched on the primary member
• It is not possible to launch an upload or activation directly on the secondary member
• Avalon drives the upgrade procedure from the primary member and monitors the overall process state
• When the primary reboots, Avalon temporarily loses the SSH connection then monitors the primary's return to reconnect and verify that the process is completed with the correct version

Roadmap

We are open to implementing specific procedures for other vendors or models. Contact us to discuss your needs.