I’m trying to import a UCS file obtained from the existing device (i2800 v12.1.5.2) into the VE version V12.1.5.2, but it’s not going smoothly.
The command I execute during import is: load sys ucs [i2800 UCS File] no-license platform-migrate
Upon checking the log (/var/log/ltm), I found the following errors:
[Errors]
err mcpd[4653]: 0107178a:3: Modifying license.maxcores to a value other than 2 is not allowed.
err loaddb[25057]: 01080023:3: Error return while getting reply from mcpd: 0x107178a, 0107178a:3: Modifying license.maxcores to a value other than 2 is not allowed.
err 010713d0:3: Symmetric Unit Key decrypt failure - decrypt failure
err Decryption of the field (secret) for object (/Common/system_auth_name1) failed.
err tmsh[25642]: 01420006:3: Loading configuration process failed.
emerg load_config_files: “/usr/bin/tmsh -n -g load sys config partitions all platform-migrate” - failed. -- 01071769:3: Decryption of the field (secret) for object (/Common/system_auth_name1) failed. Unexpected Error: Loading configuration process failed.
I only need to verify the configurations from the old model; it’s acceptable if maxcore decreases. My goal is to successfully complete the load sys command. Any support on how to address these errors would be greatly helpful.
igssv It looks like you did not migrate the master key from the old F5 to the new F5. This can be done easily if you have access to both devices. The following document has the steps which can be found if you search for “f5mku -K” when the page loads.
Thank you for your quick response! Since the old F5 is still in operation and we want to avoid elevating security risks for our clients, we would prefer not to migrate the master key. Is there a way to review the configurations without migrating the master key?
igssv Migrating the master key will not cause any disruption on your existing F5. All you are doing for this is you are retreiving the master key value from the old F5s and then taking that key and configuring it on the new F5s. After that you should be able to import the configuration on the new F5s.
Thank you once again for your prompt response. So, retrieving the master key itself won’t have any impact on the operations. I’ll discuss with our client about obtaining it. Thank you.
I successfully loaded the UCS. Thank you! However, now I’m unable to log in because the passwords for the root and admin accounts are unknown.
I have been referring to the URL myF5. However, after booting in Single User Mode and running the mount -a command, nothing is mounted, and I can’t use the passwd command.
Ideally, I’d like to reset the passwords and log in. Alternatively, I’m wondering if there is a way to load sys without importing the user account information.
Hi, Paulius,
As expected, then. Without asking our client, we won’t know the account information for the old F5 device. We were hoping to find an approach that wouldn’t inconvenience them, like a method of not importing user information. If it’s difficult, I’ll consider consulting with the client. Thank you so much for all of your responses!
igssv If you have access to the old F5s you can change the admin and root password, then create a UCS, and finally import that new UCS which should have the new usernames and passwords. Sadly, sometimes in order to get the job done correct you will have to ask for additional information. It’s better to inconvenience them a small amount now then a large amount in the future.
Thank you for the advice! Unfortunately, it’s already Saturday here in Japan, so I resolved the issue by customizing the UCS as follow.
```
On the Virtual Edition (VE), the following steps were executed:
- Ran `f5mku -r <old master key>`
- Executed `tmsh save sys conf` to save the system configuration
- Obtained the UCS
In old UCS:
- Added `fallback true` to the `auth source` section in `bigip.conf` (which was initially set to `type radius`)
- Copied the `encrypted-password` for `auth user admin/root` from the UCS on the VE over to `bigip_user.conf`
- Changed `sys httpd` in `bigip_base.conf` to `ALL`
```
Thank you so much for your consistent guidance! With your help, I’ve successfully reached a point where I can review the client’s configurations without any issues!
I would also like to extend my gratitude to you! As written in my response to Paulius, I was able to accomplish what I needed by tweaking the contents of the UCS! Thank you!
You need to do this for platform migration , glad you are successful, you can refer this process for future migrations:
modify sys crypto master-key prompt-for-password
==================================
K82540512: Overview of the UCS archive ‘platform-migrate’ option
Published Date: Oct 1, 2018Updated Date: Jul 12, 2023Toggle showing the products this articleApplies to:
Topic
F5 added the “platform-migrate” option to the tmsh load sys ucs command. This option enables you to migrate configurations from older platforms to newer platforms using an existing user configuration set (UCS) file. The new platform can be a newer generation hardware device, an F5OS tenant, a Virtual Clustered Multiprocessing (vCMP) guest, or BIG-IP Virtual Edition (VE).
Description
Starting In BIG-IP12.1.3 and 13.1.0, F5 introduces the platform-migrate option to better facilitate cross-platform configuration migrations. In previous versions, you can create a UCS on one platform type and install it on another using the no-platform-check option. However, the no-platform-check option installs the base configuration, so it may not be optimal when installing to different platforms.
You can enable the platform-migrate option using the following TMOS Shell (tmsh) command syntax:
tmsh load sys ucs <filename> platform-migrate
The platform-migrate option causes the UCS loader to ignore some platform dependent configuration objects when installing the UCS configuration. For example, when you install a UCS file using the platform-migrate option, configuration objects related to the following items may not be installed from the UCS file:
Interfaces
Interface bundles
Management IP and route
Assignments to trunks and VLANs
For example, a trunk is loaded on the new platform but interfaces, interface bundles, and VLANs assigned to it previously are not loaded.
Note: When you install a UCS file using the platform-migrate option, the system saves a list of any configuration objects that it ignores or does not install to the /var/local/ucs/platform_migrate_ignored_objects file.
Limitations
When using the platform-migrate option, consider the following limitations:
The platform-migrate parameter does not work for migrating BIG-IP UCS files from BIG-IP 10.x. If you are migrating the BIG-IP system, you must start with a BIG-IP configuration from a BIG-IP 11.x installation.
After you load the UCS using the platform-migrate parameter, you may need to perform extra steps to get the device fully functional.
For example:
You may need to reassign your new interfaces to VLANs.
In a high-availability (HA) environment, you may need to synchronize the configuration (enter configsync).
You may need to rebuild your device group if your new device’s management IP address is changing as part of the migration. You can specify the “keep-current-management-ip” option to the “load sys ucs” command to keep current Management IP when restore ucs archive. For more information, refer to K000132494: Overview of the UCS archive ‘keep-current-management-ip’ option.
If you use the platform-migrate parameter to bring up a new F5OS tenant or vCMP guest, you configure the VLANs from the host.
If the management IP address on the old platform used Dynamic Host Configuration Protocol (DHCP) relay, and you use the platform-migrate parameter, the management address of the new platform changes to use DHCP.
Recommended Action
Consider using the platform-migrate option if you are migrating from old or obsolete BIG-IP appliances to a newer platform family. F5 recommends that you use the **platform-migrate option for:**
BIG-IP Appliance-to-appliance migration
BIG-IP Appliance-to-vCMP guest migration
F5OS tenant-to-tenant migration
vCMP guest-to-guest migration
Procedures
To complete a platform migration using the platform-migrate option, perform the following procedures:
Saving UCS files on the device to be replaced<strong><em>Important: <em>If your configuration contains DNSSEC keys and you are running BIG-IP version prior to 16.0.0, do not use **tmsh modify sys crypto master-key. Use the workaround provided in [ID 639606.](https://cdn.f5.com/product/bugtracker/ID639606.html)**</em></em></strong>
Log in to tmsh of the device you are replacing by entering the following command:
tmsh
Set the device master key and password by entering the following command (remember this password because you’ll need to use the same password on the destination device):
modify sys crypto master-key prompt-for-password
Create the UCS file on the device to be replaced using the following command syntax:
save sys ucs \<file name>
Copy the UCS file to an offline location.
On the device to be replaced, force it offline by entering the following command:
run sys failover offline
This ensures that the system moves the traffic to the other device before shutting it down.
Shut down the old device.
Loading UCS configurations on the new device
<strong>Important: Before you load the configuration on the new device, you must first license, provision, and manually configure the low-level configuration on the new system. Before installing the UCS configuration, use **tmsh or the Configuration utility to configure the management IP address (unless you are using DHCP) and configure the interface settings required for your environment.**</strong>
To load the UCS configuration onto the new device, perform the following procedure:
Copy the UCS file that you prepared on the old device, to the new device.
You can do this using the Configuration utility by going to <strong>System > <strong>Archives > <strong>Upload or by manually uploading the configuration to the **/var/local/ucs directory on the new device.**</strong></strong></strong>
Log in to tmsh by entering the following command:
tmsh
Set the master-key password on the new device by entering the following commands:
modify sys crypto master-key prompt-for-password
save sys config
**Important: If you configured the management IP address of the new device to use a static IP address, and the old device used DHCP, the management IP address may change when you load the UCS using the platform-migrate option. Make sure you have appropriate console access available that does not require that you use the management IP address.**
Load the UCS file from tmsh by entering the following command:
load /sys ucs \<filename> no-license platform-migrate
If the **platform-migrate command completes successfully, the system displays the following message:**
Platform migrate loaded successfully. Saving configuration.
Confirm that the system is in the running state by entering the following command:
show sys mcp
The system displays the following message:
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
Sys::mcpd State:
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
Running Phase running
Last Configuration Load Status full-config-load-succeeded
Confirm the new device joined the trust group and is in Standby mode. If your management IP address changes, you must reconfigure the Failover Unicast address so that it matches the management IP address.
Bring the new device back online in the HA configuration by entering the following command:
run sys failover online
Resolving issues
While installing a UCS with the platform-migrate option greatly reduces the time it takes to migrate from an old or obsolete platform to a new one, installing a UCS with the platform-migrate option does not guarantee that the configuration will successfully load on the new system. You may encounter errors if you do not create the low-level configuration in advance. If you encounter an error, review the error message, make the appropriate changes, and then run the command again.
**Warning: The system is not in a running state after it produces an error, and the system will not save the configuration changes.**
If the **platform-migrate command fails, Master Control Program (MCP) is placed in a non-running state; enter the following command to check the MCP state:**
tmsh show sys mcp
This command indicates that the running phase is called <strong>platform and the load status is **high-config-load-failed.**</strong>
Example output:
\[root@bigip1:Active:Standalone] shared # tmsh show sys mcp
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
Sys::mcpd State:
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
Running Phase <strong>platform
Last Configuration Load Status **high-config-load-failed**</strong>
Therefore, the command <strong>tmsh save sys config fails to save the configuration and generates an error message. As you add the required low-level configuration objects, note that until the **platform-migrate command succeeds, you can change the configuration, but you cannot save it.**</strong>
## Related Content
<em>**Please mark it as solution in case if you feel your query has been responded and saved your time and giving pointers toward resolving your issue, as it will help other to use your query scenario to solve their similar issue.**</em>
Thank you so much for the comprehensive explanation regarding the ”platform_migrate" option! Your insights were super helpful. For this particular instance, our primary goal was simply to deploy the current device UCS to the Virtual Edition and validate the settings, so it looks like we can afford to overlook any potential issues. I might reach out again for advice if we run into any hurdles down the road—hope that’s okay!