Forum Discussion

Gemini6's avatar
Gemini6
Icon for Nimbostratus rankNimbostratus
Nov 21, 2020

F5 Migration

Hi Dears,

 

If I wanna migrate from two F5 devices in HA mode to a new one device, Should I extract the UCS file before splitting the HA or it is normal to generate the UCS file in HA mode?

application delivery
ASM Advanced WAF
BIG-IP
  • mshoaib's avatar
    mshoaib
    Icon for Cirrus rankCirrus
    Nov 22, 2020

    Hi Gemini6,

     

    When you restore a HA UCS to a single unit, it will assume Active Unit config, IP addresses, etc and create IP conflict on the network.

     

    I would setup a single unit on a network and disable its ports ( internal, external, dmz etc.) probably at the network switch level and made it accessible only from its management port.

     

    Then I will restore the UCS to a single unit and verify the configuration. May be adjust IP addresses if needed and then bring it live on the network.

     

    The single unit also assume there will be a standby unit and have HA config. You can either leave it as is or may be clean up.

     

    I hope it helps.

     

    -Muhammad

    • ecce's avatar
      ecce
      Icon for Cirrostratus rankCirrostratus
      Nov 24, 2020

      Theres more to consider. If you for example set the "forced offline" (or minimum blades up on VIPRION) that setting is saved in the bigDB and included in the UCS, and so the restored unit will be brought up in an offline mode. I've used that to ensure a device does not start process traffic after it is started.

       

      If you're moving to another platform, check out the platform-migrate option when loading configuration. There's also a reset-trust option when loading config that might interest you if you load UCS config from HA devices.

       

      Don't forget to copy the master key to the new unit. In HA it is replicated. If you restore config on a new device you need to first import the key.

       

      It's also a good idea to do a tmsh load sys config verify before creating UCS so you know the UCS will actually load later and not bail out on a sytax error.

  • masajjad's avatar
    masajjad
    Icon for Cirrus rankCirrus
    Mar 18, 2021

    We have received 2 i5800 boxes that will replace 5050 (HA pair).

     

    Besides Common there are multiple partitions. We have LTM and ASM in place. New platform will have Adv WAF.

     

    I'm thinking migrating the config offline if it loads without error then just replace the hardware in network.

     

    What strategy should we take? Can I have some high level guideline?

    • ecce's avatar
      ecce
      Icon for Cirrostratus rankCirrostratus
      Mar 19, 2021

      High Level: Join the new hardware in the DSC group, sync config, test, remove old devices from group. :)

       

      Here is a little more detailed procedure from how I did it, but I write this from memory, but it should be fairly accurate. Of course, there might be configuration in your current setup that makes this not perfectly suitable to your situation.

       

      1. Match version of software on the new hardware
      2. Do basic configuration on the new device. Configure everything that does not sync, like license activation, hostname, device cert, VLAN, SelfIP (non floating), LACP Trunks, Route domains and so on.
      3. Match Port Lockdown settings on new device. I prefer to set Allow Default on an isolated HA VLAN. tmsh show cm failover-status will show you if you have port lockdown errors.
      4. Configure ConfigSync VLAN and Failover settings on new device.
      5. Verify connection to new devices.
      6. Set the new device to Forced Offline, to ensure this does not go active before configuration is synced. I've seen that happen.
      7. Log in to the active device in the current cluster
      8. Set sync to manual and turn off failback if that is configured. There might be considerations regarding HA Group if you use that.. not sure, have never used it.
      9. While logged in the a device in the current cluster, Add Device trust for the new device. This will sync the master key to the new device.
      10. Sync config in the Sync-Only Group
      11. Add the new device to the Failover Group
      12. Sync config from the active device to the group. This will be a full sync with a warning.
      13. Verify settings in the new device. Remember that Forced Offline makes Health monitors show weird values, they are not updated until forced offline is removed.
      14. Remove Forced Offline on the new device.
      15. Failover to new device.
      16. Run acceptance tests
      17. Remove old devices from cluster.
      18. Turn on automatic sync, failback etc if thats should be used

       

      Of course it is always a good idea to have backups, preferably stored offline and also backup the master key. I always to a tmsh load sys config verify before creating UCS files, since I have seen errors in configs being written to UCS files and then when you restore them it does not work.

       

      I think that's about it... not sure if ASM > AWAF could be an issue... Good luck!