Forum Discussion
Muffe_183891
Nimbostratus
NimbostratusUpgrade F5 BIG-IP from 11.5 to 11.6
Hi,
We got a security notice from AWS that our current F5 version 11.5 has a known security risk and they recommend us to update the version.
So we did and created a new instance and uploaded the config but it didn't work so good. This is from the output:
Jan 22 10:19:57 ip-10-26-0-202 emerg mcpd[4619]: 0107070e:0: Software version not covered by service agreement. Reactivate license before continuing. Jan 22 10:19:57 ip-10-26-0-202 emerg mcpd[4619]: 01070608:0: License is not operational (expired or digital signature does not match contents). Jan 22 10:20:02 ip-10-26-0-202 emerg load_config_files: "/usr/bin/tmsh -n -g load sys config partitions all" - failed. -- 01070356:3: SNAT feature not licensed. Unexpected Error: Loading configuration process failed. Jan 22 10:20:21 ip-10-26-0-164 emerg load_config_files: "/usr/bin/tmsh -n -g load sys config partitions all" - failed. -- Error: failed to reset strict operations; disconnecting from mcpd. Will reconnect on next command. The connection to mcpd has been lost, try again. Jan 22 10:20:21 ip-10-26-0-164 emerg logger: Re-starting lind Jan 22 10:20:22 ip-10-26-0-164 emerg logger: Re-starting mcpd Jan 22 10:20:42 ip-10-26-0-164 emerg load_config_files: "/usr/bin/tmsh -n -g load sys config partitions all" - failed. -- 01070356:3: SNAT feature not licensed. Unexpected Error: Loading configuration process failed.
What do I need to do to get the license working again?
LyonsG_85618Cirrostratus
Hi
Can you still login? If you can you should be able to go through the re-licencing option via GUI? (if your F5 doesnt have access to internmet remember to tick the option to licence manually!)
Muffe_183891Hi,
Yes I can login via GUI and I get the licence option. However this is an AMI instance which doesn't have a license key. Not sure how it works but it is a hourly billing license via Amazon AWS.
- LyonsG_85618Apologies - never noticed the AWS reference. I guess you need to get in touch with F5 support then? (or AWS?)
- Muffe_183891
I have talked to AWS but they point to F5. I don't have a support contract with F5 so I thought the forum would be the best place.
See if it exists another good soul that could help me.
Hello Muffe,
To help investigate, what are the AMI IDs from the aws-marketplace for the BIG-IPs you are using?
Which type of configuration file did you use when restoring the 11.5.x configuration on the new 11.6.0 instance? Was it a .ucs or .scf backup? I suspect that you may have used an .ucs file.
Using similar types of Hourly Billing instances. Try restoring the configuration using the .scf method.
Going from 11.5.x to 11.6.0 there are some changes in authentication.
Here is a long version.
As an example, starting from:
F5 Networks BIG-IP VE 11.5.1.0.4.110 - GOOD 25Mbps - Hourly Billing - built -fa8a82ce-7679-467d-9880-16497f3ac022-ami-8b4b52e2.2 (ami-5d5c4434)
Upgrading to:
F5 Networks Hourly Hotfix-BIGIP-11.6.0.1.0.403-HF1 - Good 25Mbps - built on -fa8a82ce-7679-467d-9880-16497f3ac022-ami-7ab63012.2 (ami-6ad05d02)
On the 11.5.x instance, configure the system and create the .scf backup using tmsh.
root@(ip-10-0-0-XX)(cfg-sync Standalone)(Active)(/Common)(tmos) save sys config file 11_5_1_ConfiguredBase
This saves the configuration file in /var/local/scf/
Launch a fresh Hourly Billing instance of 11.6.0 and copy the 11.5.1 configuration files to /var/local/scf/ on the new system.
Using tmsh, load the configuration
admin@(ip-10-0-0-XX)(cfg-sync Standalone)(Active)(/Common)(tmos) load sys config file 11_5_1_ConfiguredBase
** Before doing anything else you need to enable the shell for the admin account.
admin@(ip-10-0-0-XX)(cfg-sync Standalone)(Active)(/Common)(tmos) modify auth user admin shell tmsh
admin@(ip-10-0-0-XX)(cfg-sync Standalone)(Active)(/Common)(tmos) save sys config
With 11.6.0, the admin account can connect using ssh and when they do, they will be in the tmsh shell. To get the bash shell execute:
admin@(ip-10-0-0-XXX)(cfg-sync Standalone)(Active)(/Common)(tmos) run util bash
[admin@ip-10-0-0-XXX:Active:Standalone] ~
Hope this helps.
This is probably too late for Muffe but for those perusing later, the proper way to upgrade a BIG-IP in AWS is:
Via GUI:
https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ve-setup-amazon-ec2-11-6-0.pdf?sr=43766835 or whatever manual reflects your version.
Ex. Simply type "2" for new boot volume name (= will create "HD1.2")
Via CLI:
1) Upload images (hotfixes and required base isos/images) to /shared/images (via SCP) 2) Create New Boot Volume and Install ISOs onto it
ex. Before
root@(ip-10-0-0-5)(cfg-sync Disconnected)(Active)(/Common)(tmos) show sys software
Sys::Software Status
Volume Product Version Build Active Status
HD1.1 BIG-IP 11.5.1 3.0.131 yes complete
Install cmd: root@(ip-10-0-0-5)(cfg-sync Disconnected)(Active)(/Common)(tmos) install sys software image BIGIP-11.6.0.0.0.401.iso create-volume volume HD1.2 reboot
"reboot" optional if you want to reboot immediately after install (vs. staged for later). or if want to boot hotfix all in one command (lays down base image + hotfix simultaneously)
"install sys software hotfix Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso create-volume volume HD1.2 reboot"
See Progress:
root@(ip-10-0-0-5)(cfg-sync Disconnected)(Active)(/Common)(tmos) show sys software
Sys::Software Status
Volume Product Version Build Active Status
HD1.1 BIG-IP 11.5.1 3.0.131 yes complete HD1.2 BIG-IP 11.6.0 0.0.401 no installing 6.000 pct
Will reboot immediately after this:
root@(ip-10-0-0-5)(cfg-sync Disconnected)(Active)(/Common)(tmos) show sys software
Sys::Software Status
Volume Product Version Build Active Status
HD1.1 BIG-IP 11.5.1 3.0.131 yes complete HD1.2 BIG-IP 11.6.0 0.0.401 no complete
After reboot:
[root@ip-10-0-0-5:Standby:Standalone] config tmsh show sys software
Sys::Software Status
Volume Product Version Build Active Status
HD1.1 BIG-IP 11.5.1 3.0.131 no complete HD1.2 BIG-IP 11.6.0 0.0.401 yes complete == Active Volume now
Note: default user changed from root to admin in 11.6.0 so make sure you updated your admin password from the default.
This should work for both BYOL and Subscription license versions.
If you created a new AMI, that gets trickier so would avoid if at all possible. The new subscription image will be licensed already. When you migrate the config (UCS) you have to use the "no-license" option to avoid overriding the existing working license.
root@(ip-10-0-0-5)(cfg-sync Changes Pending)(Active)(/Common)(tmos) load sys ucs config.ucs Options: no-license no-platform-check passphrase reset-trust
Besides all the usual procedures of changing the hostname (so UCS loads), probably changing the network settings (to match the new IPs AWS assigned, etc.). At that point, so much has changed or there's a lot of remapping on the AWS end, it might be worth the SCF (Single Config File) and trying to work with that (cutting out parts you need).
Obviously configs are more transient/dynamic in cloud world and we are working on more elegant ways to address this but long story short, would try to preserve the existing AMI if possible.
danielpenna_196Hi Alex, is there any support document/solution article that reflects this process you have written down ? The only official article I have ( apart from your linked one ) is https://support.f5.com/kb/en-us/solutions/public/15000/100/sol15161.html which basically tells you to replace the AMI.- Hi Daniel, Sorry. To clarify, the procedure I posted was really just to clarify "upgrading" as the title says upgrade from one "software" version to another (for which you should really do an in place upgrade). The official manual I referred to outlined the procedure from the GUI and IMHO didn't really give the clearest picture of what was involved (what to type, creating a second volume, etc.) and could be easily missed. The solution you reference still stands is more focused on "replacing" or "migrating" should you need to (image is corrupt, need to change image size, m3large to m3xlarge). The physical device analogue being more an RMA or "platform" upgrade. With the disposable chaos monkey nature of cloud, we were seeing the two types of "upgrades" (software vs. device) getting conflated and wanted to make sure everyone remembered the good ol "software" upgrade (i.e. you don't have to throw every image away for every change :-). We see the type of config mobility referenced in solution 15161 is obviously getting more and more critical so we're working on facilitating that process as well. Thanks - Alex
- danielpenna_196Thanks Alex, should have given you more context on my query. I am in the process of upgrading our AWS 11.6.0 HF1 boxes to HF3 over the next few days and was looking for an official solution article. I referenced the sol 15161 as the only official documentation I found around upgrades/updates in AWS land :).
- Alex__Applebaum
Employee
This is probably too late for Muffe but for those perusing later, the proper way to upgrade a BIG-IP in AWS is:
Via GUI:
https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ve-setup-amazon-ec2-11-6-0.pdf?sr=43766835 or whatever manual reflects your version.
Ex. Simply type "2" for new boot volume name (= will create "HD1.2")
Via CLI:
1) Upload images (hotfixes and required base isos/images) to /shared/images (via SCP) 2) Create New Boot Volume and Install ISOs onto it
ex. Before
root@(ip-10-0-0-5)(cfg-sync Disconnected)(Active)(/Common)(tmos) show sys software
Sys::Software Status
Volume Product Version Build Active Status
HD1.1 BIG-IP 11.5.1 3.0.131 yes complete
Install cmd: root@(ip-10-0-0-5)(cfg-sync Disconnected)(Active)(/Common)(tmos) install sys software image BIGIP-11.6.0.0.0.401.iso create-volume volume HD1.2 reboot
"reboot" optional if you want to reboot immediately after install (vs. staged for later). or if want to boot hotfix all in one command (lays down base image + hotfix simultaneously)
"install sys software hotfix Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso create-volume volume HD1.2 reboot"
See Progress:
root@(ip-10-0-0-5)(cfg-sync Disconnected)(Active)(/Common)(tmos) show sys software
Sys::Software Status
Volume Product Version Build Active Status
HD1.1 BIG-IP 11.5.1 3.0.131 yes complete HD1.2 BIG-IP 11.6.0 0.0.401 no installing 6.000 pct
Will reboot immediately after this:
root@(ip-10-0-0-5)(cfg-sync Disconnected)(Active)(/Common)(tmos) show sys software
Sys::Software Status
Volume Product Version Build Active Status
HD1.1 BIG-IP 11.5.1 3.0.131 yes complete HD1.2 BIG-IP 11.6.0 0.0.401 no complete
After reboot:
[root@ip-10-0-0-5:Standby:Standalone] config tmsh show sys software
Sys::Software Status
Volume Product Version Build Active Status
HD1.1 BIG-IP 11.5.1 3.0.131 no complete HD1.2 BIG-IP 11.6.0 0.0.401 yes complete == Active Volume now
Note: default user changed from root to admin in 11.6.0 so make sure you updated your admin password from the default.
This should work for both BYOL and Subscription license versions.
If you created a new AMI, that gets trickier so would avoid if at all possible. The new subscription image will be licensed already. When you migrate the config (UCS) you have to use the "no-license" option to avoid overriding the existing working license.
root@(ip-10-0-0-5)(cfg-sync Changes Pending)(Active)(/Common)(tmos) load sys ucs config.ucs Options: no-license no-platform-check passphrase reset-trust
Besides all the usual procedures of changing the hostname (so UCS loads), probably changing the network settings (to match the new IPs AWS assigned, etc.). At that point, so much has changed or there's a lot of remapping on the AWS end, it might be worth the SCF (Single Config File) and trying to work with that (cutting out parts you need).
Obviously configs are more transient/dynamic in cloud world and we are working on more elegant ways to address this but long story short, would try to preserve the existing AMI if possible.
- danielpenna_196Hi Alex, is there any support document/solution article that reflects this process you have written down ? The only official article I have ( apart from your linked one ) is https://support.f5.com/kb/en-us/solutions/public/15000/100/sol15161.html which basically tells you to replace the AMI.
- Alex__ApplebaumHi Daniel, Sorry. To clarify, the procedure I posted was really just to clarify "upgrading" as the title says upgrade from one "software" version to another (for which you should really do an in place upgrade). The official manual I referred to outlined the procedure from the GUI and IMHO didn't really give the clearest picture of what was involved (what to type, creating a second volume, etc.) and could be easily missed. The solution you reference still stands is more focused on "replacing" or "migrating" should you need to (image is corrupt, need to change image size, m3large to m3xlarge). The physical device analogue being more an RMA or "platform" upgrade. With the disposable chaos monkey nature of cloud, we were seeing the two types of "upgrades" (software vs. device) getting conflated and wanted to make sure everyone remembered the good ol "software" upgrade (i.e. you don't have to throw every image away for every change :-). We see the type of config mobility referenced in solution 15161 is obviously getting more and more critical so we're working on facilitating that process as well. Thanks - Alex
- danielpenna_196Thanks Alex, should have given you more context on my query. I am in the process of upgrading our AWS 11.6.0 HF1 boxes to HF3 over the next few days and was looking for an official solution article. I referenced the sol 15161 as the only official documentation I found around upgrades/updates in AWS land :).
- Angelo_Turetta1
Been there, done that!
The 11.5.1 images on AWS cannot be upgraded to 16.0
The license on the 11.5.1 images is dated before 16.0 release, so it cannot be validated on the new release. You can only upgrade to a newer HotFix on the same product line.
By now the Marketplace AMI have been upgraded to 16.0, so you can deploy a new instance and import the 11.5.1 configuration. Painful, due to the additional IP management. Try moving the network interfaces to the new instance.
Angelo.
- danielpenna_196I also agree with Angelo, I tried 11.5.1 to 11.6.0 in AWS land and boned the AMI hard. Had to rollout a new 11.6.0 AMI and build from that. I afind the SCF configuration file backup/restore process more useful in AWS than a UCS restore ( due to the nature of IP changes etc ).
- Alex__Applebaum
Hmm, sorry. I had even quickly tested that exact upgrade (albeit with an internal BYOL license) and it worked fine.
root@(ip-10-0-0-5)(cfg-sync Changes Pending)(Active)(/Common)(tmos) show sys software --------------------------------------------------- Sys::Software Status Volume Product Version Build Active Status --------------------------------------------------- HD1.1 BIG-IP 11.5.1 3.0.131 no complete HD1.2 BIG-IP 11.6.0 0.0.401 yes completeLooks like a licensing issue vs. software workflow. Sorry, yeah, I know, migrating is is pretty painful. I'll forward this to our testing department to see what's going on the licensing side.
- danielpenna_196
Just ran through a AWS 11.6.0 HF1 ( Default AMI ) to HF4 successfully with Alex's process. Basic configuration applied to the F5 ( no virtual servers or ASM/AFM config yet applied ).
Great. Still working with Dev to figure out what exact issue is with supporting major version upgrades on hourly billing AMIs. Will keep this post updated.
- Sorry, thought I posted this before: Here is low down re: Upgrades: Type: "Software": (ex. in place upgrades like major versions from 11.5.x to 11.6.x using standard isos from downloads.f5.com via live install process mentioned above ) -> We apologize. This is officially supported but there were a few bugs that have been affecting this: related to a permissions issue when user changed from root to admin in 11.6 and another related to licensing. However, upgrading software is officially supported for both BYOL and Utility and should start work starting 11.5.1 HF8 + 11.6.0 HF4. "Increasing Instance Size:" (ex. m3.large to m3.xlarge) -> supported starting in 11.6 for BYOL, in next release major release for utility licenses. "License": (ex. Good to Best ) -> Only BYOL. (Utility is tied to AWS's "software" billing as well which we don't control).
