Migration from Virtual FMC to FMC Appliance

[mnair]

I have one vFMC, two FP 9300(HA) and two ASA5585-SSP-40 modules.

Recently purchased 4500 FMC appliance.

Like to know the best way to migrate from vFMC to appliance based FMC with minimal or no downtime.

What configuration can be exported and imported, what configuration will auto populate and any manual configuration required.

Thanks

[Oliver Kaiser]

You can export policies (includes objects used in the policy) but you would need to manually re-register your devices with FMC. In case of the FPR9300 you would need to break HA and re-add them to your new FMC4500 and re-build HA afterwards.

Since the migration is somewhat painful I would suggest reaching out to TAC. It should be possible to restore your virtual fmc configuration on the new FMC4500 appliance, but since it is not a supported scenario you would need TAC support & their blessing to go ahead with that procedure.

Hope that helps.

[mnair]

Thanks for your response. Will there be any production impact when HA break?

My understand was that until and unless we don't push policy after migration, any changes during migration should not impact production since FP 9300 and ASA5585-SSP-40 module already has all the info in its configuration.

Will there be any production impact during de-register and register of Firepower devices with FMC?

Thanks

Mani

[Oliver Kaiser]

There will be a short traffic disruption (< 10sec) when breaking and re-building HA. Keep in mind that you will need to re-configure interface monitoring after re-building HA.

[mnair]

In my case currently I have 1 vFMC, Two 9300 (HA) and two ASA5585-SSP40

Question:

Do i need to manually break the HA before associating the new FMC with FTD or it will automatically break when I associate with new FMC appliance?\

I was recommended the following below mentioned steps by someone who has experience with 9300 migration but Cisco TAC has difference opinion. So bit confused.

9300 migration to new fmc appliance Steps:

#  De-register secondary/standby FTD from vFMC

# Register secondary/standby FTD to our new FMC. Change the FMC IP on FTD CLI, and start the registration process via FMC UI.

#Disable the data interface (This is to make sure that we don’t get in any issues when we configure it identically to our still running primary/active unit, which is still connected to vFMC).

#Configure all the required device settings on secondary FTD like Devices, interfaces and static routes again. ( This part I am not clear what settings will remain as is and what needs to be manual configured? 

#Deploy configuration to our secondary/standby FTD and verify that it is identical to our primary/active FTD .To make sure we migrated all configuration correctly use show running-config and compare utility)

#Disable the data interfaces for our primary/active FTD device and enable the data interface on  secondary/standby FTD device using the FX-OS UI , basically do a failover with a very short interruption.

TCP sessions and xlate entries will be lost, but we can fail back in case of any issues and have minimal interruption time.

#Verify that everything is working correctly… Our secondary FTD should now forward all traffic, just like the primary FTD did

#De-register our primary/standby FTD from FMCv & register it to our new FMC and build the configuration.

#Build HA between your FTD devices. Make sure that the FTD we have as secondary is now the primary and vice versa

This is to make sure that the firepower that is currently forwarding the traffic, continues to do so and syncs its device configuration to the other box. There will be brief traffic interruption during HA build.

#Verify that HA is built correctly

#Re-enable the data interfaces on secondary FTD

#Re-configure interface monitoring settings if we monitored any data interfaces

#Verify that HA failover is working correctly. Failover to secondary and back. 

Question:

What about process for two ASA5585-SSP40 migration to new FMC Appliance?

I am assuming as long as no policy is deployed post migration, there is no risk of potential business impact? What happens if policy deployment fails post migration?