Applies To:

Show Versions Show Versions

Manual Chapter: Upgrading Software
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

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.
bstnA# copy running-config ftp://juser:jpasswd@ftp.wwmed.com/net_config
bstnA# copy global-config ftp://juser:jpasswd@ftp.wwmed.com/storage_config
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
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
Use the show cores command to confirm that no software processes failed and created a core-memory file for diagnosis:
bstnA# show cores
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.
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.
Use the show version command for a more-detailed view of the software versions:
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
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:
copy {cifs|nfs} namespace volume file-path releases dest-file
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.
bstnA# show cifs-service ac1.medarch.org
ARCHIVES /rcrds Online
bstnA# copy cifs medarcv /rcrds admin/12345.rel releases test5.rel
bstnA# show releases
copy ftp://[username:password@]ftp-site/file releases dest-file
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),
file is the chosen file name (lead with two slashes (ftp-site//file) if the file path is absolute),
releases is the destination directory on the ARX, and
dest-file is the name you choose for the local copy of the release file.
bstnA# copy ftp://jusr:jpasswd@mysrv.wwmed.com/12345.rel releases test5.rel
bstnA# show releases
copy scp://username@server:file releases dest-file [accept-host-key]
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# copy scp://juser@rh1.wwmed.com:/var/rels/12345.rel releases test.rel
Password: jpasswd
Use the show releases command on a release file to view the release version and build date for the file:
where file (1-1024 characters) is the release-file name.
bstnA# show releases test5.rel
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
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# reload
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
Password: password
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:
bstnA> show version
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
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
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
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
Otherwise, use the show health command to check for any alarm conditions:
prtlndB# show health
Use the show cores command to confirm that no software processes failed and created a core-memory file for diagnosis:
prtlndB# show cores
prtlndB# copy ftp://jusr:jpasswd@mysrv.wwmed.com/12345.rel releases new.rel
prtlndB# boot system new.rel
prtlndB# reload
Password: password
prtlndB# ping license-server base-reg-key CYBJAAZ-DYWST-ANKR-GBYYDMT
prtlndB# license activate base-reg-key CYBJAAZ-DYWST-ANKR-GBYYDMT
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
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.
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
Password: password
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
prtlndA# copy running-config ftp://juser:jpasswd@ftp.wwmed.com/runA
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:
enable
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
Password: password
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
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.
prtlndA# delete startup-config
prtlndA# reload
Password: password
SWITCH> enable
SWITCH# boot system old.rel
SWITCH# reload
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.
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
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
prtlndA# config
prtlndA(cfg)# redundancy
prtlndB# config
prtlndB(cfg)# redundancy
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)