Forum Discussion
Sri_Narasimha_05
Altocumulus
AltocumulusOne-Arm Mode Migration
Hi Experts,
We're running F5 BIG-IP 2200 v15.1.2.1 (Build 0.0.10) appliances on HA and planning to migrate it to i2000 series (HA).
Currently, the config is one-arm mode and we've been asked to do a phased approach. Can you please assist if this is the correct approach?
Traffic flow: Internet -> NAT/policy on Firewalls for that VIP -> F5 (Auto-map) -> Backend servers
Current F5 config for VLAN: 126:-
Primary F5 Self IP: 10.126.1.4
Secondary F5 Self IP: 10.126.1.5
Floating IP: 10.126.1.6
VIP: 10.126.1.10
Proposed F5 config for VLAN 126:-
Primary F5 Self IP: 10.126.1.7
Secondary F5 Self IP: 10.126.1.8
Floating IP: 10.126.1.9
VIP: 10.126.1.10
We'll be building a parallel F5 (with different Self and floating IPs for each VLAN) and the VIP: 10.126.1.10 would be disabled on the Production F5 and enabled on the UAT F5 for testing.
Once testing is completed, similar approach would be carried for next application/VIP on the same VLAN, followed by other VLANs. In case of any issues, it's just a matter of disabling and re-enabling the VIP as needed.
In this scenario, VIP IP remains the same and the gateway will be the firewalls for the backend servers.
is it doable for the phased migration to happen? Thanks in advance.
Sounds ok to me. Just check that the ARP is enabled on the virtual address of the VIP. By default it is, but to be sure please check.
In case you have issues make sure you check the arp table on the firewall and the vip ip is pointing to the right mac address. Probably it be good to check this before you migrate a vip , and record the mac address so you can compare it.
Sri_Narasimha_05 the UCS restore overrides all configuration of the new device when imported last I had to do one with the exception of validating various difference between platforms when you use the platform migrate. You might try a UCS restore on a virtual appliance first in a sandbox to see exactly what happens.
mihaicMVP
Sounds ok to me. Just check that the ARP is enabled on the virtual address of the VIP. By default it is, but to be sure please check.
In case you have issues make sure you check the arp table on the firewall and the vip ip is pointing to the right mac address. Probably it be good to check this before you migrate a vip , and record the mac address so you can compare it.
Sri_Narasimha_05Hi Mate,
Thanks for the reply. Beside this, I've a question on migration.
I don't have Ubuntu desktop for the F5 Journey tool to be installed and I'm planning to migrate via the UCS "platform-migrate" option.
Can you please assist me on the best practices to migrate from one applicances to the newer ones using the above said option. K82540512 mentions the steps but doesn't outline the F5's best practice (like how to compare the config). Thank you.
- Paulius
Sri_Narasimha_05 Sadly I'm unfamiliar using the UCS platform-migrate option but if it's anything like the CLI UCS import ignore-platform command it ignores various interface specifics but imports the entire configuration provided the licenses are the same to support the imported configuration and doesn't allow you to change IPs in that process. You might consider using the SCF configuration file and doing a search replace for all the IPs in question and them importing with that.
- Paulius
Sri_Narasimha_05 Based on previous experience of migrating thousands of VIPs in a similar manner the better option, if you have the IP space for it, is to create the same virtual servers on the new F5s but with new destination IPs. For testing you can create one public to private NAT so that each group can test one at a time and all you have to do is change that one NAT for testing. On the you migrate a virtual server/s you would change the existing NAT/s for your production traffic to now NAT to the new virtual server/s IPs. Making the changes this way allows you one location to make changes and you will not have to mess with clearing any ARPs. About the only issue I can think that you might have is if your firewall uses the real IP to allow traffic rather than the mapped IP for security policies (SP) or access-lists(ACL). In order to get around the SP and ACL issue you can configure new SP and ACL with the new real IPs which should get rid of every possible issue. As applications are migrated you can update your documentation for the public to private mapping and virtual server association. Once you have finished the entire migration you can remove that single testing NAT because it is no longer necessary.
Now I do want to say that your plan will work it just requires you to deal with ARP, firewall issues, and F5 issues where the process I put forward would be one location and that's it.