BIG-IP Migration

In order to test upgrades to BIG-IP systems it would be useful to transfer the configuration to a virtual instance.  However, moving the configuration from a physical platform to a virtual platform seems to be consistently problematic.

I have identified a process which permits some (most/all) of the LTM services to be migrated and tested.

The certificate private keys, monitor passwords, and possibly other sensitive resources are protected with the BIG-IP key.  In order to be able to use resources from a configuration file the keys on the source and target system must match.

The virtual appliance I am using runs on Hyper-V.  Other virtualisation environments may require different changes, especially with the network.


Prior to applying the configuration the target virtual instance should be prepared, to make it as similar to the source system:

  • Install the same release and hotfix as the source system.
  • Ensure the target system has as at least as many network adaptors as are in use on the source system (don’t forget the management port).
  • Export the master key from the source system:
    /usr/local/bin/f5mku -K
  • Import the master key to the target system:
    /usr/local/bin/f5mku -r aaaaaaaaaaaaaaaaaaaaaa==
  • Ensure the target system has limited access/no routing to production addresses.  While many things will work fine there are risks associated with high availability and replicated configurations, where the restored test system may try and partner with a production system.  In addition any outbound monitoring, logging or reporting connections could result in contaminating production systems.


  1. Save and download an archive on the source system
  2. Use gzip to expand the .ucs file to a .im file
  3. Use tar to restore the contents of the .im file
    tar -xvf
  4. Edit the config/bigip_base.conf, making appropriate changes. See below.
  5. Use tar to create a new .im file (with an identical name), containing the original contents and the modified bigip_base.conf. I need to use sudo to read authorized keys file:
    sudo tar -cf *
  6. Use gzip to create a new .ucs file
  7. Upload the .ucs file as an archive to the target system
  8. Restore the configuration file onto the target system using a shell:
    tmsh load sys ucs /var/local/ucs/SOURCE-MOD.ucs no-platform-check no-license
  9. Remove any partner systems, change device certificates to make the new system untrusted.
  10. Change self IP addresses and routes (this could also be done through changing the configuration file but you should consider making any changes from the previous step in the config as well).
  11. Change the addresses of virtual servers.

Changed settings

I use a static IP address for the management interface, most of the changes required relate to this. The minimal set of changes to the config in my environment are:

  • Change the management IP address ‘management-ip’ in ‘cm device’ and ‘sys management-ip’
  • Change the gateway for the management-route.
  • Disable dhcp in the ‘sys global-settings’ section (mgmt-dhcp disabled)
  • Add ‘media-fixed 10000T-FD’ to net interface.  For me this was only required on 1.1, not all enabled interfaces, I don’t understand why.


I have only managed to get LTM working.  The GTM configuration seems to be loaded and visible, but the named daemon constantly restarts.  I can’t get the restored system to respond to DNS requests.