Best Practices for Deploying Configuration Changes
The following are guidelines for deploying configuration changes.
Reliable Management Connection
The management connection between the management center and the device is a secure, TLS-1.3-encrypted communication channel between itself and the device.
You do not need to run this traffic over an additional encrypted tunnel such as Site-to-Site VPN for security purposes. If the VPN goes down, for example, you will lose your management connection, so we recommend a simple management path.
Caution | We recommend against a device's management connection going through a VPN tunnel that terminates on the device itself. If you deploy a configuration change that causes the VPN to go down, the management connection will be disconnected and you will not have any way to recover the configuration without connecting directly to the device. If management traffic exits a VPN-terminating interface, be sure to exclude the management traffic from the VPN tunnel. |
Maximum Concurrent Deployments
You should not deploy to more than 25% of the maximum devices allowed for a management center in the same job. For example, for the FMCv300, the maximum job size should be 75 devices (25% of 300). Concurrent deployment to more devices can cause performance issues.
Deployment of Shared Policies
For best performance, deploy to devices that use the same policies. Create separate deployment jobs for each group of devices that share policies.
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, deployment 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.
Use a Maintenance Window to Lessen the Impact of Traffic Interruptions
We strongly recommend you deploy in a maintenance window or at a time when interruptions will have the least impact.
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 the 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 Devices for more information.