Remote EXOS Upgrade with No Console Access
An X460-G2-48t at a remote warehouse runs ExtremeXOS 22.7.3.5 and is managed only through VLAN 99 on a single 1G copper uplink to an ISP CPE. SSH is restricted to 10.20.0.0/24, NTP is synchronized, and the running config is saved. The switch must move to 31.7.1.100 to support a new ExtremeCloud IQ agent. The image is 210 MB. The local TFTP server is blocked by policy, but an SCP server at 10.20.0.50 is reachable. There is no console server at the site, and a site technician can only power-cycle the switch. The change window is 45 minutes. The current boot flag points to primary, and the secondary partition contains an older 22.6 image.
1. Outline a safe upgrade sequence, including the commands or actions you would use and how you would verify each step.
Read the worked answer
Save and export the config, record 'show version', 'show boot', 'show image', and free space. Download the 31.7 image to the secondary partition over SCP, for example 'download image 10.20.0.50 exos-31.7.1.100.xos secondary', then install or verify it and confirm the secondary partition is bootable. Do not overwrite primary 22.7.3.5; it is the fallback. Set the boot partition to secondary with 'use image secondary', reboot during the window, and reconnect. Verify 'show version', 'show boot', 'show image', VLAN 99 reachability, SSH restriction, NTP, and the new agent. Save the config. Keep an SCP session and a ping running; if the switch returns on the old image, investigate before retrying.
2. What is your rollback plan if the switch does not return after reboot, given no console access?
Read the worked answer
With no console, rollback options are limited. If the switch does not return, ask the technician to power-cycle once; confirm link LEDs and whether it obtains management access. If it still fails, you cannot change the bootloader remotely. The practical rollback is a smart-hands console session to select the primary partition, or RMA and replacement. That is why the primary partition must remain intact. Pre-stage a console kit and a tested spare, and schedule the change with a longer window. Do not rely on a remote reboot into a golden image unless auto-configuration is already designed and tested.
3. Why is overwriting the primary partition a poor choice in this scenario?
Read the worked answer
Overwriting primary destroys the known-good image and leaves no local fallback if 31.7 has a boot or driver issue. The secondary contains an older 22.6 image and may not be compatible with the saved 31.7 config or the new agent. Keeping primary 22.7.3.5 gives a quick console-selectable rollback and reduces truck-roll risk. Only overwrite it after 31.7 has run successfully through a stabilization period.