Firepower 4112 Context - Upgrade(FXOS and FTD)

[laurathaqi]

Dear community, 

I have two physical appliances of Firepower 4112. Have four context one them, 2x in the first instance and 2x other on the second instance. Furthermore, 2x Logical Device(firewalls) are meant for the Edge and 2x Logical Devices(firewalls) are meant for the Datacenter. 

For high availability, the first Physical appliance has an Active Logical Device named as Edge-FTD1, and a Active Logical Device named as Datacenter-FTD1, meanwhile, the second physical appliance has an Passive Logical Device named as Edge-FTD2 and an Active Logical Device named as Datacenter-FTD2.

Edit: This all meaning: Edge Active/Passive and Datacenter Active/Active(cluster mode).

Now, when willing to upgrade, based on Cisco's Guide, its best to follow the steps of: 

1. Upgrade FXOS on the standby.
2. Switch roles.
3. Upgrade FXOS on the new standby.
4. Upgrade FTD.

Does this mean that I have to first upgrade the two FX-OS-es on the Two Physical Appliances, via Upgrade, Switch, Upgrade. And only after both FXOS-es are upgraded, then Upgrade FTDs(first the passive and then the Active.)

Does someone has any advice how to plan act on the noted case in regards upgrading. 

Looking forward to any suggestions or advices. 

Best regards, 

Laura 

[Marvin Rhoads]

Correct for steps 1-3.

For step 4, FMC will take care of upgrading whichever device is standby role first and then do the same once it completes for the other unit. It will take care of the role switch from standby to active.

[Mike.Cifelli]

Does this mean that I have to first upgrade the two FX-OS-es on the Two Physical Appliances, via Upgrade, Switch, Upgrade. And only after both FXOS-es are upgraded, then Upgrade FTDs(first the passive and then the Active.)

-I agree with @Marvin Rhoads and the identified processes/phases for the upgrades.

-Similar process with 4110s documented in detailed example here: Cisco 4110 Platform - Upgrade an HA Pair (learnitwithcifelli.com)

HTH!

[laurathaqi]

Hi @Mike.Cifelli 

The example you shared does do the FXOS upgrade first and then after that does the the Firmware upgrade. Is that the order that should be applied? 

I have seen a video that does do the Firmware first, and then the FXOS second! Does the order play role in this usecase? 

Looking forward to hearing back from you. 

Thank you,

Laura 

[Mike.Cifelli]

@laurathaqi 

The example you shared does do the FXOS upgrade first and then after that does the the Firmware upgrade. Is that the order that should be applied? 

-If needing to everything this is the order I have done in the past and was advised to do via working with TAC (worked perfectly fine with no issues/outages):

1. Upgrade Firepower Management Center (FMC) first
2. Upgrade Firepower Extensible Operating System (FXOS) on standby 4110 chassis
3. Upgrade firmware via CLI on standby 4110 chassis
4. Failover to the secondary 4110 after FXOS is upgraded
5. Upgrade Firepower Extensible Operating System (FXOS) on primary 4110 chassis
6. Upgrade firmware via CLI on standby 4110 chassis
7. Upgrade Firepower Threat Defense (FTD) via FMC

@Marvin Rhoads shared some valuable resources that should help too.  HTH & good luck!

[laurathaqi]

Hi @Marvin Rhoads @Mike.Cifelli 

Thank you for the much valuable information provided. 

I have one last question left. How do I do the Upgrade of FTD Logical devices which are in a Cluster(Active/Active mode). I just found out that the Datacenter contexts having FTD Logical Devices are both Active/Active in a Cluster mode. However, having an issue on finding guides for this! 

Looking forward to hearing from you. 

Thank you,

Laura

[AneudyLake502]

That is correct.

Backup the chassis manager configuration prior to updating the FXOS. Also ensure the FXOS version is compatible with the Logical App you choose; study the Firepower Compatibility matrix. Ensure you are compatible for FCM, FXOS, and FTD versions on the targeted FXOS.

Also there is a field notice on a particular condition where FXOS 2.10+ requires and ROMMON upgrade.

[laurathaqi]

Hi @AneudyLake502 

Thank you for your valuable feedback. Do you have a guide on where I can check the ROMMON Upgrade process, suggestions, troubleshooting please? 

Thank you,

Laura

[Marvin Rhoads]

@laurathaqi it's not rommon on a Firepower appliance but rather firmware. The firmware release notes have complete instructions on how to upgrade and verify:

https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/firmware-upgrade/fxos-firmware-upgrade.html

The relevant field notice is here:

https://www.cisco.com/c/en/us/support/docs/field-notices/720/fn72077.html

..and the overall FXOS upgrade guide is here:

https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/upgrade/b_FXOSUpgrade/upgrade_fxos_only_on_the_firepower_4100_9300_chassis.html

Note that for 1010, 1100 series and 2100 series appliances with FTD, the firmware and FXOS software is bundled into the device software package.

[laurathaqi]

Hi all, 

Thank you for the valuable information shared with me so far. 

One last question I do have and I think am setup with the preparations. 

How do you act, in regards the order of the components upgrade, when you have HA and Cluster in one place. 

What I mean is following:

I have Active/Passive setup in the Edge firewall and Active/Active setup for the DataCenter firewall. These are distributed in two physical machines as following of Firepower 4112 as following: 

1. First physical machine has: Active Edge logical device and Active DataCenter logical device,

2. The second psychical machine has Passive Edge logical device and Active Datacenter logical device. 

Now this is the case were I have High availability setup in the Edge Firewalls, and Cluster setup in the DataCenter Firewalls!

Now the plan is to start the upgrade process with the passive FXOS node that contains the Active Datacenter and Passive Edge firewalls(logical devices). This will leave the traffic to go through the first machine, the one that has both Active Edge and Active Datacenter firewall. Here I noted that I need to make sure that the FXOS I start the upgrade with must not be the master one. And then after this machines FXOS and firmware is upgraded, I proceed with the second machine, by switching roles on FMC. 

I want to ask about your thought if there is something I need to consider during this process with mixed setups. As on this Usecase, the upgrade plan is to act based on the FXOS and FTD HA Upgrade Documentation, but in real, I have HA and Cluster modes on my firewalls. 

Looking forward to hearing from your toughts. 

Best,

Laura

[Sheraz.Salim · Accepted solution]

Now the plan is to start the upgrade process with the passive FXOS node that contains the Active Datacenter and Passive Edge firewalls(logical devices). This will leave the traffic to go through the first machine, the one that has both Active Edge and Active Datacenter firewall. Here I noted that I need to make sure that the FXOS I start the upgrade with must not be the master one. And then after this machines FXOS and firmware is upgraded, I proceed with the second machine, by switching roles on FMC. 

Correct

I want to ask about your thought if there is something I need to consider during this process with mixed setups. As on this Usecase, the upgrade plan is to act based on the FXOS and FTD HA Upgrade Documentation, but in real, I have HA and Cluster modes on my firewalls.

In your case you running HA in one instance and Cluster with Active/Active in other instance. your approach above mentioned is right. as your Master firewall in Active/Active resides in primary Firewall unit (Physical unit).  

When the secondary unit appliance will reboot for upgrade purpose node in the cluster fails, the connections hosted by that node are seamlessly transferred to other nodes (in your case Primary Appliance); state information for traffic flows is shared over the control node's cluster control link. If the control node fails, then another member of the cluster with the highest priority (lowest number) becomes the control node. The FTD automatically tries to rejoin the cluster, depending on the failure event.