This section describes device and traffic behavior when you upgrade a Firepower 9300 chassis with FTD.
Firepower 9300 Chassis: FXOS Upgrade
Upgrade FXOS on each chassis independently, even if you have inter-chassis clustering or high availability pairs configured.
How you perform the upgrade determines how your devices handle traffic during the FXOS upgrade.
Table 9. Traffic Behavior During FXOS Upgrade
Deployment
|
Method
|
Traffic Behavior
|
Standalone
|
—
|
Dropped.
|
High availability
|
Best Practice: Update FXOS on the standby, switch active
peers, upgrade the new standby.
|
Unaffected.
|
Upgrade FXOS on the active peer before the standby is finished
upgrading.
|
Dropped until one peer is online.
|
Inter-chassis cluster (6.2+)
|
Best Practice: Upgrade one chassis at a time so at least
one module is always online.
|
Unaffected.
|
Upgrade chassis at the same time, so all modules are down at some
point.
|
Dropped until at least one module is online.
|
Intra-chassis cluster (Firepower 9300 only)
|
Hardware bypass enabled: Bypass: Standby
or Bypass‑Force. (6.1+)
|
Passed without inspection.
|
Hardware bypass disabled: Bypass:
Disabled. (6.1+)
|
Dropped until at least one module is online.
|
No hardware bypass module.
|
Dropped until at least one module is online.
|
Standalone FTD Device: Firepower Software Upgrade
Firepower devices/security modules operate in maintenance mode while they upgrade.
Entering maintenance mode at the beginning of the upgrade causes a 2-3 second
interruption in traffic inspection. Interface configurations
determine how a standalone device handles traffic both then and during the upgrade.
Table 10. Traffic Behavior During Firepower Software Upgrade: Standalone FTD
Device
Interface Configuration |
Traffic Behavior |
Firewall interfaces
|
Routed or switched including EtherChannel, redundant,
subinterfaces.
Switched interfaces are also known as bridge group or transparent
interfaces.
|
Dropped.
|
IPS-only interfaces
|
Inline set, hardware bypass force-enabled: Bypass:
Force (6.1+).
|
Passed without inspection until you either disable hardware
bypass, or set it back to standby mode.
|
Inline set, hardware bypass standby mode: Bypass:
Standby (6.1+).
|
Dropped during the upgrade, while the device is in maintenance
mode. Then, passed without inspection while the device completes
its post-upgrade reboot.
|
Inline set, hardware bypass disabled: Bypass:
Disabled (6.1+).
|
Dropped.
|
Inline set, no hardware bypass module.
|
Dropped.
|
Inline set, tap mode.
|
Egress packet immediately, copy not inspected.
|
Passive, ERSPAN passive.
|
Uninterrupted, not inspected.
|
High Availability Pairs: Firepower Software Upgrade
You should not experience interruptions in traffic flow or inspection while upgrading
the Firepower software on devices in high availability pairs. To ensure continuity
of operations, they upgrade one at a time. Devices operate in maintenance mode while
they upgrade.
The standby device upgrades first. The devices switch roles, then the new standby upgrades. When the upgrade completes, the
devices' roles remain switched. If you want to preserve the active/standby roles, manually switch the roles before you upgrade.
That way, the upgrade process switches them back.
Clusters: Firepower Software Upgrade
You should not experience interruptions in traffic flow or inspection while upgrading
the Firepower software on devices in Firepower Threat Defense clusters. To ensure continuity of operations, they upgrade one at a time. The
data security module or modules upgrade first, then the control module. Security
modules operate in maintenance mode while they upgrade.
During the control security module upgrade, although traffic inspection and handling
continues normally, the system stops logging events. Events for traffic processed
during the logging downtime appear with out-of-sync timestamps after the upgrade is
completed. However, if the logging downtime is significant, the system may prune the
oldest events before they can be logged.
![](https://www.cisco.com/content/dam/en/us/td/i/templates/note.gif) Note |
Upgrading an inter-chassis cluster from Version 6.2.0, 6.2.0.1, or 6.2.0.2 causes
a 2-3 second traffic interruption in traffic inspection when each module is
removed from the
cluster.
|
High Availability and Clustering Hitless Upgrade Requirements
Performing hitless upgrades have the following additional requirements.
Flow Offload: Due to bug fixes in the flow offload feature, some combinations
of FXOS and FTD do not support flow offload; see the Cisco Firepower Compatibility Guide. To perform a hitless upgrade in a high availability or clustered deployment, you
must make sure you are always running a compatible combination.
If your upgrade path includes upgrading FXOS to 2.2.2.91, 2.3.1.130, or later (including FXOS 2.4.1.x, 2.6.1.x, and so on)
use this path:
1. Upgrade FTD to 6.2.2.2 or later.
2. Upgrade FXOS to 2.2.2.91, 2.3.1.130, or later.
3. Upgrade FTD to your final version.
For example, if you are running FXOS 2.2.2.17/FTD 6.2.2.0, and you want to upgrade to FXOS 2.6.1/FTD 6.4.0, then you can:
1. Upgrade FTD to 6.2.2.5.
2. Upgrade FXOS to 2.6.1.
3. Upgrade FTD to 6.4.0.
Version 6.1.0 Upgrades: Performing a hitless upgrade of an FTD high
availability pair to Version 6.1.0 requires a preinstallation package. For more
information, see Firepower System Release Notes Version 6.1.0 Preinstallation
Package.
Traffic Behavior During Deployment
You deploy configurations multiple times during the upgrade process. Snort typically restarts during the first deployment
immediately after the upgrade. It does not restart during other deployments unless, before deploying, you modify specific
policy or device configurations. For more information, see Configurations that Restart the Snort Process when Deployed or Activated in the Firepower Management Center Configuration Guide.
When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, restarting
the Snort process interrupts traffic inspection on all Firepower devices, including those configured for HA/scalability. Interface
configurations determine whether traffic drops or passes without inspection during the interruption.
Table 11. Traffic Behavior During FTD Deployment
Interface Configuration
|
Traffic Behavior
|
Firewall interfaces
|
Routed or switched including EtherChannel, redundant,
subinterfaces.
Switched interfaces are also known as bridge group or transparent
interfaces.
|
Dropped.
|
IPS-only interfaces
|
Inline set, Failsafe enabled or disabled
(6.0.1–6.1).
|
Passed without inspection.
A few packets might drop if Failsafe is
disabled and Snort is busy but not down.
|
Inline set, Snort Fail Open: Down:
disabled (6.2+).
|
Dropped.
|
Inline set, Snort Fail Open: Down: enabled
(6.2+).
|
Passed without inspection.
|
Inline set, tap mode.
|
Egress packet immediately, copy not inspected.
|
Passive, ERSPAN passive.
|
Uninterrupted, not inspected.
|