Re: fmc deploy with missing ftd

jbates5873 · ‎07-16-2023

hi all,

We have a project to migrate an instance of FMC from On prem into Azure. This has been completed and works as expected, however we have an issue where we need to upgrade it to the latest gold star version. And have an issue, as the current FTD units are still residing on the existing FMC. This should not be an issue, as they can just be reconfigured to talk to the new instance and that should be fine. However, there is an issue where we need to do this process in stages and move a spare unit from site to site to upgrade the production unit.

The process is take SPARE unit, configure it to SITE A, then deploy it into SITE A, and take the production unit for SITE A, and configure it to SITE B so on.. and at the end, ship back the remaining spare box from the last site to Head Office.

However, I am unsure if we can in the process of doing this, join and deploy 1 unit into the Azure FMC at a time? The customer and project is very sensitive to downtime, so we have chosen this method as we can always retain 1 in place production unit, and then just jump the physical connections between production <-> replacement unit if there are issues, and connectivity can be quickly restored.

My question is, can we add 1 unit to azure, and then deploy its config one at a time? currently there are 3 units in the FMC. the plan is outlined below. Once the units are all migrated from ON-PREM to Azure, then we can proceed with the upgrades of the units. This is not an issue.

	Site A	Site B	Site C
Step 1	Spare Unit (new Site A Prod - Azure FMC) Existing Site A Prod - ON-PREM FMC	N/A	N/A
Step 2	Spare Unit (new Site A Prod - Azure FMC)	reconfigured Site A Prod - Azure FMC) Existing Site B Prod - ON-PREM FMC	N/A
Step 3	Spare Unit (new Site A Prod - Azure FMC)	reconfigured Site A Prod - Azure FMC)	reconfigured Site B Prod - Azure FMC) Existing Site C Prod - ON-PREM FMC - Return to H/O with no config

In order to do the above, can we simply just join the SPARE unit to Azure using the SITE A name, and then re-deploy the SITE A config onto this unit only? and ignore the fact that the other 2 units are not actually connected to the AZURE FMCv?

I hope i have explained this well enough. If not, please let me know.

Marvin Rhoads · ‎07-24-2023

I am working through a similar project. The main issue is that when we remove a device from an on-prem FMC so that it can be claimed by the cloud FMC it will need to have its routing, interface-security zone mapping etc rebuilt. That can be done with a device backup and restore (requires FMC 7.1 or higher). You will also need to re-associate NAT, Platform policy, VPN configurations etc. with the device once it is managed by the FMC in the cloud.

jbates5873 · ‎07-24-2023

So, this is what im wondering though, as we have a complete spare device, I am hoping that we can join it in as one of the units, and then just deploy the config to it. Then once thats done, repeat with the second device in FMC and then we can work towards upgrading them to latest gold star.

Would that work do you think? or will we be in an issue where we are unable to deploy from FMC, as one of the FTDs is missing.

I dont have spare hardware to lab this up so it makes it quite hard to test this in a lab.

Marvin Rhoads · ‎07-25-2023

If you replace an offline device with a physical spare, that should work. If a managed device is not reachable though, that device will continue to show as pending deployment.

jbates5873 · ‎07-25-2023

thanks for that.

would we just need to name the spare device the same as it is in FMC? Is that all it uses for the registration? or is it tied to the IP address? and for example, you could change the name but as long as the device is the same model, and the ip matches its name can be totally different to whats registered in FMC? Or is there some other unique identifier that is used for the registration and thats what it uses to track the device?

EDIT: As the spare is a complete blank device, what would be the best path forward with that? if we give it the same hostname, and IP as FMC is expecting, will it just start talking to FMC and we can do a deploy to push out all the interfaces, NAT, S2S, Policies etc...??

Jason.

Marvin Rhoads · ‎07-26-2023

When you add a devices in FMC, even if it is replacing one formerly defined, you need to newly associate the ACP with it. Then, after registration and discovery, you would need to re-associate device configuration, NAT, VPN, platform, etc. to the device and deploy once again,

jbates5873 · ‎07-26-2023

Ok, so i guess that rules out just simply inserting the NEW device in and it picking up the config of the old and we can just DEPLOY it.

