Removing AAM/WAM for a successful upgrade
If you are wanting to upgrade to version 16 or 17 of BIG-IP, one thing that can cause your config not to load, is any element of AAM/WAM/WOM. As I discovered via a customer of mine, even removing all AAM/WAM items from traffic objects is not enough. While I know how to identify things in the conf files and can see them in iHealth, that doesn't help Admins in the field assess if this is an issue for them, and if it is, how to document what needs to be changed for the necessary approvals. With some help, I wrote this knowledge article to meet these needs as well as provide a way to quickly make the changes - https://my.f5.com/manage/s/article/K000149084 I am sharing this in the forum to not only advertise this, but explain some of the commands and help the community understand how they might be used for other tasks. From spending time running a few BIG-IPs myself in a prior life and working with hundreds of customers, I knew that my solution needed to address partitions and even iApps. My coworker Fernando C provided me the syntax to crawl every partition and I quickly found ways to morph that into this document. Lets take a look at the syntax that can read the lan TCP profiles in the Common partition and then see the changes needed to read all partitions. In order to filter the results a bit better we run these from bash so that we have access to a number of tools like grep, awk, sed, etc. # Return all virtual server names in Common that use a TCP Profile from wam or wom (aka AAM) # grep to find the profile prefixes and then piping that to AWK to grab the third word in the output of each line tmsh list ltm virtual one-line | grep -E "(profiles.*(w(a|o)m-tcp-lan*))" | awk '{print $3}' This simply returns the virtual server name without the partition name. Now to read all partitions, the tmsh portion of the command has to change. Specifically, we pass the -c option to tmsh to tell it to run multiple commands. When you enter tmsh, by default you are in the Common partition, so we have to back out to the root. Because we are in the root directory, we need to add the recursive option to read all subfolders which in this case are the partitions. #Read all partitions and filter for virtual servers that use the wam/wom TCP profiles on the lan or server side tmsh -c 'cd /; list ltm virtual recursive one-line' | grep -E "(profiles.*(w(a|o)m-tcp-lan*))" | awk '{print $3}' Now the output is the partition name and virtual server name, or if iApps are involved, the appservice name as well. You can take the output from the first command and pass it to xarg to use your output as a variable in a command to execute. CAUTION, the following command will attempt to make changes to your config. #Read all partitions and filter for virtual servers that use the wam/wom TCP profiles on the lan or server side then insert new profiles and delete the original profile #This will cause an error tmsh -c 'cd /; list ltm virtual recursive one-line' | grep -E "(profiles.*(w(a|o)m-tcp-lan*))" | awk '{print $3}' | xargs -t -I vsName tmsh modify ltm virtual vsName profiles add { f5-tcp-lan { context serverside } } profiles delete { wam-tcp-lan-optimized } If you run this command, it will error out, because without the proper syntax, tmsh assumes you are referencing objects in the /Common partition and as a result it will help you by implicitly adding that to the beginning of every object in your xarg command. I added the -t option to xarg to output the command that it will execute. To correct the syntax error, in the awk command, you add a forward slash and now tmsh will treat your command as if you have explicitly declared the partition name for every object. Caution - This will make changes to your configuration, very fast... #Read all partitions and filter for virtual servers that use the wam/wom TCP profiles on the lan or server side then insert new profiles and delete the original profile #CAUTION - This will make changes to your system. tmsh -c 'cd /; list ltm virtual recursive one-line' | grep -E "(profiles.*(w(a|o)m-tcp-lan*))" | awk '{print "/" $3}' | xargs -t -I vsName tmsh modify ltm virtual vsName profiles add { f5-tcp-lan { context serverside } } profiles delete { wam-tcp-lan-optimized } When I first hit the wall with xarg beyond the /Common partition, I did not realize what the fix was. However my OCD wanted to see a slash in front of the partition name and I had modified the awk to add it, but had given up on the xarg to modify things outside of /Common. It wasn't until I went to show the error to a peer, Chad T., that I discovered I stumbled upon the proper syntax, and realized I could simplify the instructions quite a bit. Where I would love some help from the community would be on ways to crawl the iApps to quickly disable Strict Updates. The xarg commands to modify/delete objects associated with an iApp will fail if the default setting of "Strict Updates" is enabled. Hope this helps, Carl
rSeries and tenant upgrades
I manage four r5900 appliances, hosting 16 tenants. The appliances are running F5OS-A 1.5.0; the tenants all run BIG-IP 15.1.10.2. We all know, of course, that the most recent QSN was released today. Normally, I'd upgrade everything to the latest version. However, where F5OS-A 1.7.0 is concerned, there is a "Known Issue" that raises a big red flag. In the release notes, 1380705-1 : BIG-IP tenant is stuck during boot up after doing tenant upgrade from 15.1.x to 17.1.x The issue description says this will not happen with every tenant. But it just has to happen once to ruin a day, right? In the past, I have always upgraded the appliance OS before upgrading the tenants. That just seemed to make sense. Given this issue, though, I am considering upgrading all of the tenants to BIG-IP 17.1.1.3 first, then upgrading the appliances to F5OS-A 1.7.0. Does anybody know of any pitfalls to this approach?
11.6.0 HF5 Error 010716bc:3: anybody ?
I recently upgraded one of my AWS F5, from 11.6.0.4 to 11.6.0.5 I use some complex iRules to manage my sites, including recently added procs Now every change I try on the virtual server using the irules, I always get the error: 010716bc:3: HTTP::header command in a proc in rule (/Common/GTM) under HTTP_REQUEST event at virtual server (/Common/STAGE_MYSERVER_80) does not satisfy cmd/event/profile requirement. I know I've not provided much details, but I don't want a validation of my irule: just want to confirm if a change breaking existing code can be expected in a HotFix? Or there simply was a problem with my upgrade. Does anybody know if the irule runtime environment has changed in HotFix5 ??? Where can I find info about that error code? Thank you Angelo.
