NimbostratusDear all, I'm going to upgrade our current LTMs (1600 series) to new one (2200 series). My question is that whether it is possible to import "SCF" file from BIG-IP v10.2.4 into new BIG-IP v11.6 or not? Because, as I know, some of the configuration sections have been changed on new TMOS (v11.x), and I guess that is incompatible. If I'm right, so what is the best solution to have migration in less time?
CumulonimbusI'd first upgrade your current box to 11.X (depending on if the Hardware is compatible)
When you're on your target version, depending on your IP address allocation, I would join the devices into a device group, and sync configuration across to the new box. Then break the trust and disconnect the old box.
That's the way I'd tackle it (Very high level)
NimbostratusDear Lain, thanks for your reply, but in TMOS v10.x we have "Failover/HA" peers.On the other hand, there is limitation of only 2 devices in HA mdoe. But in version 11.x and after, we have new concept as "HA-Group", and as you know the new feature is incompatible with the previous one (due to difference in HA configuration steps - HA VLAN , ...). Did you check the mentioned solution before?
NacreousThere will be some hassle involved and the procedure won't be straight-forward. Contact F5 professional services to get assistance with the migration, or find a freelance consultant to help you out.
If you want to try yourself, then prepare a UCS archive file, and attempt to restore configuration from it, using
no-platform-checkno-licence/var/log/ltmDear Hannes, Many thanks for your reply. As one simpler and better solution, I think it's possible to revise the default "SCF" file of new LTMs based on current configurations, and then importing the new revised SCF file into TMOS v11.x
NacreousSCF formatting has changed a lot, it's not faster by any means. There are other problems, for instance, SCF does not include private keys and SSL certificates. That means the importing of those, and linking with relevant profiles will be yet another separate task to do. UCS adaptation works the best, but it's not the easiest of options for 1st time triers.
If you don't feel like using the UCS adaptation method, give a try to "playing with lego" approach. You can use "tmsh load sys config merge file /var/tmp/confFile.txt" to re-build configuration from a scratch. You will create multiple files, one containing nodes, the second file containing profiles, 3rd file containing health-check monitors... (you get the idea). You load them in one part of configuration at a time. The good thing about config merge option is that it also recognizes old v10 formatting (no need to re-invent the wheel with your own migration scripts), and it's also forgiving to obsolete/incorrect syntax (any unrecognized rubbish will just be discarded).
NimbostratusDear Hannes, Many thanks in advance for your tips, OK, as you mentioned, It seems that UCS archives are better choice in current situation. So let me think about what should I do in this regard... Certainly, if the need arises, I need your help again.
NimbostratusThere will be some hassle involved and the procedure won't be straight-forward. Contact F5 professional services to get assistance with the migration, or find a freelance consultant to help you out.
If you want to try yourself, then prepare a UCS archive file, and attempt to restore configuration from it, using
no-platform-checkno-licence/var/log/ltmDear Hannes, Many thanks for your reply. As one simpler and better solution, I think it's possible to revise the default "SCF" file of new LTMs based on current configurations, and then importing the new revised SCF file into TMOS v11.x
NimbostratusSCF formatting has changed a lot, it's not faster by any means. There are other problems, for instance, SCF does not include private keys and SSL certificates. That means the importing of those, and linking with relevant profiles will be yet another separate task to do. UCS adaptation works the best, but it's not the easiest of options for 1st time triers.
If you don't feel like using the UCS adaptation method, give a try to "playing with lego" approach. You can use "tmsh load sys config merge file /var/tmp/confFile.txt" to re-build configuration from a scratch. You will create multiple files, one containing nodes, the second file containing profiles, 3rd file containing health-check monitors... (you get the idea). You load them in one part of configuration at a time. The good thing about config merge option is that it also recognizes old v10 formatting (no need to re-invent the wheel with your own migration scripts), and it's also forgiving to obsolete/incorrect syntax (any unrecognized rubbish will just be discarded).
NimbostratusDear Hannes, Many thanks in advance for your tips, OK, as you mentioned, It seems that UCS archives are better choice in current situation. So let me think about what should I do in this regard... Certainly, if the need arises, I need your help again.
MVPbut even though those methods are incompatible you can upgrade your current boxes to 11.x and the HA part will be converted to the new method.
it might be different from what you suggest but it sounds like a solid path if the upgrade goes smoothly.
NimbostratusHey Boneyard, what rate of success do you get with that? In my experience, v10 HA is properly rolled forward to v11 on rare occasions. If you go straight to v11.4+, the clientssl's default.crt has a tendency to disappear from the profile configuration, and therefore the HA is screwed up as the cluster is not established on configuration load. Only after the link to default.crt is re-established in profile configuration, the HA can be configured successfully. Or maybe I'm just doing something completely wrong :)
Cumulonimbus10.2.4 - 11.2.x - 11.5.3 - 11.6
Upgrade both boxes,
I've done this very procedure and been pretty successful - (Aside for GTM named.conf conflicts)
Thats my opinion on what to do anyway :)