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 two entry points to launch an upgrade:

From the site map: Select one or more devices, right-click, and choose a service from the NosImages category. For more details on device interactions from the map, see the Site Operations page.
From the scheduler (Schedule): Schedule an upgrade for deferred execution.

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

Limitation

Only the last image uploaded by Avalon can be activated. Images uploaded manually or by other means are not eligible.

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¶

Upload Phase¶

Avalon performs several checks before and during the transfer:

Image presence: If the image is already present on the device's disk, Avalon does not retransfer it but marks it as eligible for activation.
Disk space: Avalon verifies that available space is sufficient. For stacked devices, the check is performed on all stack members.
- If space is insufficient and the auto_cleanup option is enabled and supported, Avalon automatically cleans the disk before the transfer. The cleanup behavior is adapted to each platform and its boot mode.
Checksum validation: Once the transfer is complete, Avalon verifies the MD5 checksum of the file to ensure image integrity.

Activation Phase¶

Checks and actions depend on the chosen activation mode:

Image presence: Verifies that the image is present on the disk.
Disk space: Additional check for Cisco devices in INSTALL MODE.
Activation procedure depending on hardware:

With minimize_disruption enabled:
- For Cisco devices in INSTALL MODE with ISSU support: Avalon performs an ISSU check then launches ISSU activation with active process monitoring.
Without minimize_disruption:
- For Cisco IOS devices in bundle mode: Avalon configures the current image in second position (when possible), sets the new image first in the boot sequence, then validates the sequence.

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 automatically uses the ISSU procedure. Otherwise, it falls back to a standard upgrade.

Supported Platforms¶

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

Catalyst 9500 (C95)
Catalyst 9400 (C94)

Both must be configured in Stackwise Virtual topology.

Eligibility Criteria¶

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

Criterion	Required value
Model	Catalyst 9500 (C95) or Catalyst 9400 (C94)
Technology	Stackwise Virtual
Minimum version	IOS XE 16.9.2
Boot mode	Install mode (`packages.conf` in running image)
Redundancy	SSO (Stateful Switchover) active
Topology	2 Stackwise Virtual switches in `Ready` state
Autoboot	`manual_boot = no` on both Active and Standby
ISSU state	`Enabled`, no operation in progress
Packages	All in `Committed` state
Disk space	Sufficient space on `bootflash:` and `stby-bootflash:` (dynamically calculated based on image size)

If any criterion is not met, Avalon reports the issue in the transaction log and falls back to a standard upgrade (or aborts if the failure is critical).

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)

How It Works¶

When ISSU is triggered, Avalon performs the following steps:

Pre-flight checks: Avalon validates all eligibility criteria listed above
ISSU activation: Avalon launches the ISSU procedure on the device
Active monitoring: Avalon continuously monitors ISSU progress (timeout: 40 minutes)
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
Reconnection: After the switchover, Avalon reconnects to the device
Post-upgrade validation: Avalon verifies that the new version is active and that the device state is clean
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 + Stackwise Virtual
Supported models	C2960X, C38, C45, C92-95	C94, C95 in Stackwise Virtual only
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.