Traffic Flow and Inspection
Schedule maintenance windows when upgrade will have the least impact, considering any effect on traffic flow and inspection.
Traffic Flow and Inspection for Firewall Threat Defense Upgrades
Software Upgrades for Standalone Devices
Devices 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.
|
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. For bridge group interfaces on the ISA 3000 only, you can use a FlexConfig policy to configure hardware bypass for power failure. This causes traffic to drop during software upgrades but pass without inspection while the device completes its post-upgrade reboot. |
|
IPS-only interfaces |
Inline set, hardware bypass force-enabled: Bypass: Force |
Passed without inspection until you either disable hardware bypass, or set it back to standby mode. |
|
Inline set, hardware bypass standby mode: Bypass: Standby |
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 |
Dropped. |
|
|
Inline set, no hardware bypass module. |
Dropped. |
|
|
Inline set, tap mode. |
Egress packet immediately, copy not inspected. |
|
|
Passive, ERSPAN passive. |
Uninterrupted, not inspected. |
|
Software Upgrades for High Availability and Clustered Devices
You should not experience interruptions in traffic flow or inspection while upgrading high availability or clustered devices. For high availability pairs, the standby device upgrades first. The devices switch roles, then the new standby upgrades.
For clusters, the data security module or modules upgrade first, then the control module. 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.
Note that hitless upgrades are not supported for single-unit clusters. Interruptions to traffic flow and inspection depend on interface configurations of the active unit, just as with standalone devices.
Software Revert (Major/Maintenance Releases)
You should expect interruptions to traffic flow and inspection during revert, even in a high availability/scalability deployment. This is because revert is more successful when all units are reverted simultaneously. Simultaneous revert means that interruptions to traffic flow and inspection depend on interface configurations only, as if every device were standalone.
Software Uninstall (Patches)
For standalone devices, interruptions to traffic flow and inspection during patch uninstall are the same as for upgrade. In high availability/scalability deployments, you must explicitly plan an uninstall order that minimizes disruption. This is because you uninstall patches from devices individually, even those that you upgraded as a unit.
Traffic Flow and Inspection for Chassis Upgrades
Upgrading FXOS reboots the chassis. For FXOS upgrades to Version 2.14.1+ that include firmware upgrades, the chassis reboots twice—once for FXOS and once for the firmware. This includes Version 7.4.1+ chassis upgrades for the Secure Firewall 3100/4200 in multi-instance mode.
Even in high availability or clustered deployments, you upgrade FXOS on each chassis independently. To minimize disruption, upgrade one chassis at a time; see Upgrade Order.
|
Firewall Threat Defense Deployment |
Traffic Behavior |
Method |
|---|---|---|
|
Standalone |
Dropped. |
— |
|
High availability |
Unaffected. |
Best Practice: Update FXOS on the standby, switch active peers, upgrade the new standby. |
|
Dropped until one peer is online. |
Upgrade FXOS on the active peer before the standby is finished upgrading. |
|
|
Inter-chassis cluster |
Unaffected. |
Best Practice: Upgrade one chassis at a time so at least one module is always online. |
|
Dropped until at least one module is online. |
Upgrade chassis at the same time, so all modules are down at some point. |
|
|
Intra-chassis cluster (Firepower 9300 only) |
Passed without inspection. |
Hardware bypass enabled: Bypass: Standby or Bypass‑Force. |
|
Dropped until at least one module is online. |
Hardware bypass disabled: Bypass: Disabled. |
|
|
Dropped until at least one module is online. |
No hardware bypass module. |
Traffic Flow and Inspection when Deploying Configurations
Snort typically restarts during the first deployment immediately after upgrade. This means that for Firewall Management Center upgrades, Snort could restart on all managed devices. Snort does not restart after subsequent deployments unless, before deploying, you modify specific policy or device configurations.
Restarting the Snort process briefly interrupts traffic flow and inspection on all devices, including those configured for high availability/scalability. Interface configurations determine whether traffic drops or passes without inspection during the interruption. When you deploy without restarting Snort, resource demands may result in a small number of packets dropping without inspection.
|
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. |
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. |
Dropped. |
|
|
Inline set, Snort Fail Open: Down: enabled. |
Passed without inspection. |
|
|
Inline set, tap mode. |
Egress packet immediately, copy not inspected. |
|
|
Passive, ERSPAN passive. |
Uninterrupted, not inspected. |
|

)
Feedback