Guidelines and Limitations for FlexConfig

If you make a mistake in the FlexConfig policy, the system will roll back all changes included in the deployment attempt that includes the failed FlexConfig. Because rollback due to a failed deployment includes clearing the configuration, this can be disruptive to your network. Consider timing deployments that include FlexConfig changes to non-business hours. Also, consider isolation the deployment so it includes just FlexConfig changes, and no other policy updates.

When you use the VxLAN_Make_VNI object, you must deploy the same FlexConfig to all units in a cluster or high availability pair before you form the cluster or high availability pair. The Management Center requires the VXLAN interfaces to match on all devices before forming the cluster or high availability pair.

If you configure any service that applies to connections, such as SIP inspection, go to the device CLI and enter the clear conn command to clear connections. When the connections are rebuilt, the new configuration is applied to the sessions.

QoS rules and service policy rules (in the access control policy) are translated to commands on the firewall. This includes creating policy maps. There can be only one policy map per interface. The system automatically combines QoS and service policy configurations in a single policy map per interface.

However, you can also create policy maps manually using FlexConfig. For lower-end firewalls, such as the Secure Firewall 3100, you can create up to 64 policy maps in the configuration. For more powerful firewalls, such as the Firepower 4100, you can create up to 128. Be careful not to exceed this limit, or deployment will fail. You can view the device configuration from the CLI or use the deployment transcript to see how rules are translated to commands.