Big-IP 10.x can be upgraded to any version of 11.x given your hardware supports the new version. Big-IP 11.x can be upgraded to any version of 12.x given your hardware supports the new version. You cannot upgrade directly from 10.x to 12.x. For more information, refer to:
The Latest Maintenance Release of each Long Term Stability Release are the best choices for security and sustainability. For more information, refer to K5903: BIG-IP software support policy. The lowest-numbered version in the Latest Maintenance Release column is generally considered the most stable while the highest number contains the newest features and security fixes.
Misconceptions and Perils
"It's a firmware upgrade"
Big-IP runs on either a physical or virtual disk with CentOS Linux installed as the base operating system. While there are also various internal firmware upgrades which take place between software versions, a Big-IP upgrade is at heart an operating system and tmos (Traffic Management Operating System) upgrade.
"It will take two minutes"
The fastest Big-IP upgrades will be around 15 minutes and up to an hour or more depending on the speed of the disk, CPU and size of the Big-IP configuration being upgraded. Be patient. Forcing a reboot during the installation process may lengthen recovery time and take more effort.
"I can install to the current, running software volume"
Engineers don’t often say this out loud but I have inferred some thinking this. Big-IP forces you to install to a software volume which is not currently in-use so that you are able to boot the old volume should there be a problem with the new one.
"No need to reactivate the license"
This is the #1 mistake made in regards to Big-IP upgrades. Assume a license reactivation IS necessary until you can explain exactly why it isn’t.
"Didn't run tmsh load sys config verify before the upgrade"
This is less common an issue but can be nasty if not caught early. Essentially, if the command does not succeed, not only should you expect upgrades problems but also config sync problems and possibly issues even reverting to the old software volume. Make sure this command completes without error before upgrading.
"No need for UCS backups"
What if you reboot your hardware and it never comes back up? Having a UCS archive will saves a lot of time should something go wrong and you need to restore a Big-IP quickly.
"Let's upgrade and reboot both Big-IPs at the same time to save time"
Again, you need to be sure one Big-IP is operational before risking losing both units in a high availability configuration. Just because a piece of electronics is running right now doesn’t mean it necessarily turn back on.
"I have serial console port access but no need to check that's it's working prior to the upgrade"
If you have easy access to a serial port connection to your Big-IPs, use it. A big advantage here is that you can still watch installation progress while the network ports are down.
Back out Procedure
If a Big-IP fails to upgrade and further troubleshooting cannot be performed due to time constraints, follow the below steps before reverting to the previous Big-IP version.
Run the tmsh load /sys config command to determine what may be causing a configuration load error.
Gather a qkview.
Once the above data is gathered, you can boot the previous Big-IP version by using the Configuration Utility (System/Software Management/Boot Locations/ and click the Activate button which will reboot the system. You can also use K5658: Overview of the switchboot utility to change to another software volume via the command line.
Note: The above back out procedure does not apply if you have reset the Big-IP to default settings.
Alternatively, you can load your previously saved UCS archive. For more information, refer to K4423: Overview of UCS archives.
According to K13845, you can upgrade from 10.1.x or 10.2.x directly to 12.x unless you have GTM provisioned (see K17158). You can't upgrade directly from 10.0.x to 12.x.
I would recommend going to version 10.2.4 before upgrading into v11/v12 particularly if you have a 6900/8900/11050 as there is an issue with swap file creation if skipped. Can check this via "cat /proc/swaps".
