F5 LTM Load Balancing Methods: Guide on How to Upgrade to 10.2.4

Unfortunately there are still a lot of F5 ® version 9.x installations out there, and there shouldn’t be. Not only is version 9 a long way out of support, it’s really not secure in this day and age. You’re also missing out on using iHealth® which can only be used from version 10.x onwards.

Please note that you may need AskF5™ login credentials to access some of the links within this article. If you do not have an AskF5 login you can request one here.

This guide assumes an upgrade to version 10.2.4 unless otherwise stated, although the same process applies to earlier 10.x versions. Note that 10.0.x releases are no longer supported. 10.2.4 is the recommended version for this branch and is supported to 31st December 2016 (see AskF5 SOL5903).

Prerequisites:
Before considering upgrading, ensure your hardware platform will support 10.2.4 code. The following platforms support it, as confirmed by AskF5 SOL9412:

You can only upgrade directly to 10.2.4 code from 9.3.x or 9.4.x releases.  If you are running an earlier 9.x release, you must upgrade to 9.3.x or 9.4.x before continuing.

Before you begin

Assuming you meet the prerequisite requirements, consider the following:

• YOU MUST re-activate the unit license before upgrading.  See AskF5 SOL7727 for reasoning.
• Backup EVERYTHING: /config/bigip.conf, bigip_base.conf, bigip.license, bigip_sys.conf (if it exists), wideip.conf (if it exists), take an SCF* (recommended, but only backs up LTM configuration), take a UCS (note that UCS also saves admin/root passwords and the license, so take this after license reactivation). Save these off box.  Also save the UCS file to /shared/ (you might need to create this directory) and to /var/local/ucs.  An extra 10 minutes spent here can save agony later on! If you are running ASM, also take a backup of the policy.

*to take an SCF, use the command:

# bigpipe export <filename.scf>

for example:

# bigpipe export mybackup.scf

• You should still read the release notes for the version you are installing.
• If you have a HA pair, you will, of course, be working on your standby unit.
• It is recommended to disconnect any unnecessary cables from a unit whilst upgrading (only leave connected the cables you need, such as the management cable). This will prevent any issues with the unit attempting to process traffic whilst upgrading.

Let’s upgrade

1)    Download the 10.2.4 ISO and copy* to /shared/images (create this folder if it does not already exist).
*SCP is the recommended method to copy files to/from the BigIP system. For a Windows client, check out WinSCP 

2)    Install the image2disk utility:

# im /shared/images/<filename.iso>

for example:

# im /shared/images/BIGIP-10.2.4.577.0.iso

3)    Begin the install. The full command syntax is

# image2disk --instslot=HD<slot_number> --format=<format_style> <downloaded_filename.iso>

BUT WAIT! Observe the following options first:

• Assuming you only want version 10.x and above from now on (highly recommended!), we need to format for volumes, so use:

# image2disk --instslot=<slot_number> --format=volumes /shared/images/>filename.iso>

• Assuming we wish to run version 10 and version 9 (not recommended, version 9.x is not supported), use:

# image2disk --instslot=<slot_number> --format=partitions /shared/images/>filename.iso>

Note that since we repartition, we will need to reinstall version 9 to a free partition after the version 10 installation completes.

• To preserve your existing configuration, use

# image2disk --instslot=<slot_number> --nomoveconfig--format=volumes /shared/images/<filename.iso>

DO NOT use the ‘–nomoveconfig’ flag if you are running ASM. Use a backup UCS instead. Using ‘–nomoveconfig’ means: “The configuration of the target boot location (if any is present) is re-installed on the target boot location after re-imaging is complete.”

The ‘slot_number’ variable will be HD1.1 or HD1.2 for example (the inactive partition, NOT the one you are currently running in*)
* If you are not sure which partition you are currently running on, use 

# switchboot -l

• If installing 10.2.x the flag “–instslot=<slot_number>” is NOT permitted so should be absent from the command to install software.  Reasoning: 10.2.x will always install to HD1.1 after the disk is formatted.

4)    The unit should reboot and install the new software.

5)    Once finished, you may need to do

# switchboot

and select the newly upgraded partition, then

# full_box_reboot

This depends on the specific upgrade version so may not be applicable. Install hotfixes at this point if necessary. It’s always recommended to be running the latest available hotfix.

6)    Wait for the filesystem to build and the installation to finish. This first boot after upgrade can take a while!

7)    Once the unit is up and running, load on any necessary config files.  These can either be a UCS (User Configuration Set, aka ‘Archive’) uploaded via System > Archives, or can be individual bigip.conf, bigip_base.conf, bigip.license (etc) files, which should be uploaded to the /config directory using SCP.  If you upload the individual configuration files, you’ll need to reboot again.  Check the configuration is present and correct via the GUI.  Cable the unit back up and you should be good to go.  If you are running a HA pair, you should failover during a change window and check the newly upgraded unit processes traffic correctly.  Assuming it does, repeat the upgrade process on your second unit.

8)    Beginning with version 10.0.0 of the software, a redundant system configuration must contain failover peer management addresses for each unit. If you roll forward a redundant system configuration from 9.3.x or 9.4.x, the units start up correctly, but the system logs a message every ten minutes reminding you to configure the peer management addresses. To configure the failover peer management addresses, navigate to System > High Availability > Network Failover, then specify the management IP address of the peer unit in the Peer Management Address field. Then do the same on the other unit in the configuration. Once you specify both IP addresses, the system should operate as expected. For more information, see AskF5 SOL9947.

You’re all done!

Chris Spillane is a Senior Security Analyst at NTT Com Security. He has been working with F5 Load Balancers for more than seven years. If you want to contribute as well, click here.

Find more tip on how to manage your F5 load balancers with indeni.