Aruba 2930F Switch Firmware Upgrade

2020年11月16日 LOG admin

原文：Aruba 2930F Switch Firmware Upgrade — theDXT (Daniel Keer)

Because config1 is my main config file I want to make a copy of it to config2

run the command copy config config1 config config2 to do that

Use something like SolarWinds TFTP and copy the config off of the switch

type the command to copy the config off the switch copy startup-config tftp IP_TFTP_SERVER Switch_config_WC.16.10.0009.cfg

Because we want to flash the primary image we will take a backup by copying it to the secondary image

run the command copy flash flash secondary
confirm it worked by typing show flash

You want to make sure that the secondary image is setup to boot with config2

run the command startup-default secondary config config2

Now it’s time to flash the firmware

run the command copy tftp flash IP_TFTP_SERVER WC_16_10_0011.swi

after its done copying the switch will validate it

once you get the command line again type show flash to make sure all is good.

reboot the switch to the new image by typing in boot system flash primary
wait for the switch to reboot
SSH back into the switch
type show version to confirm everything

You are all done.

What this procedure is actually protecting you from

Flashing a switch in place is the quick way to upgrade, and it is also the way people brick switches. The idea behind the steps above is that at every moment there are two of everything: two firmware images, two configuration files, and a copy of the configuration sitting on a TFTP server that is not the switch. If the new image boots badly, you boot the old one. If the new configuration misbehaves, you boot the old one. And if the switch does not come up at all, you still have a text file you can paste into a fresh unit.

If you only take one thing from this page, take the two backups: the configuration off the box, and the known-good primary image preserved in the secondary slot. Everything else can be repeated; those two cannot be recreated after the fact.

Before you start

Read the release notes. The 2930F runs Aruba’s AOS-Switch (ProVision) 16.x code train. Check the Aruba support portal for the newest release supported on your exact model, and read the release notes for recommended intermediate versions — a jump of several major releases in one go is sometimes disallowed.
Get the right file. Aruba firmware ships as a .swi file that is model-specific. Uploading a 2930M or 2930F-for-a-different-family image will be rejected, or worse, accepted and then fail to boot.
Have a TFTP server ready. SolarWinds TFTP Server is what the original post used, and any TFTP server will do — the switch is the client. Make sure the server’s firewall allows UDP/69, that the switch can ping it, and that the server’s root directory has both the new .swi and space for the config you are about to upload.
Check the free space and your access. show flash for image space, and confirm you have console or out-of-band access in case the management interface does not come back.
Pick a window. The switch reloads twice in this procedure. Users notice.

How a 2930F stores images and configs

Understanding the storage model makes the commands obvious:

Two firmware images live in flash: primary and secondary. Only one is active at a time.
Two configuration files live alongside them: config1 and config2. Each image can be associated with a config file in the startup default, which is how you get the “boot the old image with the old config” safety net.
The startup default decides which image and which config are used at the next reboot, unless you override it at the boot prompt.

That is why the procedure copies the running config into a second file first: config1 stays exactly as it is, and config2 becomes the copy you fall back to.

Step 1 — Copy config1 to config2

copy config config1 config config2

The switch acknowledges the copy and returns you to the prompt. On a 2930F with a modest configuration this takes a second or two.

Step 2 — Copy the configuration off the switch

Using a TFTP server (SolarWinds TFTP is the author’s tool of choice):

copy startup-config tftp 10.20.30.40 Switch_config_WC.16.10.0009.cfg

Substitute your TFTP server address and whatever filename convention you use — naming the file after the existing firmware version makes it obvious later which build the config belongs to. If the transfer fails, the error message is almost always one of three things: no route to the TFTP server, a host firewall blocking UDP/69, or the target filename already existing on the server with the wrong permissions.

Step 3 — Preserve the current primary image

Because we want to flash the primary image we will take a backup by copying it to the secondary image:

copy flash flash secondary

Confirm it worked:

show flash

The output lists the images in both slots with their versions and checksums. You should see the currently running version in both primary and secondary now. If the secondary slot already contained something and the copy fails for space reasons, you will have to free space before continuing.

Step 4 — Point the default boot at secondary and config2

You want to make sure that the secondary image is setup to boot with config2:

startup-default secondary config config2

This command writes the startup default only; it changes nothing until the next reboot. Verify it with show startup-config, or by checking the boot configuration shown in show version. From this point on, if the new primary image fails to boot or fails to talk to the network, a plain reload brings the switch back on the old image with the copied configuration.

Step 5 — Copy the new firmware into flash

Now it’s time to flash the firmware:

copy tftp flash 10.20.30.40 WC_16_10_0011.swi

The switch copies the file into the primary flash slot, then validates it. Validation is not decoration — the image carries a checksum and the switch refuses to mark a corrupt or mismatched file as bootable, which is exactly the behaviour you want.

When you get the command line back, check the result:

show flash

The primary slot should now show the new software version and the secondary slot should still show the old one. If the new version appears in neither slot, the copy or validation failed — re-check the filename, the TFTP server log, and the free space, and do not reboot yet.

Step 6 — Reboot into the new image

boot system flash primary

The switch asks for confirmation, then reboots. Wait for it to come back — a 2930F with a full configuration and PoE ports takes a few minutes — then SSH back in and confirm:

show version

The version banner should show the new firmware, the configuration should be the one you have been running, and the switch should be forwarding traffic. You are all done.

Verifying the upgrade properly

show version is the headline check, but a firmware upgrade deserves a couple of minutes of verification before you close the ticket:

show version
show flash
show boot-history
show interfaces brief
show trunk
show spanning-tree

show version confirms the running image and the uptime (it should be minutes, not days).
show flash confirms the slot layout is what you expect, with the new code in primary.
show boot-history shows recent reboots and why they happened — useful if the switch rebooted again on its own.
show interfaces brief shows link state on every port. A port that used to be up and is now down is the fastest signal that a configuration was not carried over.
show trunk or your LACP verification command confirms uplinks came back aggregated rather than half-up.
Check the log for new complaint messages: show logging -r pages through recent events newest-first.

Then save the state you just verified:

write memory
copy startup-config tftp 10.20.30.40 Switch_config_WC.16.10.0011.cfg

The second command is the one people skip. It gives you a configuration backup that matches the firmware actually running, which is the file you want the next time this switch has a bad day.

Rollback and troubleshooting

The new image will not boot. Let the switch finish, then reload. If it still will not come up, interrupt the boot and boot the secondary image, or rely on the startup default you set in step 4. Confirm with show flash which slot holds the good image.
It boots but the network is broken. Reload to boot secondary with config2 — the configuration you copied in step 1 — and diff it against the running config to see what changed.
TFTP copy times out. Check that the switch can ping the TFTP server, that UDP/69 is open in the server’s firewall, and that no VPN or ACL is filtering the management VLAN. Large .swi files over a congested link are also slow: give the copy time before declaring failure.
Not enough flash space. Free the slot you are not booting from before you copy. Never erase or overwrite the image the switch is currently running from — that is the one scenario that really does require a console cable and a TFTP recovery.
You downgrade later. Downgrades usually work by booting the secondary slot, but configuration written by the newer firmware may not be understood by the older one. Keep the matching config file from before the upgrade, which is exactly what step 2 produced.