We are migrating from some 6900s to ve's. I have two devices at site 1 in HA active/passive and one device at site 2 in active state. both sites are configured with dns. i have used these articles as a reference.
I have all the ve's up and licensed. i have so far... interfaces configured, trunks configured, vlans configured with matching names of those on our 6900's, Management address configured, and Self-IP's have been configured with new addresses. i have a few things I'm confused about.
My understanding is a passphrase is needed during archive ucs creation or some ssl configurations will not be backed up. Is this passphrase the same thing as the masterkey I see referenced in some documentation?
will all of my DNS/GTM configurations including DNSSEC/keys be copied in the backup? I need to make sure this is up as site 1 is our ns1 and site 2 is our ns2. everything in our domain points to these.
Any recommendations on best way to go about migration if I want to reutilize previous IP's. I was thinking once platform migration is complete, shutdown the legacy device and build additional floating and non floating self-ips on the ve. once they are up, delete the ones I created for migration purposes.
any additional info would be much appreciated. thanks
the masterkey [f5mku -K] is used to decrypt the encrypted 'stuff' [password in auth configs, health monitors [ldap, http basic, etc..], ssl key passhphrase] in your ucs. so if you are restoring a ucs from another device, its worthwhile have this available. grab the master key from the source device and 're-key' the master key on the destination device.
not so sure.. but I would say yes.. the ucs takes care of these keys and i think dnssec keys will be included.
reusing the self ips is fine, just dont enable the interfaces [vlan/actual traffic] until you are done with initial config setup. enable only the mgmt interface. premature enabling of interfaces - same vlan on your old and new bigip - can cause you an active active state.. even if they are not in HA.
16-Feb-201821:32 - last edited on 05-Jun-202322:04 by JimmyPackets
I went through an "in-place" physical to virtual migration recently and my general steps were as follows. This assumes that all IP addressing, hostnames, and so forth will remain the same, and allows you to use the standard HA failover method as the old active and new standby will be clustered together briefly.
Deploy the new VEs to the same software version as the source systems.
Reset the masterkey on your source systems to the same value for each member in the cluster, and record it.
modify /sys crypto master-key prompt-for-password
Create a UCS archive for each source system, and store them somewhere safe.
On the destination VEs, set their masterkeys to match that of the source system.
modify /sys crypto master-key prompt-for-password
Upload the UCS archives to the destination.
Set the destination hostnames to match the source, and license the boxes. Create an archive at this point in case something goes wrong.
Shut down the standby unit, and re-IP the destination unit to match. (You could disable the box at the network level too, if you like. In my recent experience with this, we only had access to the AOM, so a power-off was appropriate.)
Load the UCS using the command
load /sys ucs no-license no-platform-check
At this point the new system should attempt to load the config. I did this on 11.5.4 and it needed a few edits to the config file, so just make the edits needed and continue attempting
load sys config
until the errors go away. This may vary on particular software releases.
Once the configuration loads, you can then reassign your VLANs to the correct interfaces, adjusting for tagged or untagged modes. If you were running a trunk previously, you'll have to remove the VLANs from that first.
At this point if everything worked out, then you should be able to see the cluster failover status as Standby. Configsync might even work too, if your software versions are the same. Compare the network maps on each, check the logs, then you could force your active to standby, then verify things look good. If everything is OK, repeat the steps and migrate the config from the other box.
Over all this method worked pretty well for us and we migrated 10 boxes this way. The nice thing about this process is that you don't need to stage any temporary self-IPs
To speak to your question about DNSSEC, I think that as long as your masterkey values match, then you shouldn't have any trouble with loading the configuration. As with anything, try to test as best you can, but hopefully someone may have an answer for you.
