Forum Discussion
NimbostratusMigrating to new LB pair
About a year ago I migrated our LTM from an old 3400 pair to the 6900 pair. We were running 9.x on the 3400s and 10.x on the 6900s. I exported an SCF from the old pair and made a handful of changes before importing it into the new pair. This was a very smooth process for us.
Now we require 10g interfaces so we purchased a pair of 4200v. They are running 11.2.1 (first release supporting this platform). I was hoping to do a similar migration/upgrade using SCF. I created an SCF from the 4200v after I configured basic management settings. It seems all the objects have a different format. We have about 600 VS, 300 pools, 60 VLANs, etc, so it will be pretty nasty converting everything to the 11.x SCF format.
Has anyone put time into converting SCF between v10 and v11?
I'm wondering if I should just plan on upgrading our production 6900 to 11.2.1, then do a more standard SCF migration to the 4200s. I checked the release notes for 11.2.1 and it says it can be upgraded from any 10.x, so it doesn't look like I need to be on the latest 10.x release.
13 Replies
natheCirrocumulus
rjordan
Rather than use an SCF have you tried exporting a v10.x UCS file and importing into v11.x - this should work. If the hostname of the two appliances are the same then it will do a full restore of the config file.
Rgds
N
rjordanBut with UCS, do I lose the ability to make changes before importing? At the very least, the physical interfaces (10g), management IPs and hostnames are different.
Thanks- natheYou can extract the UCS file and amend files accordingly if you need to. See: https://devcentral.f5.com/community/group/aft/1176442/asg/52
Looks like it's not without possible issues, however, and not something I've ever had to do. - What_Lies_Bene1
Cirrostratus
If you can't easily make changes why not just use the UCS method and modify the hostname, mgmt IP etc. as necessary afterwards? Sounds like a better option than recoding the config by hand. - rjordanI'll check out the UCS method when I can take my new 4200's off my network to avoid conflicts. I'm have a consultant coming in to assist so I'll be sure to discuss this option.
Thanks - What_Lies_Bene1OK, cool. If they have any better ideas please do let us know.
- rjordanI just want to follow up on my upgrade/migration experience in case anyone else is in the same scenario. After working through some of the options, here is what we did:
1. Configure basic configuration on the new 4200v pair. This includes hostname, management IP and the various device group stuff for HA. Make sure device group sync is working.
2. Upgrade our production standby unit in our 6900 pair to version 11.3.
3. Copy the bigip.conf from the upgraded 6900 over to the 4200v primary unit.
4. Copy various network settings from bigip_base.conf from the upgraded 6900 over to the bigip_base.conf on the 4200v primary unit. This step required a good amount of manual tweaks due to hardware differences. There are also several sections you don't want to overwrite such as the device trust sections, management IP, etc. We also had to change the self IPs so they reflected the "primary" IPs.
5. Copy certificates and keys from the upgraded 6900 over to the primary 4200v. In version 11, the certificate path changed.
6. Run tmsh sys config load on the primary 4200v so it loads the updated bigip.conf and bipip_base.conf files. I disabled the switch ports for the external and internal interfaces in order to avoid IP conflicts with our 6900 production unit.
7. Copy bigip_base.conf settings over to the secondary 4200v.
8. Run tmsh sys config load on the secondary unit so it loads the updated bipip_base.conf files. Again, the switch ports for the external and internal interfaces were disabled in order to avoid IP conflicts.
9. Sync the primary 4200v to the device group so the secondary 4200v will get the update config as well as the certificates.
10. Check for any errors.
11. Shut down switch port interfaces on the 6900 units and bring up switch port interfaces on the 4200v units.
12. Clear arp cache on upstream routers. - What_Lies_Bene1Thanks!
opediggitty_692Hey. I just want to say thank you for taking the time to come back on here and let us all know what you did to be successful with this migration. We have been struggling for weeks as we are also trying to get from 10.2.0 build 1707 to the latest version going from a pair of 1500's (I know right?) to a pair of 4000s' and have found out the huge differences in these versions after the very first function called "provision" in the old scf file is no longer called "provision." You were the first one I found that has shared their experience in this regard. I have found that F5 has not put any effort in "migration paths/steps" that are officially supported, I think in part by just how easy it was for you to go from 9.x to 10.x with an SCF file and minor by-hand changes. However, the jump from 10.x to 11.x is entirely different and I have been told by support that they are writing an approved hardware/software upgrade path with which we can follow on their support site but that they do not support a migration at all, at this time. He kept referring me to my local SE to take care of this. So now I just had my local F5 SE bring me a 3600 from his basement since this is one of the line of boxes that we totally skipped over that will allow both my current version and my new version of software on the device so I can then perform the upgrade on it to later move to the 4000s pair. Painful! That seemed to be the safest route given that I use both the 1.x and 2.x interfaces. I may still have to tweak those small differences though. If you have any more tips on tweaking for minor hardware differences within the conf files and/or the scf/ucs files that would be great. Thanks again.
JGCumulonimbus
An alternative path of upgrade could be:
- Downgrade 4200v to v10x;
- scf+ucs from the 6900s to 4200v;
- Upgrade to v11.1.2 on the 4200v.
This way, you won't have the stress of breaking redundancy while you experiment with the new.
I haven't done this myself, but I am planning my upgrade similarly.
