Manual Chapter :
Upgrading Software
Applies To:
Show Versions
ARX
- 6.3.0
ARX software is distributed in release files, typically named with a .rel extension (for example, initial.rel or arx-0.5.0_dev.rel). To upgrade software on the ARX, you must
| the copy command to copy a full release file to the disk, and |
| the boot system command to unpack the release file on the disk. |
Software upgrades may require more planning for multiple ARX sites. You can configure a shadow-copy rule to copy data from a managed volume on one ARX to a shadow volume on another ARX; for details, see Chapter 16, Shadowing a Volume in the ARX® CLI Storage-Management Guide. To upgrade both sites, we recommend pausing all policy operations at the source volume (see Pausing All Rules in a Volume, on page 14-49 of the same manual), upgrading software at the target site, and then upgrading software at the source site.
Back up your current configuration before initiating an upgrade or downgrade procedure. The configuration is at risk, especially in a downgrade; this makes it possible to reload the configuration later. Save the network-configuration parameters (running-config) in one file and the storage-configuration parameters (global-config) in another file. Use the copy running-config command to back up the running-config, as described in Saving the Local Running Config. The copy global-config command saves the global-config, as described in Saving the Global Config.
bstnA(cfg)# exit
bstnA# copy running-config ftp://juser:jpasswd@ftp.wwmed.com/net_config
bstnA# copy global-config ftp://juser:jpasswd@ftp.wwmed.com/storage_config
bstnA# ...
You can use the show master-key command to display the master keys encrypted value. For example:
bstnA# show masterkey
System Password: %uper$ecretpw
Wrapping Password: an0ther$ecretpw
Validate Wrapping Password: an0ther$ecretpw
For detailed information about using this CLI command, refer to the ARX® CLI Reference.
After you copy your configuration, check the overall health of the ARX. Use the show health command to check for any alarm conditions:
bstnA# show health
bstnA# ...
Use the show cores command to confirm that no software processes failed and created a core-memory file for diagnosis:
bstnA# show cores
bstnA# ...
Review the trap and error logs to see if any noteworthy events have occurred. Execute show logs traplog and show logs error.log as appropriate, and execute tail logs traplog and tail logs error.log to view the file contents, if necessary. See Accessing the Syslog for complete information about accessing and reading these files. Investigate and resolve any issues that come to light.
Review the syslog to see if any noteworthy system events have occurred. Execute show logs syslog and tail logs filename to list and view the syslog files. See Accessing the Syslog for complete information about accessing and reading these files. Investigate and resolve any issues that come to light.
Release files consume large amounts of disk space, so the ARX only stores up to three release files (possibly more on some platforms). If your switch has the maximum releases already, you must delete an unused release before you copy a new one onto the chassis. Use the show releases command for a listing of current release files:
| R is the running release. |
| A is the armed release, the one that will run on the next reboot. By default, this is the same release as the running (R) release. |
| B is the backup release. F5 personnel can revert the switch back to this release if necessary. |
bstnA(gbl-ns[wwmed])# show releases
Use the show version command for a more-detailed view of the software versions:
bstnA(gbl-ns[wwmed])# show version
You cannot delete the running, armed, or backup release. To delete any other release file, go to priv-exec mode and use the delete releases command:
delete releases file
where file (1-1024 characters) identifies the release file. You can use wildcards (such as * for a string, ? for a single character, or [A-Z] for any uppercase letter).
bstnA# delete releases test1.rel
bstnA# show releases
bstnA# ...
You reach the Downloads page after the F5 site accepts your credentials. Navigate from this page to the desired ARX release, and follow the instructions to download the release file to the current machine. Release files are very large, so the download can take a long time.
The copy command requires the specific namespace and volume where the release file resides. Use show cifs-service fqdn for a map of fqdns front-end CIFS shares to its ARX volumes; see Focusing on One CIFS Service, on page 11-39 of the ARX® CLI Storage-Management Guide. For an NFS export, use show nfs-service fqdn (Showing One NFS Service, on page 11-8 of the same manual).
Then, from priv-exec mode, use copy cifs or copy nfs to copy the release file to the releases directory:
cifs | nfs is a required choice. This is the network protocol used to copy the release file out of the ARX volume.
namespace (1-30 characters) identifies the namespace. You can find the correct namespace from the output of show cifs-service or show nfs-service.
volume (1-1024 characters) is the volume name. For a CIFS share, use the output of show cifs-service to find the volume name (such as /rcrds) behind a share name (such as ARCHIVES). For an NFS export, use the output of show nfs-service to find the volume name.
file-path (1-1024 characters) is the path from the volume root (above) to the release file.
releases is the destination directory.
dest-file (1-1024 characters) is the name you choose for the local copy of the release file.
For example, the following command sequence shows the namespace and volume behind \\ac1.medarch.org\ARCHIVES (highlighted in bold text below), copies the release file from that volume, then uses show releases to confirm that the file was copied:
bstnA# show cifs-service ac1.medarch.org
Exports for Namespace: medarcv
bstnA# copy cifs medarcv /rcrds admin/12345.rel releases test5.rel
bstnA# show releases
bstnA# ...
If the client machine supports FTP transfers to the ARX, you can use copy ftp instead:
username:password@ (optional) is an FTP username and password (the default is the username/password set by the ip ftp-user command; see Setting a Default FTP or SCP User),
ftp-site identifies the FTP server with an IP address or FQDN (for example, 172.16.88.3 or ftp.myftpsite.com),
releases is the destination directory on the ARX, and
dest-file is the name you choose for the local copy of the release file.
For example, the following command sequence copies a release file from mysrv.wwmed.com, then uses show releases to confirm that the file was copied:
bstnA# copy ftp://jusr:jpasswd@mysrv.wwmed.com/12345.rel releases test5.rel
bstnA# show releases
bstnA# ...
username@ is a valid username at the remote host,
server identifies the SCP server with an IP address or FQDN (for example, 172.16.100.18 or deb1.mynet.com), and
file is the release-file name. Lead with a slash (scp-server:/file) if the file path is absolute. Without the slash, the path is presumed to start in the home directory for username.
dest-file is the name you choose for the downloaded copy of the release file.
accept-host-key (optional) tells the CLI to accept an unknown host key if offered by the SCP server. The host key authenticates the server; if the key is unknown, it is possible that an attacker has taken the servers hostname and/or IP address. Note that any SCP server is unknown if the ARX has not had an SCP exchange with it since the ARXs last reboot.
The CLI prompts for the usernames password. Enter a password that is valid at the remote site. For example, the following command exits from gbl mode to priv-exec mode, then downloads a release file through SCP:
bstnA(gbl)# exit
bstnA# copy scp://juser@rh1.wwmed.com:/var/rels/12345.rel releases test.rel
Password: jpasswd
bstnA# ...
Use the show releases command on a release file to view the release version and build date for the file:
show releases file
where file (1-1024 characters) is the release-file name.
bstnA# show releases test5.rel
bstnA# ...
It is possible for the release file to be incomplete after it downloads. You can verify the integrity of the file by comparing its current checksum, a file signature based on its contents, against the checksum it had when it was built. Use the verbose option in the show releases command to run a checksum test on the release file:
show releases file verbose
bstnA# show releases test5.rel verbose
bstnA# ...
If the checksum fails, retry the copy command and/or retry the download from the F5 web site.
The next step in upgrading software is to arm the switch with the new release file. From priv-exec mode, use the boot system command to arm the ARX:
boot system release-file
where release-file (1-1024 characters) identifies the desired release file.
Note: If you are downgrading to an earlier release, this command removes all of your configuration parameters. After the next reboot, all managed volumes will disappear from the configuration; to recover, you must restore the running-config and global-config files (saved earlier) to re-import all managed volumes. The CLI warns of this and prompts for confirmation; confirm that you have saved your config and enter yes to continue.
bstnA# boot system test5.rel
bstnA# show releases
bstnA# ...
The final step in upgrading software is to reboot the switch and activate the armed release file. From priv-exec mode, use the reload command to reboot the switch:
The CLI prompts for confirmation before rebooting; enter yes to proceed. For example:
bstnA# reload
Contact your Sales representative to get your base-registration key, which is required to activate the license for the first time. The key usually comes in an E-mail message. Then use automatic or manual license activation, as appropriate for your installation. For details on license activation, see Chapter 5, ARX Feature Licensing in the ARX® CLI Network-Management Guide.
Username: admin
Password: password
bstnA> enable
bstnA# ping license-server base-reg-key CRJGVQP-DYWST-ANKR-GBYYDMT
bstnA# license activate base-reg-key CRJGVQP-DYWST-ANKR-GBYYDMT
If the license activation fails and cannot be resolved, you must arm the ARX with the former release and use reload to go back to it (go back to Arming the Switch with the Release File).
Username: admin
Password: password
SWITCH> ...
This indicates that you need to restore the running-config and the global-config, saved off at the beginning of this process (recall Saving the Configuration). First, edit both configuration files to remove all commands that do not exist in the older release. Contact F5 Support if you need assistance.
Once the running-config and global-config files are edited for the downgrade release, use the copy command to copy the files to the ARX. Then use the run configs command to invoke each of them as a script. Run the running-config script first, followed by the global-config script. For example, the following commands replace the previously stored configs:
SWITCH> enable
SWITCH# copy ftp://juser:jpasswd@ftp.wwmed.com/net_config configs running-config
SWITCH# run configs running-config
bstnA# copy ftp://juser:jpasswd@ftp.wwmed.com/storage_config configs global-config
bstnA# run configs global-config
The new release is running when the switch reboots. Log back in and use show version to verify that the software upgrade was successful. For example:
Username: admin
Password: acopia
bstnA> show version
bstnA> ...
A software release may contain new firmware for the switchs hardware modules. The firmware is low-level software that controls the boot process and various FPGAs.
You can use the show firmware upgrade command to compare the running firmware with the firmware that is available on the new release:
where verbose (optional) expands the output with specific version numbers for each firmware component.
bstnA# show firmware upgrade
bstnA# ...
If the show firmware upgrade output indicates that a firmware upgrade is available for any of your slots, you can use the firmware upgrade all command to upgrade all slots at once.
bstnA# firmware upgrade all
| use show processors to confirm that the processors are all Up or (for network processors) in Standby state, |
| use show health to verify there are no active alarms, and |
prtlndB# copy running-config ftp://juser:jpasswd@ftp.wwmed.com/runConfPrtlndB
prtlndB# copy global-config ftp://juser:jpasswd@ftp.wwmed.com/gbl_config_prtlnd
prtlndB# ...
Refer back to Other Important Configuration Parameters for more details and examples.
Before you upgrade one of the switches, confirm that the chosen Active switch (the switch that you will not upgrade first) is connected to the quorum disk. The Active switch must be connected to the quorum disk when you upgrade its peer, or both switches reboot simultaneously. Use the show redundancy quorum-disk command to verify the connection to the quorum disk (see Showing the Quorum Disk, on page 7-22 of the ARX® CLI Network-Management Guide). Run this command at the Active switch, not the switch where you will do the upgrade first. Any Up status, even if the switch is not receiving heartbeats, is acceptable.
prtlndA# show redundancy quorum-disk
prtlndA# ...
From the backup switch, use the show redundancy command to confirm that the redundant pair is formed. Both peers and the quorum disk should all have a status of Up. For example,
prtlndB# show redundancy
prtlndB# ...
Otherwise, use the show health command to check for any alarm conditions:
prtlndB# show health
prtlndB# ...
Use the show cores command to confirm that no software processes failed and created a core-memory file for diagnosis:
prtlndB# show cores
prtlndB# ...
prtlndB# copy ftp://jusr:jpasswd@mysrv.wwmed.com/12345.rel releases new.rel
prtlndB# boot system new.rel
prtlndB# reload
Contact your Sales representative to get your base-registration key, which is required to activate the license for the first time. The key usually comes in an E-mail message. Then use automatic or manual license activation, as appropriate for your installation. For details on license activation, see Chapter 5, ARX Feature Licensing in the ARX® CLI Network-Management Guide.
Username: admin
Password: password
prtlndB# ping license-server base-reg-key CYBJAAZ-DYWST-ANKR-GBYYDMT
prtlndB# license activate base-reg-key CYBJAAZ-DYWST-ANKR-GBYYDMT
If the license activation fails and cannot be resolved, you must reload and boot the former release of software (see Upgrading the Backup Switch).
If this platform supports firmware upgrades, use the show firmware upgrade command to compare the running firmware with the firmware that is available on the new release. For example, the following chassis has new firmware available for its only slot:
prtlndB# show firmware upgrade
prtlndB# ...
If the show firmware upgrade output indicates that a firmware upgrade is available for any of your slots, you can use the firmware upgrade all command to upgrade all slots at once.
prtlndB# firmware upgrade all
| use show processors to confirm that the processors are all Up or (for network processors) in Standby state, |
| use show health to verify there are no active alarms, and |
| use show redundancy to ensure that redundancy is up and running. |
Repeat the health checks at the active switch, where the previous release is still running. Use the show redundancy command to confirm that the redundant pair is formed, and use show health to verify that there are no active alarms. Both peers and the quorum disk should all have a status of Up, and there should be no active alarms.
The next step is to fail over and put the new software into active service. Reload the other switch, the switch currently running services on the old software. Use the priv-exec reload command. This forces failover to the switch running the new software. From the now-active switch (prtlndB in our examples), take the following steps to confirm that the failover succeeded:
| Repeat show cifs-service all and/or show nfs-service all until all of your configured services have a State of Online. |
| Repeat show redundancy until the now-backup peer has re-joined the pair in the Backup role. Confirm that the both peers and the quorum disk all have a Status of Up. |
Upgrade the peer switch (now in the Backup role) to the new release. Use the same steps that you used above, from Saving the Configuration to Sanity Check. Then both switches are running the new software, and all new global-configuration options are now available.
You must invoke one additional failover after both peers have been upgraded. The final failover, with both peers at the new software version, makes it possible to perform the final upgrade of internal databases and enable any new features that are database-dependent. To return the originally-active peer (prtlndA in our examples) to its active status, use reload on the currently-active peer (prtlndB). This causes a failover.
To return to the old release, you can revert the now-Active switch to the old software. First use reload to fail back to the peer switch, which is still running the previous release. When this switch boots (now in the backup role), use boot system to select the old release, then use reload to install it. Downgrading deletes all configuration parameters, both the running-config and the global-config; a CLI prompt asks for confirmation before doing this. Recall that you saved the global-config and running-config files earlier, in Saving the Configuration.
prtlndB# reload
prtlndB# boot system oldRelease.rel
prtlndB# reload
Username: admin
Password: password
SWITCH> ...
The final step in reverting to the old software is to restore the old running-config parameters, saved off at the beginning of this process (recall Saving the Configuration). The global-config is still running on the active peer (prtlndA in the examples), so that does not need to be restored. Use the copy command to copy the file to the ARX. Then use the run configs running-config command to invoke it as a script.
SWITCH> enable
SWITCH# copy ftp://juser:jpasswd@ftp.wwmed.com/runConfPrtlndB configs running-config
SWITCH# run configs running-config
prtlndB# copy running-config ftp://juser:jpasswd@ftp.wwmed.com/runConfPrtlndB
prtlndB# copy global-config ftp://juser:jpasswd@ftp.wwmed.com/gbl_config_prtlnd
prtlndB# ...
prtlndA# copy running-config ftp://juser:jpasswd@ftp.wwmed.com/runA
prtlndA# ...
These parameters are shared between the peers, like the global-config. Refer back to Other Important Configuration Parameters for more details and examples.
The config files may have commands that are unknown in the downgrade release. Edit them all to remove any such commands. You can use the CLI Reference manual from the downgrade release to check for the existence and syntax of any given command in the release.
Additionally, remove the cfg-redundancy enable command from both running-config files. When you run the config files as scripts later, you will want to control the timing for re-enabling redundancy. For example, this shows the end of the running-config file for the prtlndB switch. Comment out or remove the enable command, shown here in bold text:
The next step is to downgrade the Backup switch. This is the same as the upgrade process described earlier, except that you choose a release with a lower release number. Typically, the older release is already on the ARX. Use the boot system command to arm the system with the older release, and then reload with it. The boot system command causes the next reload to erase the entire configuration, so the CLI prompts you for confirmation first; this is necessary for the downgrade, so enter yes to proceed.
prtlndB# boot system old.rel
prtlndB# reload
Username: admin
Password: password
SWITCH> ...
This indicates that you need to restore the running-config, saved off and edited at the beginning of this process (recall Saving the Configuration).
Once the running-config file is edited for the downgrade release (recall Editing the Config Files), use the copy command to copy the file to the ARX. The CLI prompts for confirmation before overwriting the current running-config file; enter yes to proceed. Then use the run configs running-config command to invoke it as a script.
SWITCH> enable
SWITCH# copy ftp://juser:jpasswd@ftp.wwmed.com/runConfPrtlndB configs running-config
SWITCH# run configs running-config
If this platform supports firmware downgrades, use the show firmware upgrade command to compare the running firmware with the firmware that is available on the downgrade release. For example, the following chassis has new firmware available for its only slot:
prtlndB# show firmware upgrade
prtlndB# ...
If the show firmware upgrade output indicates that a firmware change is available for any of your slots, you can use the firmware upgrade all command to change all slots at once.
prtlndB# firmware upgrade all
| use show processors to confirm that the processors are all Up or (for network processors) in Standby state, and |
| use show health to verify there are no active alarms other than "licenseNotFoundRaise." The license is supposed to be disabled at the moment because the peer ARX is still the active peer (and possibly in service), so it has registered all the proxy-IP addresses for this current ARX through ARP. Enabling the license would cause the current switch to gratuitously ARP all of its proxy IPs, creating contention for those addresses between the two ARX devices. |
You must manually erase all configuration parameters from the active peer before you downgrade it. You cannot use the boot system command on an active peer, and the active peer cannot fail over if the redundant peer is running a lower release, so you must erase the devices configuration before you perform the downgrade. Use the delete startup-config command, followed by a reload, to erase all of the configuration from the active peer. Recall that you already saved the configuration earlier, and edited it for use at the older release level.
The CLI prompts for confirmation at each command, to warn you of the configuration outage and the loss of service; enter yes for both commands.
prtlndA# delete startup-config
prtlndA# reload
Username: admin
Password: password
SWITCH> enable
SWITCH# boot system old.rel
SWITCH# reload
When the downgraded switch returns from its reboot, restore its running-config. Use the running-config that you saved off and edited at the beginning of this process (recall Saving the Configuration).
Use the copy command to copy the edited running-config file to the ARX. The CLI prompts for confirmation before overwriting the current running-config file; enter yes to proceed. Then use the run configs running-config command to invoke it as a script.
Username: admin
Password: password
SWITCH> enable
SWITCH# copy ftp://juser:jpasswd@ftp.wwmed.com/runA configs running-config
SWITCH# run configs running-config
The downgrade erases all traces of a former license activation along with the configuration database. If the license was activated previously, you can use the license activate command (without a base-registration key) to re-activate it after the downgrade. (For details on license activation, see Chapter 5, ARX Feature Licensing in the ARX® CLI Network-Management Guide.)
prtlndA# license activate
If this platform supports firmware downgrades, use the show firmware upgrade command to compare the running firmware with the firmware that is available on the downgrade release. If a change is necessary, use the firmware upgrade all command. For example, the following chassis has all of its firmware up-to-date:
prtlndA# show firmware upgrade
prtlndA# ...
The next step in reverting to the old software is to restore the old global-config parameters, saved off and edited at the beginning of this process (recall Saving the Configuration). Use the copy command to copy the global-config file to the ARX. Then use the run configs global-config command to invoke it as a script.
prtlndA# copy ftp://juser:jpasswd@ftp.wwmed.com/gbl_config_prtlnd configs global-config
prtlndA# run configs global-config
| use show processors to confirm that the processors are all Up or (for network processors) in Standby state, |
| use show health to verify there are no active alarms, and |
| use show redundancy to ensure that redundancy is not currently running. |
The originally-backup peer (prtlndB in the examples) still has a disabled license. It needs its license enabled before it can rejoin the redundant pair. If the license was ever activated previously, you can use the license activate command (without a base-registration key) to re-activate it after the downgrade. For details on license activation, see Chapter 5, ARX Feature Licensing in the ARX® CLI Network-Management Guide.
prtlndB# license activate
Log into each of them, enter cfg-redundancy mode, and use the enable command in that mode. For example:
prtlndA# config
prtlndA(cfg)# redundancy
prtlndA(cfg-redundancy)# enable
prtlndB# config
prtlndB(cfg)# redundancy
prtlndB(cfg-redundancy)# enable
prtlndB(cfg-redundancy)# show redundancy
