Forum Discussion
Replacing Two HA Platforms with HA VEs
- Nov 15, 2022
Hi speachey ,
I like such these changes.
> Both of options are good ideas for migration , and you covered them well.I want to add some points below :
- After Activating the new licenses on both of New "VEs"
- Take the Master Key from of old F5 4200 appliance , it is enough one appliance as this Key is shared between them as long they are in HA Cluster or single device group.
For retrieving or getting this key issue the below Command on bash shell :
#f5mku -K , Note "K" is a uppercase letter.
Copy it’s output and save it in safe place.
before migration you must re-keying the master key on F5 Virtual edition " VEs" by issuing the below command on bash as well :
#f5mku -r "Key_output_from_the_old_appliance" , Note "r" is a lowercase letter.
> Without Re-Keying the master Key on "VEs" , your migration fails from the first step. - import "UCS" file , or transfer it to " /var/local/ucs " directory.
- Make sure that , the new VEs license is identical with Old device license in Features , I mean for instance if you have on your old devices " ASM , IP intelligence , GTM " you need to request a new license with the new "VEs" contains " ASM , IP intelligence , GTM " which are the same modules or Features.
- it is very very good to power both of VEs on the same version like old devices.
- when loading the ucs on VEs , correct you will use platform-migrate option but you must use the below command on tmsh prompt :
(tmos)# load sys ucs "File_Name" no-license platform-migrate.
> Why " no-licnse option" because F5 licenses is related to Appliances’ serial numbers and other parameters , and of course the license which exists on UCS is related to old appliances and is tied with its serial " mean old devices serials " .
So that you must exclude old license during loading ucs , at the same time you already configured the new license in " step number 1 " - After That , Revise your network design and Flow , and select your new interfaces which you are going to use , and assign again the Vlans to your interfaces " From Network >> Vlan >> (assign your needed interface to your vlan) " this part is depending on your design.
- I assume you will load UCSs on both of VEs
- After finishing " Vlans , Trunks , routes " , you will need to check the HA between both of VEs.
> I recommend that :
- Break up the HA between both of VEs , and remove each other from their device group.
- Re-build HA between both of VEs from scratch.
- Generate a new Certificate for both of them , before building device trust , check the below snap shot :
- Do not forget this step , the trust idea is exchanging certificates between both of appliances and you should not use an old certificate " old certificate will be transferred from old appliance via ucs on the new VEs " so you need to Re-new or re-generate new one.
> Follow this KB to build your HA correctly :
https://support.f5.com/csp/article/K42161405 - After Finishing HA , you will be about step on migration and you can test your services offline before changing the path of traffic from old appliances to new VEs.
- After making sure that all is fine , Take your maintenance window and change traffic Path to VEs to serve your application.
- Do you know , I do not recommend working with VEs over real Appliances , I think you will buy a new 2 physical appliances in the future , as a hardware based is more stable , speedy and efficient than Virtual edition.
- I prefer to choose " load ucs options ".
- I do not think disabling interfaces will add anything.
- you can use forced offline option , it is a very good idea.
- Automatic or manual Sync is not a problem in migration , start with manual sync , after guaranteeing that everything is stable , you can switch to Automatic sync.
I know you have covered most of my points , so I hope the above procedures help you if there are any missing point with you in migration plan.
GoodLuck in your Migration , you will enjoy by taking this Action.
Regards
Hi speachey ,
I like such these changes.
> Both of options are good ideas for migration , and you covered them well.
I want to add some points below :
- After Activating the new licenses on both of New "VEs"
- Take the Master Key from of old F5 4200 appliance , it is enough one appliance as this Key is shared between them as long they are in HA Cluster or single device group.
For retrieving or getting this key issue the below Command on bash shell :
#f5mku -K , Note "K" is a uppercase letter.
Copy it’s output and save it in safe place.
before migration you must re-keying the master key on F5 Virtual edition " VEs" by issuing the below command on bash as well :
#f5mku -r "Key_output_from_the_old_appliance" , Note "r" is a lowercase letter.
> Without Re-Keying the master Key on "VEs" , your migration fails from the first step. - import "UCS" file , or transfer it to " /var/local/ucs " directory.
- Make sure that , the new VEs license is identical with Old device license in Features , I mean for instance if you have on your old devices " ASM , IP intelligence , GTM " you need to request a new license with the new "VEs" contains " ASM , IP intelligence , GTM " which are the same modules or Features.
- it is very very good to power both of VEs on the same version like old devices.
- when loading the ucs on VEs , correct you will use platform-migrate option but you must use the below command on tmsh prompt :
(tmos)# load sys ucs "File_Name" no-license platform-migrate.
> Why " no-licnse option" because F5 licenses is related to Appliances’ serial numbers and other parameters , and of course the license which exists on UCS is related to old appliances and is tied with its serial " mean old devices serials " .
So that you must exclude old license during loading ucs , at the same time you already configured the new license in " step number 1 " - After That , Revise your network design and Flow , and select your new interfaces which you are going to use , and assign again the Vlans to your interfaces " From Network >> Vlan >> (assign your needed interface to your vlan) " this part is depending on your design.
- I assume you will load UCSs on both of VEs
- After finishing " Vlans , Trunks , routes " , you will need to check the HA between both of VEs.
> I recommend that :
- Break up the HA between both of VEs , and remove each other from their device group.
- Re-build HA between both of VEs from scratch.
- Generate a new Certificate for both of them , before building device trust , check the below snap shot :
- Do not forget this step , the trust idea is exchanging certificates between both of appliances and you should not use an old certificate " old certificate will be transferred from old appliance via ucs on the new VEs " so you need to Re-new or re-generate new one.
> Follow this KB to build your HA correctly :
https://support.f5.com/csp/article/K42161405 - After Finishing HA , you will be about step on migration and you can test your services offline before changing the path of traffic from old appliances to new VEs.
- After making sure that all is fine , Take your maintenance window and change traffic Path to VEs to serve your application.
- Do you know , I do not recommend working with VEs over real Appliances , I think you will buy a new 2 physical appliances in the future , as a hardware based is more stable , speedy and efficient than Virtual edition.
- I prefer to choose " load ucs options ".
- I do not think disabling interfaces will add anything.
- you can use forced offline option , it is a very good idea.
- Automatic or manual Sync is not a problem in migration , start with manual sync , after guaranteeing that everything is stable , you can switch to Automatic sync.
I know you have covered most of my points , so I hope the above procedures help you if there are any missing point with you in migration plan.
GoodLuck in your Migration , you will enjoy by taking this Action.
Regards
- speacheyNov 16, 2022Cirrus
Thanks for the response and details Mohamed! These load balancers are LTM + APM. I purchased and already received the LTM and APM VE licenses from F5 and applied them to the VEs and configured Resource Provisioning appropriately. Is there still a need to transfer Master keys? I never heard of Mater Keys so I need to understand/research that.
I mention exporting/importing device certificates because we use device certs signed by a CA and not self-signed. It was an organization requirement that complicates updating device trust between LTMs and separate BIG-IP DNS (formerly GTM) devices in other locations every year. I would not recommend anyone using signed certs for f5 devices if you can avoid it! Would you still advise creating new/unique device certs on the VEs? I could go through the device trust dance, if there is a compelling reason to do so.
You recommend hardware/platform over VE. I know the F5 HW chipsets in the past were always preferred over VE, but everything I have read shows the specs on current VM NICs and specs look sufficient for our needs. I have never put production LTM+APM (SAML/SSO) services on VE and I'm curious about the details of problems you have had. Did increasing VM memory/CPU address your issues? I don't think our load requirements are that high so it looks like VE should work fine ( 1K virtual servers, max of about 50K active connections, 150M throughput[bits], 250 APM Access Session/sec). Are your connections and throughput mush higher than ours?
Thanks again for taking the time to share your knowledge!
- Nov 16, 2022
Hi speachey ,
> About master Key :- It is the most important thing before Migration , this Key is relevant to UCSs or old appliance Configuration , and it must be printed on the VEs before loading UCS or you definitly fail.
Please read well this KB :
https://techdocs.f5.com/en-us/bigip-13-1-0/big-ip-secure-vault-administration/Working-with-ucs-files/ucs-installation-new-bigip-system/preparing-ucs-install-no-master-key-pw-no-access-bigip-no-object-pw.html
and this as well :
https://www.empirion.co.uk/f5/f5-master-key-rma-migration/
and take a look here Also :
https://securityguy225.wordpress.com/2016/11/11/how-to-migrate-all-configuration-from-2-different-f5-appliance/
____________________________________________________________________
> For Certificates :
- okay very well , you Can proceed without auto generating self sign certficate , but if you got errors in " Device Trust " it would be due to Certificate.
But at for a Certificate signed by CA , I expect that After migration , you will find both of devices "insync" Without issues.
_____________________________________________________________________
> For Physical and Virtual Editions :
I mentioned that as a Concern of Physical appliance Capabilities , but it seems you have done a good sizing with your needs.
- In internet service proiders , it is mandatory to use a very powerful Phyical appliances to process this huge Quantity of traffic.
____________________________________________________________________
Regards.
and GoodLuck with your migration - speacheyNov 16, 2022Cirrus
I should have added that I dropped support for the platforms when I purchased the VE licenses....so the platform licenses are about to expire
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com