Forum Discussion

AboAmir's avatar
AboAmir
Icon for Altostratus rankAltostratus
Mar 14, 2023

Traffic migration from Existing BigIP 5200 cluster to another i5800 cluster without a Downtime !

Dear all,

We have currently two 5200 Big-IP LB working in cluster configuration (Active-Standby) mode.

We are planning to replace them with two new i5800 LB also in cluster configuration (Active-Standby).

I was able to migrate the configuration from the old LB to the new one using platform-migrate.

Once i prepare the configuration of the new cluster to be the same as the old one, What is the best way please to move the traffic to the new cluster without having any down time if possible.

 

Your fast response is highly appreciated.

Best regards,

application delivery
Migrate traffic from old to new cluster without downtime
  • Paulius's avatar
    Paulius
    Icon for MVP rankMVP
    Mar 14, 2023

    AboAmir Because you have already migrated the configuration over and these devices are using the exact same IPs and are different platforms your options are a bit limited. If everything migrated perfectly without any errors and you are 100% certain that the configuration is sound I think the best option is to connect the new F5s to switchports in the appropriate VLANs with the ports shutdown. Your downtime will be however long it takes STP to run through moving that port to forwarding and for you to clear arp on the gateway device and switches for the F5 floating and self IPs. The following are very broad steps and you will have to tune them a bit to work for you.

    1. Log into switch/s that F5s old and new are connected to.
    2. Log into switch's that you will have to clear arp on for the F5 IPs which should be all floating and self IPs.
    3. Shutdown old ports then no shut new ports.
    4. Clear arp on all the appropriate devices for the F5 self and floating IPs.

    It is possible that once you complete step 3 that everything will start to work but most likely you will also have to run step 4 for everything to work properly and everything should immediately start to work after step 4 has been executed. If I had to give a more precise time and based on only having to clear arp on 2-4 devices with those command already prepped and ready to paste in you should have about 2 minutes of downtime but maybe less if you have different people running steps 3 and 4 simultaniously.

  • AboAmir's avatar
    AboAmir
    Icon for Altostratus rankAltostratus
    Mar 15, 2023

    Dear  Paulius

    Many thanks for your response,

    You mentioned that "options are a bit limited" could you please advise about a different procedure if config migration is not the best.

    As our target to have zero downtime during the migration.

     

     

    Thank you,

    • Paulius's avatar
      Paulius
      Icon for MVP rankMVP
      Mar 15, 2023

      AboAmir Typically the better option to drastically reduce downtime is to standup the new F5s with the same configuration but just different IPs. Typically this isn't a feasible option because of limited IP space but is the better option because it allows you to allocate all new IP addresses and migrate virtual servers one at a time and then once everything has been tested, assuming your F5s are in path you can reroute the larger subnet to them and then remove any /32 routes you put in place for testing purposes. Going this route allows for near zero downtime assuming the VSs and routing that you are testing work when you put the temporary /32 routes in place.