I wonder if we can deploy the new device as a new FTD in FMC, and then pull its config using the FMC option in Devices -> Device -> General? This will hopefully mirror the old source unit.

Im going to give this a shot next, as it might work to pull over all the NAT and S2S config. I will report back.

EDIT: Hmm, perhaps not.

to clarify, the CUBE unit is our production unit and the TEST is the target. they are the same device. and the config on the TEST is bare (other than joined into the same FMC) I have cloned our fmc so that i can experiment in a bit of a sandbox environment, and changed the IP's etc as needed. but, no-bueno thus far.

EDIT EDIT:

So, i just configured the interfaces on the TEST unit to match the same as the office PROD unit, and then i was able to pull the config from office PROD -> TEST... and then was able to deploy it successfully.

Looking at the ```show running-config``` for the unit, it appears to have worked, as it has put in the DHCP scopes and connection types for things. I dont have a S2S tunnel to test this with though, so am unsure if that will work? But this is atleast a good starting point. what are your thoughts on this approach @Marvin Rhoads ??

Marvin Rhoads · ‎07-27-2023

I am taking a similar approach on a project of my own.

I have not yet reached to point were i can test S2S and RA VPN configs with the approach but, from what I have researched, this is the least painful way forward ...and one that works within Cisco's supported (albeit clunky) migration path.

jbates5873 · ‎08-02-2023

so, an update to my progress,

I tested this at the office with our production and spare 1010, using a new FMC, did a backup and restore and then added the spare 1010 to that dev instance. it worked perfectly. The only catch was that the interfaces needed to be created first (which seems at odds with pulling / cloning a config, but i digress)

So, i go to our customers office to test it with their spare 2130 unit, and perform all the same steps and was greeted with this error. I am unable to find ANY information on this in the documentation or even looking around on google or reddit. We checked multiple times and can confirm that the interfaces are configured EXACTLY the same between the units.

The only difference is that the units are about 4 years apart in age. However i dont know if that would make a difference. Al of the speed configurations on the interfaces (and all other tabs for that matter) are exactly the same between the units.

So, im at a loss here. open to any suggestions if you have them @Marvin Rhoads

Marvin Rhoads · ‎08-03-2023

You cannot restore a 1010 configuration onto a 2130 device. The backup / restore process requires the exact same hardware.

Otherwise you will have to build the device-specific settings from scratch (basically anything that's setup under the device page tabs - interfaces, zone mapping, routing, license assignment etc.).

jbates5873 · ‎08-03-2023

Na, I went 1010 -> 1010 in my test environment. That worked as expected.

I ran into the interface speed issue when doing 2130 -> 2130

Re-reading my post, I understand how it seemed I went 1010 -> 2130. But it was all the same model migrations.

Marvin Rhoads · ‎08-03-2023

There were some changes in the 2100 series interface definitions that I recall would lead to some cosmetic error messages on FMC after upgrading even a given appliance. I recall they were related to some default commands Cisco changed per interface. Even though the capabilities are the same across releases, how FMC parsed the running-config changed. You may be hitting a previously-unknown symptom of that bug.

jbates5873 · ‎08-03-2023

Hi marvin. Of course there is. Why is nothing ever easy with these firewalls. Even the simplest things are a mission to complete. Haha.

Do you by chance have any recollection of the details of this bug so i can look for more info on it?

Marvin Rhoads · ‎08-04-2023

@jbates5873 this was the bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwa14518

...and I discussed it in this thread: https://community.cisco.com/t5/network-security/fmc-health-alert-not-clearable-interface-status-modified/td-p/4528153

jbates5873 · ‎08-09-2023

Hi Marvin, thanks for that.

After investigation looking through a ```sh int```, we noticed that one of the interfaces on the SOURCE was set to 100MBPS (although the interface setting in FMC was AUTO) and when replicated to the TARGET, it was set at 1000MBPS.

We manually assigned the TARGET interface down to 100MBPS to match, and even after multiple deploys it did not work, We are now going down the manual path of applying the configs and policies, and not using the config push / pull.

Thanks for the assist though.