We procured the rSeries some time ago, and I built it using the UCS files from the vCMP guests. However, I was unable to make it live on the network. During this time, several changes have been made to the vCMP guests. I am now planning to bring the rSeries into production and decommission the vCMP appliances, but I am not sure what changes have been made on the vCMP guests since the initial build. Is there a way to identify those changes and apply them to the rSeries appliances? I would prefer not to rebuild the rSeries appliances from scratch.
One way to do it would be to compare the bigip.conf files of the old and new instances. I believe that file’s found in the /config directory, and you can use a utility like Filezilla to retrieve it. A comparison utility like ExamDiff can then be used to show the differences between the two config files. You may need to rename the file, replacing .conf with .txt, if ExamDiff doesn’t like it.
If you no longer have access to the old system, it’s possible to extract the bigip.conf file from a ucs backup. Instructions for doing that can be found online (I’ve done it couple of times).
During discussion with my team I found there were multiple changes done during this period including SSL certificate renewal. Now I am thinking to use the UCS and rebuild the tenant.
The old appliances are running on version 14.1.2.8 and new one is running on 17.1.3, do you think I will be able to copy the UCS?
Let’s make sure I understand the situation correctly.
A UCS from a v14 vCMP guest was used to provision an rSeries appliance. The rSeries then sat offline for some time, while additional changes were made to the vCMP guest, including SSL certificate renewals. The rSeries is currently running v17, while the vCMP guest remains on v14.
A couple of questions:
1. What BIG-IP version was the rSeries running when the original UCS was loaded?
2. What’s the highest BIG-IP version supported for upgrading the vCMP guest? Is it limited to v15, or can it be upgraded further?
Note: A UCS should generally be restored on the same BIG-IP version that created it, although an exact version match is not always required.
The sticky point is the version gap between the systems. The source vCMP guest config is on v14, while the target rSeries is running v17. Before loading a current UCS from the vCMP guest, I would first determine the highest version the vCMP guest can be upgraded to. Ideally, the source configuration should be brought as close as possible to the target version before migration to minimize config conversion issues.
I’ve heard of some customers encountering issues during upgrades from v15 to v17, although we didn’t have any problems. However, we’re only licensed for LTM, so your experience may differ depending on the modules in use.
One other item to consider is the master key. If the UCS contains encrypted objects (for example, SSL private keys, passwords, or other encrypted secrets), the target system may need to have its master key changed to match the source system. I’ve run into that a couple of times and have even seen the master key get corrupted and have to be restored (tip: keep a list of the master keys for your F5 appliances just in case).
Note: If the vCMP guest can be upgraded to v17, then first upgrade it to the latest version of v15 before making the jump to v17.
I would not trust a diff of a v14 and v17 raw configuration file. There is likely syntax and format differences.
I agree with Fallout1984 that the easiest way would possibly be to upgrade the vCMP guest to v17. Then create a v17 UCS file. Then import the UCS on to the rSeries device.
As all ready stated another possibility is to down grade the rSeries to the lowest version of TMOS that it will support. Import the v14 UCS. The upgrade to v17.
There is a third more advance way to import the v14 configuration on a BIG-IP running TMOS v17. Most of the bigip.config file should be able to be imported, merged, via the use of single configuration files (SCF). I use single configuration files to import configuration objects that are difficult to add via the CLI and do not get converted when importing a UCS file.
I disagree with article K81271448 stating that is optional to validate the merge operation. I require the validation before any SCF merging. It discovers the inevitable typos and missing brackets.
I run the SCF merge from the Linux shell.
1. Create a UCS in case something goes wrong with the SCF merge
tmsh save sys ucs /shared/tmp/$(echo $HOSTNAME)_$(date +%H%M-%m%d%y)