Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
Deployment fails with "ERROR ERROR: Timeout waiting for snort detection engines to process traffic"
> FTD setup is multi-instance > Applies to SSP Platforms (9300 and 4100) > A detector is deactivated on the FMC > An FTD Software upgrade is performed
Ensure there is FMC and FTD backup before doing upgrade A. To mitigate the issue on FTD standalone or HA deployment, follow these sequence of events before upgrading: 1. Deploy all pending changes. 2. Enable all the disabled application detectors. 3. Upgrade VDB on the FMC and deploy 4. Proceed with the upgrade Note: The last step before the upgrade should only be VDB upgrade/deployment. If it includes policy deployment, it will remove the lua files again despite the appid is/are already enabled. B. To recover if already in a failed state (snort are down):, Standalone Deployment ++++ Upgrade VDB on FMC and then deploy. If already running the latest VDB, delete the following files to force a VDB update. Below is an example from a system running 7.2.4.1 and VDB 374 1. Check the exporter and vdb files. root@FMC:/var/cisco/packages# ls -l total 79684 -rw-r--r-- 1 root root 2375548 Oct 30 20:20 exporter-7.2.4.1-43.tgz -rw-r--r-- 1 root root 1708837 Oct 13 20:02 modules-3281-x86_64.tgz -rw-r--r-- 1 root root 35193370 Oct 30 20:20 vdb-374.tgz 2. Move the files. root@FMC:/var/cisco/packages# mv exporter-7.2.4.1-43.tgz /var/tmp/ root@FMC:/var/cisco/packages# mv vdb-374.tgz /var/tmp 3. Reinstall VDB. install_update.pl /var/sf/updates/ --detach --force 4. Deploy C. Rebooting the failed unit may fix the issue too. Note: Installing VDB manually via FTD's expert mode will result in the following error under 011_check_versions.pl.log because the device is FMC-managed. "VDB install is not supported on this device. at pre/011_check_versions.pl" HA Deployment ++++ *** Try this option if the Standalone process in the primary FMC did not work. With several customers, breaking the HA was not needed and just the process above was enough. *** Break HA via several attempts if possible. Power down the unit that has snort-down if needed to break HA. Afterwards, follow the standalone recovery procedure and then proceed with the upgrade. For the other unit that had snort down, this can be reimaged. ++FTD HA or Cluster setup, where one node is kicked out and in Failed state++ 1. On the FMC, upgrade VDB to the latest version. 2. Trigger a deployment from the FMC. This will ensure the deployment goes to the Active node alone. (In cluster, to all the nodes that are part of the cluster) 3. Once the deployment is completed, resume the high-availability on Failed node using the command "configure high-availability resume" from CLISH (Note: In cluster, use "cluster enable" to join it back)
Note that even a single application detector (example Ultrasurf) being disabled will result into the problem.