The following are guidelines for deploying configuration changes.

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.

For Firepower Threat Defense devices, the Inspect Interruption column in the Deploy dialog warns you when deploying might interrupt traffic flow or inspection. You can either proceed with, cancel, or delay deployment; see Restart Warnings for the FTD Devices for more information.

Caution

We strongly recommend you deploy in a maintenance window or at a time when interruptions will have the least impact.

When you deploy, the Inspect Interruption column in the deploy page specifies whether a deployed configuration restarts the Snort process on the Firepower Threat Defense device. When the traffic inspection engine referred to as the Snort process restarts, inspection is interrupted until the process resumes. Whether traffic is interrupted or passes without inspection during the interruption depends on how the device handles traffic. Note that you can proceed with the deployment, cancel the deployment and modify the configuration, or delay the deployment until a time when deploying would have the least impact on your network.

When the Inspect Interruption column indicates Yes and you expand the device configuration listing, the system indicates any specific configuration type that would restart the Snort process with an Inspect Interruption (). When you hover your mouse over the icon, a message informs you that deploying the configuration may interrupt traffic.

The following table summarizes how the deploy page displays inspection interruption warnings.

For information on all configurations that restart the Snort process for all device types, see Configurations that Restart the Snort Process When Deployed or Activated.

On the Deployment page, the Status column provides the deployment status for each device. If a deployment is in progress, then the live status of the deployment progress is displayed, else one of the following statuses is displayed:

• Pending—Indicates that there are changes in the device that are to be deployed.

• Warnings or errors—Indicates that the pre-deployment checks have identified warnings or errors for the deployment, and you have not proceeded with the deployment. You can continue with the deployment if there are any warnings, but not if there are any errors.

  Note	The status column provides the warning or error status only for a single user session on the deployment page. If you navigate away from the page or refresh the page, the status changes to pending.

• Failed—Indicates that the previous deployment attempt failed. Click on the status to view the details.

• In queue—Indicates that deployment is initiated, and the system is yet to start the deployment process.

• Completed—Indicates that deployment has completed successfully.

The Estimate link is available on the Deployment page after you select a device, a policy, or a configuration. Click the Estimate link to get an estimate of the deployment duration. The time duration is a rough estimate (having around 70% accuracy), and the actual time taken for deployment may vary for a few scenarios. Refer to the deployment duration estimate for deployments to a few Firepower Threat Defenses. The estimate is dependable for deployments of up to 20 Firepower Threat Defense devices.

When an estimate is not available, it indicates that the data is not available, since the first successful deployment on the selected device is pending. This situation could occur after the FMC version upgrade or after a fresh installation.

Note	The estimate is incorrect and unreliable for bulk policy changes (in case of bulk policy migrations), and selective deployments because the estimate is based on the heuristic technique.

Deployment notes are custom notes that a user can add as part of the deployment, and the deployment notes are optional.

You can view the deployment notes in the Deployment History page. On the Firepower Management Center menu bar, click Deploy and then select Deployment History to view the Deployment Notes column for each job.

Use the Search option on the Deployment History page to search using job name, device name, user name, status, or deployment notes.

Preview provides a snapshot of all the policy and object changes to be deployed on the device. The policy changes include the new policies, changes in the existing policies, and the deleted policies. The object changes include the added and modified objects which are used in policies. The unused object changes are not displayed because they are not deployed on the device.

On the Deployment page, the Preview column provides a Preview () icon for each listed device. On clicking the preview icon, FMC displays a UI page listing all the policy and object changes. The left pane on the preview page lists all the different policy types that have changed on the device, organized in a tree structure.

