Policy Deployment
After you configure your deployment, and any time you change that configuration, you must deploy the changes to affected devices. You can view deployment status in the Message Center.
Deploying updates the following components:
-
Device and interface configurations
-
Device-related policies: NAT, VPN, QoS, platform settings
-
Access control and related policies: DNS, file, identity, intrusion, network analysis, prefilter, SSL
-
Network discovery policy
-
Intrusion rule updates
-
Configurations and objects associated with any of these elements
You can configure the system to deploy automatically by scheduling a deploy task or by setting the system to deploy when importing intrusion rule updates. Automating policy deployment is especially useful if you allow intrusion rule updates to modify system-provided base policies for intrusion and network analysis. Intrusion rule updates can also modify default values for the advanced preprocessing and performance options in your access control policies.
In a multidomain deployment, you can deploy changes for any domain where your user account belongs:
-
Switch to an ancestor domain to deploy changes to all subdomains at the same time.
-
Switch to a leaf domain to deploy changes to only that domain.
Best Practices for Deploying Configuration Changes
The following are guidelines for deploying configuration changes.
Inline vs Passive Deployments
Do not apply inline configurations to devices deployed passively, and vice versa.
Time to Deploy and Memory Limitations
The time it takes to deploy depends on multiple factors, including (but not limited to):
-
The configurations you send to the device. For example, if you dramatically increase the number of Security Intelligence entries you block, deploy can take longer.
-
Device model and memory. On lower-memory devices, deploying can take longer. For example, it can take up to five minutes to deploy to a Firepower 7010, 7020, or 7030 device.
Do not exceed the capability of your devices. If you exceed the maximum number of rules or policies supported by a target device, the system displays a warning. The maximum depends on a number of factors—not only memory and the number of processors on the device, but also on policy and rule complexity. For information on optimizing policies and rules, see Best Practices for Access Control Rules.
Interruptions to Traffic Flow and Inspection During Deploy
When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior and Configurations that Restart the Snort Process When Deployed or Activated.
![]() Caution |
We strongly recommend you deploy in a maintenance window or at a time when interruptions will have the least impact. |
Auto-Enabling Application Detectors
If you are performing application control but disable required detectors, the system automatically enables the appropriate system-provided detectors upon policy deploy. If none exist, the system enables the most recently modified user-defined detector for the application.
Asset Rediscovery with Network Discovery Policy Changes
When you deploy changes to a network discovery policy, the system deletes and then rediscovers MAC address, TTL, and hops information from the network map for the hosts in your monitored networks. Also, the affected managed devices discard any discovery data that has not yet been sent to the Firepower Management Center.
Deploy Configuration Changes
Smart License |
Classic License |
Supported Devices |
Supported Domains |
Access |
---|---|---|---|---|
Any |
Any |
Any |
Any |
Admin/Network Admin/Security Approver |
After you change configurations, deploy them to the affected devices. We strongly recommend that you deploy in a maintenance window or at a time when any interruptions to traffic flow and inspection will have the least impact.
![]() Caution |
When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior and Configurations that Restart the Snort Process When Deployed or Activated. |
Before you begin
-
Review the guidelines described in Best Practices for Deploying Configuration Changes.
-
Be sure all managed devices use the same revision of the Security Zones object. If you have edited security zone objects: Do not deploy configuration changes to any device until you edit the zone setting for interfaces on all devices you want to sync. You must deploy to all managed devices at the same time. See Synchronizing Security Zone Object Revisions.
Procedure
Step 1 |
On the Firepower Management Center menu bar, click Deploy. The Deploy Policies dialog lists devices with out-of-date configurations. The Version at the top of the dialog specifies when you last made configuration changes. The Current Version column in the device table specifies when you last deployed changes to each device. |
Step 2 |
Identify and choose the devices where you want to deploy configuration changes.
|
Step 3 |
Click Deploy. |
Step 4 |
If the system identifies errors or warnings in the changes to be deployed, it displays them in the Errors and Warnings for Requested Deployment window. You have the following choices:
|
What to do next
-
(Optional) Monitor deployment status; see Viewing Deployment Messages.
-
If deploy fails, see Best Practices for Deploying Configuration Changes.
Redeploy Existing Configurations to a Device
Smart License |
Classic License |
Supported Devices |
Supported Domains |
Access |
---|---|---|---|---|
Any |
Any |
Any |
Leaf only |
Admin/Network Admin/Security Approver |
You can force-deploy existing (unchanged) configurations to a single managed device. We strongly recommend you deploy in a maintenance window or at a time when any interruptions to traffic flow and inspection will have the least impact.
![]() Caution |
When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior and Configurations that Restart the Snort Process When Deployed or Activated. |
Before you begin
Review the guidelines described in Best Practices for Deploying Configuration Changes.
Procedure
Step 1 |
Choose . |
Step 2 |
Click edit ( In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch. |
Step 3 |
Click Device. |
Step 4 |
Click edit ( |
Step 5 |
Click Force Deploy ( |
Step 6 |
Click Deploy. The system identifies any errors or warnings with the configurations you are deploying. You can click Proceed to continue without resolving warning conditions. However, you cannot proceed if the system identifies an error. |
What to do next
-
(Optional) Monitor deployment status; see Viewing Deployment Messages.
-
If deploy fails, see Best Practices for Deploying Configuration Changes.
Snort® Restart Scenarios
When the traffic inspection engine referred to as the Snort process on a managed device restarts, inspection is interrupted until the process resumes. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior for more information. Additionally, resource demands may result in a small number of packets dropping without inspection when you deploy, regardless of whether the Snort process restarts.
Any of the scenarios in the following table cause the Snort process to restart.
Restart Scenario |
More Information |
---|---|
Deploying a specific configuration that requires the Snort process to restart. |
Configurations that Restart the Snort Process When Deployed or Activated |
Modifying a configuration that immediately restarts the Snort process. |
|
Traffic-activation of the currently deployed Automatic Application Bypass (AAB) configuration. |
Inspect Traffic During Policy Apply
Inspect traffic during policy apply is an advanced access control policy general setting that allows managed devices to inspect traffic while deploying configuration changes; this is the case unless a configuration that you deploy requires the Snort process to restart. You can configure this option as follows:
-
Enabled — Traffic is inspected during the deployment unless certain configurations require the Snort process to restart.
When the configurations you deploy do not require a Snort restart, the system initially uses the currently deployed access control policy to inspect traffic, and switches during deployment to the access control policy you are deploying.
-
Disabled — Traffic is not inspected during the deployment. The Snort process always restarts when you deploy.
The following graphic illustrates how Snort restarts can occur when you enable or disable Inspect traffic during policy apply.

![]() Caution |
When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior and Configurations that Restart the Snort Process When Deployed or Activated. |
Snort® Restart Traffic Behavior
The following tables explain how different devices handle traffic when the Snort process restarts.
Interface Configuration |
Restart Traffic Behavior |
---|---|
inline: Snort Fail Open: Down: enabled |
passed without inspection |
inline: Snort Fail Open: Down: disabled |
dropped |
routed, transparent (including EtherChannel, redundant, subinterface) Note that Version 6.2.2 does not support the CLI command configure snort preserve-connection {enable | disable} , which, when enabled (the default), allowed existing TCP/UDP connections to pass without inspection. As of Version 6.2.2, packets are dropped unless both the FMC and FTD are running Version 6.2.0.2 or a subsequent 6.2.0.x patch. For more information, see Cisco Firepower Threat Defense Command Reference. |
dropped |
inline: tap mode |
egress packet immediately, copy bypasses Snort |
passive |
uninterrupted, not inspected |
Interface Configuration |
Restart Traffic Behavior |
---|---|
inline: Failsafe enabled or disabled |
passed without inspection A few packets might drop if Failsafe is disabled and Snort is busy but not down. |
inline: tap mode |
egress packet immediately, copy bypasses Snort |
passive |
uninterrupted, not inspected |
routed, switched (7000 and 8000 Series only) |
dropped |
Interface Configuration |
Restart Traffic Behavior |
---|---|
routed or transparent with fail-open |
passed without inspection |
routed or transparent with fail-close |
dropped |
![]() Note |
In addition to traffic handling when the Snort process is down while it restarts, traffic can also pass without inspection or drop when the Snort process is busy, depending on the configuration of the Failsafe option (see Inline Sets on the Firepower System) or the Snort Fail Open Busy option (see Configure an Inline Set). A device supports either the Failsafe option or the Snort Fail Open option, but not both. |
![]() Note |
When the Snort process is busy but not down during configuration deployment, some packets may drop on routed, switched, or transparent interfaces if the total CPU load exceeds 50 percent. |
Configurations that Restart the Snort Process When Deployed or Activated
Deploying any of the following configurations except AAB restarts the Snort process as described. Deploying AAB does not cause a restart, but excessive packet latency activates the currently deployed AAB configuration, causing a partial restart of the Snort process.
Access Control Policy Advanced Settings
-
Deploy when Inspect Traffic During Policy Apply is disabled.
-
Add or remove an SSL policy.
Security Intelligence
Add or delete multiple Security Intelligence whitelist or blacklist networks or network objects. Changes can be to custom or system-provided lists, and whether the Snort process restarts can vary by device, depending on the memory available for inspection.
File Policy
Deploy the first or last of any one of the following configurations; note that while otherwise deploying these file policy configurations does not cause a restart, deploying non-file-policy configurations can cause restarts.
-
Enable or disable Inspect Archives.
-
Take either of the following actions:
-
Enable or disable Inspect Archives when the deployed access control policy includes at least one file policy.
-
Add the first or remove the last file policy rule when Inspect Archives is enabled (note that at least one rule is required for Inspect Archives to be meaningful).
-
-
Enable or disable Store files in a Detect Files or Block Files rule.
-
Add the first or remove the last active file rule that combines the Malware Cloud Lookup or Block Malware rule action with an analysis option (Spero Analysis or MSEXE, Dynamic Analysis, or Local Malware Analysis) or a store files option (Malware, Unknown, Clean, or Custom).
Note that access control rules that deploy these file policy configurations to security zones or tunnel zones cause a restart only when your configuration meets the following conditions:
-
Source or destination security zones in your access control rule must match the security zones associated with interfaces on the target devices.
-
Unless the destination zone in you access control rule is any, a source tunnel zone in the rule must match a tunnel zone assigned to a tunnel rule in the prefilter policy.
Identity Policy
-
When SSL decryption is disabled (that is, when the access control policy does not include an SSL policy), add the first or remove the last active authentication rule.
An active authentication rule has either an Active Authentication rule action, or a Passive Authentication rule action with Use active authentication if passive or VPN identity cannot be established selected.
Network Discovery
-
Enable or disable non-authoritative, traffic-based user detection over the HTTP, FTP, or MDNS protocols, using the network discovery policy.
Device Management
-
Routing: Add a routed interface pair or virtual router to a 7000 or 8000 Series device.
-
VPN: Add or remove a VPN on a 7000 or 8000 Series device.
Caution
The system does not warn you that the Snort process restarts when you add or remove a VPN on a 7000 or 8000 Series device.
-
MTU: Change the highest MTU value among all non-management interfaces on a device.
-
7000/8000 series high availability: Change a high-availability state sharing option. The system does not warn you that the Snort process restarts on the primary and secondary devices.
-
Automatic Application Bypass (AAB): The currently deployed AAB configuration activates when a malfunction of the Snort process or a device misconfiguration causes a single packet to use an excessive amount of processing time. The result is a partial restart of the Snort process to alleviate extremely high latency or prevent a complete traffic stall. This partial restart causes a few packets to pass without inspection, or drop, depending on how the device handles traffic.
Updates
-
System update: Deploy configurations the first time after a software update that includes a new version of the Snort binary or data acquisition library (DAQ).
-
VDB: Deploy configurations the first time after installing a vulnerability database (VDB) .
-
Intrusion rule update: Deploying configurations the first time after importing an intrusion rule update (also known as a Snort Rule Update or SRU) that includes a new or modified shared object rule.
Caution
Intrusion rule updates are cumulative. Any shared object rule that is added or modified since your last update causes a restart when you deploy, even if the current update has no shared object rule changes.
Changes that Immediately Restart the Snort Process
The following changes immediately restart the Snort process without going through the deploy process. How the restart affects traffic depends on how the target device handles traffic. See Snort® Restart Traffic Behavior for more information.
-
Take any of the following actions involving applications or application detectors:
-
Activate or deactivate a system or custom application detector.
-
Delete an activated custom detector.
-
Save and Reactivate an activated custom detector.
-
Create a user-defined application.
A message warns you that continuing restarts the Snort process on all managed devices, and allows you to cancel.
-
-
Create or break a Firepower Threat Defense high availability pair—A message warns you that continuing to create a high availability pair restarts the Snort process on the primary and secondary devices and allows you to cancel.
-
Install a vulnerability database (VDB) update.
-
Restart the Snort process in the 7000 or 8000 Series user interface (System > Configuration > Process)—The system prompts you for confirmation and allows you to cancel.