We are seeing intermittent deployment failures on 3x SA5516-X with SFR. They are on 7.0.1 with Snort version 2 currently.
The error witnessed during failures in the FMC UI is:
"Deployment failed due to configuration error . If problem persists after retrying, contact Cisco TAC."
The deployment logs I've seen in relation to that error don't seem to point to any huge smoking gun:
94185-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: Remote task failure. 10.10.1.253. at /usr/local/sf/lib/perl/5.24.4/SF/Synchronize/Transaction.pm line 2376.
94186-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: SF::Synchronize::Transaction::handleParentTaskMessage(HASH(0x558b864534a8), HASH(0x558b883a1520))
94187-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: called at /usr/local/sf/lib/perl/5.24.4/SF/Synchronize/Transaction.pm line 2089
94188-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: SF::Synchronize::Transaction::multiTaskHandler(HASH(0x558b864534a8))
94189-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: called at /usr/local/sf/lib/perl/5.24.4/SF/Synchronize/Transaction.pm line 788
94190-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: SF::Synchronize::Transaction::processFunctions(HASH(0x558b864534a8), "logic")
--
94241-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: '-line' => '2376',
94242-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: '-file' => '/usr/local/sf/lib/perl/5.24.4/SF/Synchronize/Transaction.pm',
94243-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: '-package' => 'SF::Synchronize::Transaction'
94244-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: }, 'Error::SFActionQueueFatal' );
94245-Dec 2 01:12:38 SRUC-FMC ActionQueueScrape.pl[19990]: Setting failure code to device_failure_configuration at /usr/local/sf/lib/perl/5.24.4/SF/UMPD/Transaction.pm line 1009.
94246-Dec 2 01:12:39 SRUC-FMC ActionQueueScrape.pl[19990]: hasActiveSession... at /usr/local/sf/lib/perl/5.24.4/SF/Auth.pm line 280.
Looking further at the health status of the sensors however, I can see that they are complaining of 'Configuration Memory Allocation' with - 'Deployed configurations are too large. Your deployed configurations require more memory than the system can allocate. Re-evaluate your configuration. Most often you can reduce the number or complexity of access control rules or intrusion policies. See the online help to learn best practices for access control.'
I had seen some indication that a migration to Snort 3 does improve efficiency but wasn't sure if that was a direct correlation to policy compression and moreover, the error we are encountering.
I've passed this via TAC but wondered if this has been encountered before or logged in an existing bug that's been logged and resolved.
Any helps is very much appreciated. Thanks,
David