The Filter icon ( provided on the Preview page provides an option to filter the policies at the user level and policy level. Click the Filter icon (. Select the policy or user name, or both, and then click Apply to restrict the displayed listing to only the selected items. To view all the pending deployments, ensure that you click the Filter icon and select Reset.

The right pane lists all the additions, changes, or deletions in the policy, or the object selected in the left pane. The two columns on the right pane provide the last deployed configuration settings (in the Deployed Version column) versus the changes that are due for deployment (in the Version on Firewall Management Center column). The last deployed configuration settings are derived from a snapshot of the last saved deployment in the FMC and not from the device. The background colors of the settings are color-coded as per the legend available on the top-right of the page.

The Modified By column lists the users who have modified, or added the configuration settings. At the policy level, the FMC displays all the users who have modified the policy, and at the rule level, the FMC displays only the last user who has modified the rule.

Deployment preview of changes to Security Intelligence, Geolocation, Sinkhole, and File List objects is supported. For an explanation of these and other reusable objects supported in the FMC, see the chapter titled Reusable Objects.

You can download a copy of the change log by clicking the Download as PDF button.

Note

To preview the deploy changes, you require access from the REST API to the FMC. To enable the REST API access, follow the steps in Enabling REST API Access. The preview does not show the reordering of rules across policies. For DNS policies, reordered rules appear in the preview list as rule additions and deletions. For example, moving a rule from position 1 to position 3 in the rule order is displayed as if the rule was deleted from position 1 and added as a new rule in position 3. Similarly, when a rule is deleted, the rules under it are listed as edited rules as they have changed their positions. The changes are displayed in the final order in which they appear in the policy. The preview shows all the default values, even when they are not altered, along with the other configured settings when an interface or a platform settings policy is added for the first time. Similarly, the high availability-related policies and default values for settings are shown, even when they are not altered, in the first preview after a high availability pair is configured or disrupted. Preview is not supported for some objects. Object additions and attribute changes are displayed in the preview only if the objects are associated with any device or interface. Object deletions are not displayed. Preview is not supported for the following policies: High availability Network discovery Network analysis Device settings The change log is not supported on NGIPS devices. User information at rule level is not available for intrusion policies. The FMC displays the username as system for the following operations: Rollback Upgrade FTD backup and restore SRU update LSP update VDB update If you change the FMC name in System > Configuration > Information, the deployment preview does not specify this change, yet it requires deploy.

The Filter icon () provided on the Deployment page provides an option to filter the device listings that are pending deployment. The filter icon provides options to filter the listings based on selected devices and user names. You can use the filter along with the search option to narrow down to the required listing.

Click the filter icon (). Select the device or user name, or both, and then click Apply to restrict the displayed listing to only the selected items. To view all the pending deployments, ensure that you click the filter icon () and select Reset.

Caution

Do NOT push the FMC deployments over a VPN tunnel that is terminating directly on the Firepower Threat Defense. Pushing the FMC deployments can potentially inactivate the tunnel and disconnect the FMC and the Firepower Threat Defense. Recovering the device from this situation can be very disruptive and require executing the disaster recovery procedure. This procedure resets the Firepower Threat Defense configuration to factory defaults by changing manager from FMC to local and configuring the device from beginning. For more information, see Deploying the FMC Policy Configuration over VPN Tunnel.

The FMC allows you to select a specific policy within the list of all the changes on the device that are due for deployment and deploy only the selected policy. Selectively deployment is available only for the following policies:

• Access control policies

• Intrusion policies

• Malware and file policies

• DNS policies

• Identity policies

• SSL policies

• QoS policies

• Prefilter policies

• Network discovery

• NAT policies

• Routing policies

• VPN policies

On the deployment page, after you click Expand Arrow () to view device-specific configuration changes, Policy selection () icon is visible. The policy selection icon allows you to select individual policies or configurations to deploy while withholding the remaining listed changes without deploying them. This option is available only for Firepower Threat Defenses and not for sensors. You can also view the interdependent changes for a certain policy or configuration using this option. The FMC dynamically detects dependencies in-between policies (for example, between an access control policy and an intrusion policy), and between the shared objects and the policies. Interdependent changes are indicated using color-coded tags to identify a set of interdependent deployment changes. When one of the deployment changes is selected, the interdependent changes are automatically selected.

Note

When the changes in shared objects are deployed, the impacted policies should also be deployed along with them. When you select a shared object during deployment, the impacted policies are automatically selected. Selective deployment is not supported for scheduled deployments and deployments using REST APIs. You can only opt for complete deployment of all the changes in these cases. The pre-deployment checks for warnings and errors are performed not only on the selected policies, but on all the policies that are out-of-date. Therefore, the warnings or errors list shows the deselected policies as well. Similarly, the Inspect Interruption column indication on the Deployment page considers all out-of-date policies and not just the selected policies. For information on the Inspect Interruption column, see Restart Warnings for the FTD Devices.

There are certain limitations to selectively deploying policies. Follow the contents in the table below to understand when selective policy deployment can be used.

Caution

Do NOT push the FMC deployments over a VPN tunnel that is terminating directly on the Firepower Threat Defense. Pushing the FMC deployments can potentially inactivate the tunnel and disconnect the FMC and the Firepower Threat Defense. Recovering the device from this situation can be very disruptive and require executing the disaster recovery procedure. This procedure resets the Firepower Threat Defense configuration to factory defaults by changing manager from FMC to local and configuring the device from beginning. For more information, see Deploying the FMC Policy Configuration over VPN Tunnel.

Rollback is a deployment functionality provided to clear the existing deployment on an FTD device and to reconfigure the device with the previously deployed configuration.

After a policy deployment, if the traffic through an FTD is affected in an unintended way, rollback provides an option to revert the device to the earlier state, which existed before the faulty deployment.

When a deployment has gone awry and caused traffic interruption in an unintended way, it is recommended that you should identify the change in the deployment that has caused the condition, and fix it. To know the changes in the previous deployment, choose Deploy > Deployment History, expand the last deployed job, and click the preview icon (). The preview page provides an option to compare deployments, which can be useful to identify specific changes for a deployment compared to a previous deployment. After identifying the change causing the problem, rectify the configuration, and redeploy it on the device. This is the recommended approach. However, if the change causing the problem is unidentifiable, roll back to the last stable deployed version on the device.

After a successful rollback operation, go to Deploy > Deployment, and click the Preview icon next to the rolled back device. View the changes between the rolled back configuration and the current changes in the FMC. Identify the change that has caused the issue and rectify it.

Rollback reverts all the configurations on the device except a few. See the table below for details.

Important

Rollback is a disruptive operation. During this operation, all the existing connections and routes are dropped, and the traffic is disrupted. Rollback removes the current configuration on all the selected FTD devices and reconfigures them with the chosen rollback version. Initiate a rollback during low traffic conditions for optimal performance. Rollback to a particular version can be performed only once. Consecutive rollbacks to the same version is not allowed. However, the same version can be selected for rollback at a later time. You can roll back to any one of the last 10 versions before the currently deployed version. Rollback to versions prior to these are not supported. The rollback icon is greyed out for unsupported versions. Two consecutive rollback operations are not allowed. However, you can rollback again after a deployment. Rollback reverts the configuration only on the selected FTDs. FMC retains all the changes. With the configuration changes retained in the FMC, the devices are marked as out-of-date on the FMC after a rollback operation. To see the changes that are retained in FMC versus the configuration on the device, go to Deploy > Deployment, and click the Preview icon next to the rolled back device. Be cautious of the changes you want to deploy in the first deployment after you have rolled back, as it would be a full deployment, and you will not be able to roll back to the rolled back version again. For FTDs with very large access lists, if the Object Group Search setting is disabled, then the rollback operation may take a longer duration to complete. To verify the Object Group Search setting, go to Devices > Device Management, then select the device and click Edit Advanced Settings.

Note

Rollback is supported only on FTD versions 6.7.0 and above. Rollback is not supported on NGIPS devices. Rollback is supported for Snort3 policies as well. Rollback is not supported if the connection interface between the FMC and the FTD is changed from management to data or vice versa. In Firepower 4100/9300, when interface changes are made from the Firepower Chassis Manager (FCM) in a previous deployment, then sync the interfaces using the FCM before initiating a rollback. Failing to do so can cause traffic interruptions. Independent certificate enrollments are also listed as deployment jobs in the Deployment History page. However, you cannot rollback to these versions. A rollback from a deployment version created after certificate enrolments reverts the certificate associations as well. In the next deployment after a rollback, manually associate the certificates before proceeding with the deployment. Rollback is not supported on the first version after an upgrade of FMC or FTD. For example, if the FMC is upgraded from 6.7.0 to 6.7.0.1, then you will not be able to roll back to any deployment packages associated with 6.7.0. If a deployment for a device with a FlexConfig object configured with a deployment frequency set to Once is rolled back, then you will not be able to redeploy the object even though it is displayed as out-of-date on the Preview page. After a rollback, you will have to manually unassign and then reassign the FlexConfig object to the device before the next deployment.

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.

The discovery feature allows you to monitor network traffic and determine the number and types of hosts (including network devices) on your network, as well as the operating systems, active applications, and open ports on those hosts. You can also configure managed devices to monitor user activity on your network. You can use discovery data to perform traffic profiling, assess network compliance, and respond to policy violations.

In a basic deployment (discovery and simple, network-based access control only), you can improve a device’s performance by following a few important guidelines when configuring its access control policy.

Note	You must use an access control policy, even if it simply allows all traffic. The network discovery policy can only examine traffic that the access control policy allows to pass.

First, make sure your access control policy does not require complex processing and uses only simple, network-based criteria to handle network traffic. You must implement all of the following guidelines; misconfiguring any one of these options eliminates the performance benefit:

• Do not use the Security Intelligence feature. Remove any populated global Block or Do Not Block list from the policy’s Security Intelligence configuration.

• Do not include access control rules with Monitor or Interactive Block actions. Use only Allow, Trust, and Block rules. Keep in mind that allowed traffic can be inspected by discovery; trusted and blocked traffic cannot.

• Do not include access control rules with application, user, URL, ISE attribute, or geolocation-based network conditions. Use only simple network-based conditions: zone, IP address, VLAN tag, and port.

• Do not include access control rules that perform file, malware, or intrusion inspection. In other words, do not associate a file policy or intrusion policy with any access control rule.

• In the Advanced settings for the access control policy, make sure that Intrusion Policy used before Access Control rule is determined is set to No Rules Active.

• Select Network Discovery Only as the policy’s default action. Do not choose a default action for the policy that performs intrusion inspection.

In conjunction with the access control policy, you can configure and deploy the network discovery policy, which specifies the network segments, ports, and zones that the system examines for discovery data, as well as whether hosts, applications, and users are discovered on the segments, ports, and zones.

Disabling discovery if you don't need it (for example, in an IPS-only deployment) can improve performance. To disable discovery you must implement all of these changes:

• Delete all rules from your network discovery policy.

• Use only simple network-based conditions to perform access control: zone, IP address, VLAN tag, and port.

  Do not perform any kind of Security Intelligence, application, user, URL, or geolocation control. Although you can disable storage of discovery data, the system still must collect and examine it to implement those features.

• Disable network and URL-based Security Intelligence by deleting all Block and Do Not Block lists from your access control policy's Security Intelligence configuration, including the default Global lists.

• Disable DNS-based Security Intelligence by deleting or disabling all rules in the associated DNS policy, including the default Global Do-Not-Block List for DNS and Global Block List for DNS rules.

After you deploy, new discovery halts on target devices. The system gradually deletes information in the network map according to your timeout preferences. Or, you can purge all discovery data immediately.