Best Practices for Deploying Configuration Changes

Deploying the Management Center Policy Configuration over VPN Tunnel

You can deploy the management center policy configuration over a VPN tunnel, only if the deployment is for a device that does not terminate the tunnel. The management center to threat defense management traffic should be its own secure transport SF tunnel and does not need to be over S2S VPN tunnel for any connectivity.

For policy-based VPN tunnel, choose the protected networks on both side to exclude the management center to threat defense management traffic. For route-based VPN tunnel, configure the routing to exclude the management center to threat defense management traffic to the VTI interface.

When you push the management center deployments over the VPN tunnel with the management traffic that is also passing through the tunnel, in the event of any VPN misconfiguration, it inactivates the tunnel and results in disconnecting the management center and the threat defense.

To reinstantiate the tunnel configuration, you can either:

• Remove the sensor from the threat defense and the management center (resulting in losing all of its configuration), and then add the sensor again to the management center.

  Or

• Contact Cisco TAC.

  Note	Reinstantiating the tunnel configuration requires overhauling of the system.

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.

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.

For 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 Threat Defense Devices for more information.

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 management center.