FirePower Threat Defense (FTD) migrations from one FMC to another FMC with Policy

[vschary.scc]

Process for FTD migration with Policy

As per Cisco documentation, we have below steps for for de-register and register process. Please follow below steps :

Step 1 : Break HA pair and de-register your FTD from FMC (old).

Step 2 : Register your primary FTD with FMC (new).

Step 3 : Configure the interfaces and routing information on FMC (new).

Step 4 : De-register secondary FTD and register it with FMC (new).

Step 5 : Re-build HA on FMC (new).

Note : This process needs downtime as it will impact your traffic.

For registration process please refer to below link :

https://www.cisco.com/c/en/us/support/docs/security/firesight-management-center/118596-configure-firesight-00.html

For De-registration process first you need to delete the device from FMC and then you need to run below command on FTD.

configure manager delete

Manager successfully deleted.

For HA break process please refer to below link.

https://www.cisco.com/c/en/us/support/docs/security/firepower-management-center/212699-configure-ftd-high-availability-on-firep.htmlanc9

But, I have created a cheat sheet and documented the below steps in detail which always helps me during FMC migrations.

Detail Steps:

1. Create all necessary security zones with interface type under Objects ==> Interface on new FMC
2. Take the screen shots of Device Interface details from old FMC
3. Move (System ==> Export/Import) all the policies from old FMC to new FMC
4. On old FMC make secondary FTD ACTIVE - make sure all the traffic is flowing fine with accessing applications
5. Break the HA pair - minor interruption. All the traffic will be flowing through secondary FTD which is ACTIVE ==>Config will be removed from the primary FTD
6. Remove (DELETE) the primary FTD from old FMC
7. Shutdown the primary FTD interfaces on Chassis except the management. Disable all Port Channel Interfaces form 9300 Chassis Management portal if present.
8. Attach (REGISTER) the primary FTD to the new FMC
9. Do all the Device Management Config
10. Interfaces – ADD Port Channels and ENABLE if exists
11. Routing – ADD Static Routes
12. Verify the Device (Model, Routed, Mgmt), cross check
13. Verify the Summary for License
14. Assigning all the policies and deploy.

    NOTE: Since the interfaces on Chassis are shutdown, the primary FTD won’t take traffic. If the interfaces are not shut on Primary FTD Chassis, it can cause split brain and cause a major outage after deployment

15. Compare the Config of primary and secondary FTDs (one that is passing the traffic). Re-Verify all TABs.
16. Once the config is good on primary FTD.
17. Shutdown the secondary FTD interfaces from 9300 Chassis Management portal
18. Enable the primary FTD interfaces 9300 Chassis Management portal
19. Here we will have small amount of downtime
20. Clear the arp on switch/adjacent devices. All the traffic should be passing through the primary FTD now.
21. Validate all applications and verify the traffic on primary FTD, if all looks good then proceed further with step 22.
22. Remove (DELETE) the secondary FTD from old FMC
23. Attach (REGISTER) the secondary FTD to the new FMC
24. Create HA with group, as Primary and Secondary FTD
25. Update secondary interface IP Address and disable monitoring for time being
26. Verify all Device Management Config with captured screen shots and then push the policy
27. Re-verify all Device Management Config and Health alerts, then Enable Monitoring
28. One last time push the policy and validate the applications.
29. Verify the Logging with events.

[vschary.scc]

Caution: At Step #23, FMC will deploy the policy during the FTD registration process and the deployment will fail.

Workaround: Delete the FTD and do the re-register process. Attach a dummy or temporary policy with no rules in ACP during the registration process. This will make the FTD register and then attach the original ACP Policy which will be successfull deployment.

[thayyy]

@vschary.scc Is there any way of not having downtime in the migration from a virtual FMC to FMC 4600?

[vschary.scc]

The process of virtual FMC migration to FMC4600 would be similar steps provided in original topic as the FMC IP Address will be changing and this need all connected FTDs/ASAx must be re-register to FMC4600.

[Jason Gauruder]

We are preparing to do this similar process as well.  I would add after after step 3 "Take the screen shots of Device Interface details from old FMC" the following step :  "Take the screen shots of Device Routing tab details from old FMC".  This is required because things like prefix-lists and route-maps and basically any objects outside of ACP (ie : objects that are referenced by the FTD device only) are not part of export/import process.   There does not appear to be a good way to get those types of objects over from old FMC to new FMC that I am aware of.  so, have to re-create manually.

[sunil.moli1]

I have around 10 FTD 2k and few 4k which needs to be migrated from Old FMC 2500 without HA to new FMC 2600 (with HA).  Appreciate how to proceed & best practices.

[Garry Cross]

I just wanted to comment on a couple of items in this topic.

