Hi,
I have a project where we are migrating from iSeries to rSeries and would like to to combine two current vcmp guests into one tenant in the new rSeries hardware.
What is the proper and easiest way to achieve this? Lets assume that we have APM, ASM and LTM configurations present.
Thanks in advance.
Teemu
TeamuK,
The easiest but time consuming process would be to manually duplicate all of the configuration on to the new rSeries.
Combining complex configuration from multiple BIG-IP devices can be accomplished. I have combined configurations. It’s not easy. It may take many weeks to complete. Merging the configurations is best left to someone with a lot of experience with the TMOS and BIG-IP module configuration.
I first would start by trying to have all the BIG-IPs running the same version of TMOS.
The easiest BIG-IP module to merge would be LTM. The LTM configurations can be merged via importing parts from the bigip.conf file from each of the iSeries devices. Sections of the raw configuration from the bigip.conf can be imported via single configuration files (SCF). When you import configuration via SCF you have to be aware of the dependencies. Example, a node may need to be added before it can be added as a pool member.
K13408: Overview of single configuration files (11.x - 21.x)
About The Single Configuration File
K81271448: Merging BIG-IP configuration objects into the running configuration using tmsh
My fingers and toes are crossed for ASM. You should be able to export the ASM polices from the older iSeries and import them on the new rSeries. Then manually add or import SCF for the other configuration objects needed for ASM. In the past I have found that the easiest way to import a BOT policy is via a SCF. Using SCF requires an understanding of the F5’s configuration files syntax. Once you have added all the dependencies. Add the virtual server and bond the ASM policy and configuration objects.
K13905104: Overview of importing and exporting BIG-IP ASM security policies
Merging APM may not be easy. The APM configuration is very complex. At high level you export and import the APM policy. Then manually add or import SCF to add the other configuration objects.
I can not provide a detailed process because there are a lot of dependencies. Example, An APM policy may be depended on configuration objects that need to be in place before you can successfully import the policy.
Importing and Exporting Access Profiles
On purpose I have left out discussing partitions.
The strength of BIG-IP is it massive number of ways in which it can be configured. It’s flexibility and complexity makes it time consuming to merge multiple BIG-IP into one device.
Teemu,
Adding to @mwolf’s answer — I’ve run this exact pattern a few times (iSeries vCMP guests collapsed into a single rSeries tenant, LTM+ASM+APM). Here’s the order that has worked for me, and the items that will bite you if you skip them.
0. Pick an “anchor” guest, then do a collision audit before touching anything
One of the two guests becomes the base of the tenant (pick the one with the most APM/ASM complexity). The other one gets merged into it. Before that, diff the two configs for:
/Common objects with the same name but different content — pools, monitors, iRules, profiles, data-groups, SNAT pools, certs/keys. These are the silent killers in a merge.The result of this audit is what decides your partition/route-domain design — and if the APM guest is also the one with overlapping addresses, it decides whether route domains can even solve the collision (they can’t; you’re renumbering instead). Don’t design it before you’ve run it.
1. Master key — but not with f5mku -r
A tenant has exactly one master key, and your two guests almost certainly have two different ones. f5mku -K only reads the key; using f5mku -r on a guest that already holds an encrypted config is documented to break the next config load.
The supported way is, on both guests, with the same password:
tmsh modify sys crypto master-key prompt-for-password
tmsh save sys config
f5mku -K # optional, to confirm both now match
Per K82540512 this “will re-encrypt all passwords and passphrases in the BIG-IP configuration with the new master key”, and “the same password will generate the same master key.” Then set the same password on the tenant before loading anything.
On impact: this isn’t documented as traffic-disruptive — it’s an mcpd/Secure Vault operation on stored secrets, not a datapath reload, and none of F5’s own procedures that use it (K82540512’s own migration steps included) carry a traffic-impact warning. What it does touch is HA: if the guest is an active member of a DSC device group, the key change syncs to its peer through normal config-sync. So still treat it as a change-window action — run it, then confirm with tmsh show cm sync-status right after instead of assuming the sync landed, and take a fresh UCS backup first: K03773000 documents the rekey failing outright (not silently, you get a decrypt error) if the config has orphaned encrypted objects still tied to an even older key.
Two caveats: if you’re below 16.0.0 and have DNSSEC keys, don’t do this (ID 639606), and regardless of the above, keep an offline cleartext inventory of every secret — monitor credentials, APM AAA bind passwords, SSL key passphrases, SNMPv3, OAuth client secrets. If the key alignment ever goes sideways, Solution 3 of the Secure Vault guide (put the secrets back in cleartext in bigip.conf and let the system re-encrypt) is your way out.
2. Version homologation — the rules differ per module
Practical consequence: upgrade both guests to the target TMOS on the iSeries, let them run, and only then migrate. Doing the upgrade and the platform move in the same window means you won’t know which one broke things. Also note platform-migrate doesn’t support UCS from 10.x.
3. Bring the anchor guest over with platform-migrate — don’t rebuild it
F5 explicitly lists “BIG-IP appliance-to-F5OS tenant migration” and “vCMP guest-to-guest migration” as supported use cases for this option (K82540512).
Prepare the tenant first: LAGs and VLANs on F5OS, tenant deployed with enough vCPU/RAM for LTM+ASM+APM combined, management IP, provisioning. On F5OS the tenant inherits licensing from the platform — no separate tenant license — but do confirm the platform license carries ASM and APM entitlement and enough APM session capacity for both guests’ load, not just one.
load /sys ucs <file> no-license platform-migrate validate # 21.1.0+, dry run
cat /var/log/platform_migrate_validate.log | jq
load /sys ucs <file> no-license platform-migrate
tmsh show sys mcp # expect full-config-load-succeeded
What it strips: interfaces, interface bundles, management IP/route, and trunk/VLAN assignments. Anything ignored is listed in /var/local/ucs/platform_migrate_ignored_objects. If your UCS contains trunk objects, prep it per K50152613 first — that one fails loudly on F5OS tenants. HA groups referencing trunks also need rework.
(The Journeys app still exists on downloads.f5.com but is being phased out in favour of platform-migrate, which runs native in TMOS with no Docker — see K000137313.)
4. Certificates and keys first
Agreed with your ordering — they’re a dependency for clientssl/serverssl and for APM SAML/OAuth. Two things to plan for:
/Common/wildcard.corp.com, different certs). Rename on import.ca-bundle.crt is not restored from UCS (K000138973), so re-import any custom trusted-CA bundles.5. ASM / APM / Bot / DoS
security dos profile and security bot-defense profile are ordinary tmsh objects in bigip.conf, so they merge via SCF like everything else (this is @mwolf’s point about importing a bot policy via SCF, and it’s the right call). Rebuild by hand only if you were going to redesign them anyway.profile-<partition>-<name>.conf.tar.gz) and use Reuse Existing Objects on import once the first guest’s AAA servers, webtops, connectivity profiles and resources already exist — otherwise you end up with duplicated AAA objects pointing at the same directory. Note that OAuth client application / resource server / scope objects are reused whether you tick the box or not./Common on route domain 0 — this is closer to a hard requirement than a style choice. K20465715 documents AD/DNS queries, SecurID, Kerberos SSO, EAM/OAM AAA, EMS and OCSP as RD0-only, and OAuth token requests are “sent through the default route domain (route domain 0)” regardless of config. On top of that, Bug ID1293805 (open through 17.1.2.2, no workaround) breaks OAuth auto-discovery for access profiles outside /Common, and ID1010597 causes connection resets when the VS sits behind a non-Common, route-domain-isolated partition. ASM has no such restriction, but I’d still keep it in /Common alongside APM — it carries no IP addresses either.6. Networking collisions — this is what actually decides the design
This is the part I’d check before committing to any partition layout. If the two guests have overlapping addressing, partitions will not save you — a partition is an administrative boundary, it does not isolate IP space. Route domains do: duplicate addresses are only allowed when each instance “resides in a separate route domain and is isolated on the network through a separate VLAN.”
The pattern that works: one partition per legacy guest, each with its own route domain set as the partition’s default route domain, so the merged config stays readable without %ID everywhere:
tmsh create net route-domain rd_guestA { id 10 vlans { ... } }
tmsh modify auth partition guestA default-route-domain 10
Constraints worth knowing before you draw it:
/Common cannot be assigned to a route domain in another partition — so create the per-guest VLANs inside the per-guest partition, not in /Common. VLANs in /Common land in RD 0 automatically./Common on RD0 regardless of how you partition LTM for the two guests (see point 5 above).On rSeries the L1/L2 layer lives on the platform: LAGs and VLANs are F5OS objects assigned to the tenant. So VLAN tags have to be unique and consistent at the platform level, and if both guests used the same tag for different L2 domains you need distinct tags or distinct paths. Also watch for L2 loops if you share VLANs between tenants.
And the honest counter-case: if the two guests don’t overlap in addressing, don’t add route domains. Use partitions for RBAC only. Route domains add real operational complexity (routing, monitors, troubleshooting) and you should only pay that cost if duplicate IP space forces you to.
7. The LTM merge itself
Rather than editing bigip.conf / bigip_base.conf in place on the tenant, I’d pull per-partition stanzas into .inc files under /var/local/scf and merge them:
load /sys config merge file guestB_ltm.inc verify
load /sys config merge file guestB_ltm.inc
save /sys config
Always include the full /partition/name path in both object names and object references, otherwise objects land in whatever your current partition happens to be. Respect dependency order (nodes → pools → virtuals → policies). Two known traps: using verify on a live HA pair can disrupt the HA connection (K15491), and a merge that changes an existing pool’s monitor can leave stale monitor instances behind (K17388).
Keep Appliance Mode disabled on the tenant while you’re doing this, or you won’t have the shell access this approach needs.
8. Acceptance checks before you call it done
tmsh show sys mcp → full-config-load-succeeded, and tmsh load sys config verify clean./var/log/ltm free of “Master Key decrypt failure” / “Decryption of the field (…) failed” — that’s your proof step 1 actually worked.It’s not a quick project — budget weeks, as @mwolf said. But getting the master key and the version alignment right up front is what turns this from “rebuild everything by hand” into an actual merge.
References: K82540512, K13905104, K81271448, K000137313, K50152613, K000138973, K15491, K17388.
Thanks a lot for the thorough explanation!