Forum Discussion
CirrostratusHow to Verify config before loading to F5
I have edited .ucs file from old F5s and tried to load it on new F5s. The system went into Inoperative state and had to load the cfg that was configured before loading the edited config from old F5.When it was is inoperative, i ran tmsh looad sys ucs verify and it showed one of the line was not commented #
- How can we verify the file before loading to the config
- I have the new F5s up with HA and Syncfailover setup(GTM is not yet setup). The management IP, HA selfIPs and VIPs are different on the new implementation. Is there a recommended way we can merge this config.
- Plan to have iquery established after the config is loaded. Is that okay?
3 Replies
- sircrocodile
Nimbostratus
Hi,
1. Verifying the UCS Before LoadingYou're on the right track with the verify flag. Always run this before doing the actual load:
tmsh load sys ucs <filename>.ucs verify
This performs a dry-run validation without applying any changes to the system. Review the output carefully and fix any flagged issues (such as uncommented lines) before proceeding with the actual load.
2. Recommended Migration Method >> platform-migrate
Instead of manually merging configs, I'd strongly recommend using the `platform-migrate` option introduced by F5 specifically for cross-platform migrations:
tmsh load sys ucs <filename>.ucs platform-migrate
This is documented in F5 Article https://my.f5.com/manage/s/article/K82540512
Here's why this is cleaner than a manual merge:- It automatically skips platform-dependent objects such as:
- Interfaces and interface bundles
- Management IP and routes
- Trunk/VLAN assignments
- This means you avoid overwriting your new Management IP and HA Self-IPs on the destination box, exactly the problem you're trying to solve.
Handling VIPs that differ on the new platform:
Since `platform-migrate` does not automatically remap VIPs, you will need to manually edit the bigip.conf file inside the UCS archive before loading.
3. Recommended HA Migration
Since you already have HA + Sync Failover configured on the new boxes, follow this sequence to minimize traffic impact:
Step 1. Force the Standby unit offline before touching it
Step 2. Load the UCS on the Standby unit using `platform-migrate` to preserve the new box's management IP
tmsh load sys ucs <filename>.ucs platform-migrate
Step 3. Reassign interfaces to VLANs if needed, as `platform-migrate` does not carry interface-to-VLAN assignments over.
Step 4. Reset Device Trust and rebuild the Device Group since the HA Self-IPs have changed on the new platform, the old device trust will no longer be valid.
Step 5. Verify HA state is properly established:
- tmsh show cm sync-status
- tmsh show cm failover-status
Confirm the device group shows In Sync and both units are visible with correct Standby/Active roles before proceeding.
Step 6. Verify all Virtual Server, Pool Member states and availability are green on the Standby unit:
Step 7. Perform a failover once Standby is confirmed stable
Step 8. Repeat the process on the ex-Active unit (now Standby), following the same steps above.
InquisitiveMaiThank you sircrocodile , I will try this. Would self IPs be changed with platform migrate command? I have created new self IPs(floating and local) on the new F5 pairs, Plan to have new VIP ip range on the new F5s.
Also, On the new F5s, we do not want to have the same resource provisioning. Want to disable the modules which we do not use. Which file we should edit