Both FMC must be the same version.

Here is a list of significant policies that can be exported for reference.

ACP, Flexconfig, Intrusion, NAT, Platform

I do not see any VPN in the list that can be exported and objects that go with the VPN config. 

No mention of Certificates. Are these retained by the device?

[alex.f.]

Hi,

I recently had to migrate a HA (tow FTD2130) from one FMC to a new one.

I installed the FMC in the exact Version and restored a five day old backup from the OLD FMC to the NEW FMC.

Everything was the same from the MGMT IP of the FTDs (10.0.0.x/24) to the MGMT Network of the old and new FMC (10.0.1.100/24), Certs, Policy's, RA VPN, S2S VPN, NAT, DHCP.

 I have made these steps:

- FTD2 Active HA disabled on Console

- FTD1 passive HA disabled on Console

- FTD2 Active delete Manager on Console

- FTD1 passive delete Manager on Console

- FTD2 Active add Manager on Console

- new FMC add Device FTD2 (with Access Policy)

The FMC pushed the Access Policy on the active Device and did something unexpected.

It deleted all Zones from the Interfaces, all Routes, every NAT statement, DHCP, CERTS, VPN S2S and VPN RA.

How is this possible?

What did I wrong?

[MacFergus]

As others have mentioned, it seems that the steps above have caveats or options... Admittedly, my FTD migration to another FMC was not as complicated because this is a secondary, smaller site so there's no IPsec tunnels, no user VPN, no certificates in my experience. But the instructions in this post are good; create the Zones on your new FMC, with the "type" like "Routed" (mine were all routed), but you cannot assign interfaces yet...do that after you Add the Active FTD to your new FMC and it will discover all the interfaces. Then Import your configs from your old FMC to your New FMC.  Then Break HA of your FTDs -- this will delete the config on the Standby FTD, leaving the mgt IP address -- then the Active FTD keeps working; this was nice, because downtime was actually minimal...  When you Delete the FTDs from your old FMC, it also deletes the "configure manager ..." stuff from the CLI of the FTDs--but deleting the Active FTD from the old FMC did NOT delete the configs from the Active FTD, so it kept working for me.  So then you add your FTDs to the new FMC.  Since the Active FTD still has all the interface configs, it will import them... Make sure you go to System > Licenses > Smart Licenses, to add your FTDs to the Threat, Malware, URL or whatever (because it'll throw errors for that too). Then you add interfaces to your Security Zones before deploying--and the FMC will FORCE you to deploy to the individual FTD boxes, BEFORE you re-create the HA FTD Pair...but not a big deal in my experience.  Since the Standby FTD had its interfaces and config wiped, when you deploy Policy, it will complain about stuff...but I went ahead anyway, once I got rid of Errors and just got down to Warnings (my errors were because I first tried to deploy before I added Interfaces to Zones, and before I edited Smart Licenses for my Threat and Malware). I'm not sure if by deleting FTDs from old FMC, if the old FMC reached out to software.cisco.com to say that my Threat and Malware licenses were available...but when I went to software.cisco.com, it showed that I had 2 licenses available for each... Also, re-do your OSPF or whatever routing you need, and if you exported/imported NAT configs, then go to Devices > NAT, select the imported NAT policy, then do Policy Assignments--I'm pretty sure that I only selected the Active FTD at first, then when I created the FTD HA Pair, it looks like the NAT policy updated, to use the FTD-HA-Pair, instead of the single, Active FTD.  So then I deployed my Standby FTD first, then I deployed my Active FTD, then I created the HA Pair of FTDs--it takes quite a bunch of minutes for the re-created HA FTD pair to settle down, but wait, and/or do the "Run all" from the System > Health > Monitor area, and eventually the health went green.  I had constant pings going to servers behind my FPR-2110 boxes, and I didn't lose many pings... I had 5 terminals pinging 5 Windows Servers--1 server stopped pinging, but the others only missed pings then picked up again.  I could ping the server in question from the FTD, so I just stopped my pings that were not working, restarted the pings to the same server that was not responding, and they worked...so some odd cache thing.  But again, this seems to have worked without serious downtime.  Just missed tens of pings here & there...  Also, not sure how much it matters, but the FTD database can leave some garbage in the database regarding the old FMC IP addresses.  On your FTDs, go to expert mode and run:

OmniQuery.pl -db mdb -e "select name,ip,uuid,last_changed, active, role from EM_peers;"

to get a list and UUIDs of FMCs, so if you've deleted the FTD from the FMC, and the "show managers" command from the normal FTD console says no managers are configured...there might still be garbage in the database from that OmniQuery above... so you can clean that up with

OmniQuery.pl -db mdb -e "delete from EM_peers where uuid='<your-UUID>';"