Update FMC ip address on FTD

[mumbles202]

I have a few FTDs that were managed by a pair of FMC 1000 in HA.  I had to break the HA, re-ip the standby FMC and re-establish the HA.  HA established, but getting the warning that the standby has few devices registered.  When I go into the FTDs and issue a "show managers" I'm still seeing the old standby FMC listed.  If i go into expert and issue:

cat /etc/sf/sftunnel.conf

I'm still seeing the old standby listed there as well.  Is there a way to just delete the standby FMC ip address or modify the sftunnel.conf file to correct it?

I saw this:

Firepower Management Center Administration Guide, 7.1 - High Availability [Cisco Secure Firewall Management Center] - Cisco

which seems to suggest to remove the device from registration, delete the active manager on the FTD (including and FTD HA clusters?) and then re-add the FTD to the active FMC?

[Marius Gunnerud]

If you are running a newer FTD version (7.x or higher) you can edit the manager information on the FTD CLI using the "configure manager edit " command

[mumbles202]

Perfect.  That worked for all of the FTDs and they all appear correct now.  I just have a pair of SFRs modules running 6.4 code that need to be updated now.  For those will I need to remove the registration and then re-add the SFR to the FMC and re-deploy policies?

[Marius Gunnerud]

unfortunately for any version below 6.7 (if I remember correctly) you will need to remove the devices and re-add them, as you have mentioned.

[mumbles202]

So I removed 1 of my SFR modules and re-added it back to the configuration.  If I issue a show managers now, it only shows the information for the primary FMC.  Did I miss a step (deleted the unit from the FMC gui, went to cli of SFR, added the FMC ip address, went back to FMC and registered the SFR and deployed policy.

[Aref Alsouqi]

I don't believe you need to remove the devices from the FMC, it would be enough to update the manager IP like you did.

[Marius Gunnerud]

This is correct.  When you add the FTDs to an FMC HA pair you only add it to the active FMC.  The registered FTD is then automatically registered to the standby FMC.

https://www.cisco.com/c/en/us/td/docs/security/firepower/660/configuration/guide/fpmc-config-guide-v66/device_management_basics.html

[mumbles202]

Thanks.  It took a while for the HA unit to show up, but when I checked last both of them were there.  

When I delete the SFR from the FMC will any events associated with it be removed from history as well?  Not the end of the world as it seems I don't have a choice but figured I'd ask.

[Marvin Rhoads]

@mumbles202 deleting a device from FMC should not affect any events (Connection, Intrusion etc.) already stored on the FMC

[Marius Gunnerud]

Events are historical log information so that should not be affected when removing a device from FMC as these are stored in separate log files, what can affect the events log is if they are overwritten by newer logs depending on how much your FMC is configured to retain.

[Marvin Rhoads]

@Marius Gunnerud : "you can edit the manager information on the FTD CLI using the "configure manager edit " command" - have you had the chance to use this? I am working on a project where it may be of help and was wondering about any real world experience with it.

[Marius Gunnerud]

@Marvin Rhoads  - Unfortunately no real world experience.  Have only played a little with it in dCloud where it worked fine, but in that case I was only changing the IP of FMC and not actually migrating to a new FMC.

I did have a use case a year ago, but the customer was running version 6.6.5 so I had to go through the process of removing and adding to the new FMC, a little more work with regard to routing, security zones and VPN, but all in all it wasn't too bad.

[Marvin Rhoads]

Thanks @Marius Gunnerud from what I was able to ascertain in my lab testing, changing the FMC address is quite disruptive.

We cannot use "configure manager edit" as it applies only to editing same UUID

To change manager IP address we need to:
1. Delete from current FMC
2. "configure manager delete" from FTD
3. Add from new FMC
4. "configure manager add" from FTD

This will require us to redefine the interface-zone and interface group-zone mapping in FMC (interface addresses will persist on FTD), reassign NAT policy, reassign RA VPN profiles (if any), recreate trustpoints (if used), re-associate platform policy, reconfigure all routing information (...and possibly a few more things I didn't mention)

[Marius Gunnerud]

@Marvin Rhoads I went through the same process a year and a half ago.  Customer had a service provider that was using an FMC as multi-tenant.  So FMC could not be taken over, backups were not available, and were running 6.6.x version so I was not able to test changing the FMC IP.  I believe if I was able to restore a backup from an old FMC to the new one, that changing IP would work.  We did get export of the ACP policy, NAT policy, and Flex Config which I imported to the new FMC.

The following is more for information to other that might read this post as you might already know this.

1. When the FTD was removed from the FMC, this also pushed the command "configure manager delete" to the FTD so I did not have to issue this on the FTD.  No configuration was removed during this stage and the FTD operated as it always had.
2. When adding the FTD to the new FMC the only thing that was imported was the interface configuration.  Everything else was removed since part of adding an FTD to FMC includes a policy deployment.  Since the new FMC has no existing policy for the FTD all configuration that is not included in the policy deployment is removed, as well as all VPN configurations.  You will be assigning an Access Control Policy but since you have not yet allocated the interfaces to that ACP policy it will not be in use yet.
3. At this stage I assigned all imported policies (ACP, NAT, Health, and Flex Config) to the new FTD and allocated the interfaces to the appropriate Security Zones and Security Zone Groups.  I had configured these zones beforehand to save time.  I also configured routing at this stage since all routing configuration will be removed during the onboarding process.  It is important to get the routing right if the FMC and FTD are on different subnets and management traffic is routed through this FTD.  You can configure the routing from CLI and then correct the mistake in FMC later but much better to get it right the first time round. 
4. VPN configuration is also removed as this references interface names. So, in some sites for the customer we had to get someone onsite with an ASA which I had configured beforehand so I could setup the association with the FMC.  These sites were running HA so using a data interface was not an option for management and we did not have enough public IPs to assign to the management0 interface.

This whole process was a real pain the first time I went through it.  Hit a bug on the FMC last month were all FTDs were removed from the FMC management and I was forced to go through this same process again.  But as I had a better understanding of what I was up agains and basically all configuration was already in place and just needed to be re-associated, it did not take much time once I had console access.  Down side was that I did need someone to go onsite at each location to assist with onboarding again.

[Marvin Rhoads]

@Marius Gunnerud thanks again for your detailed reply. I have ascertained that with FMC 7.1+ the "device backup" can help out since it provides the ability to restore the routing interface mapping etc. relatively quickly. We do have to re-attached the various policies (NAT, platform, Flexconfig etc.) and then redeploy to get everything synced. We are planning to lab out the whole process prior to making the production changes so I will keep you updated on how it works out.

Cheers!