Showing results for 
Search instead for 
Did you mean: 

Deployment failures on SFR via FMC


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[19990]: Remote task failure.  at /usr/local/sf/lib/perl/5.24.4/SF/Synchronize/ line 2376.
94186-Dec  2 01:12:38 SRUC-FMC[19990]:      SF::Synchronize::Transaction::handleParentTaskMessage(HASH(0x558b864534a8), HASH(0x558b883a1520))
94187-Dec  2 01:12:38 SRUC-FMC[19990]:           called at /usr/local/sf/lib/perl/5.24.4/SF/Synchronize/ line 2089
94188-Dec  2 01:12:38 SRUC-FMC[19990]:      SF::Synchronize::Transaction::multiTaskHandler(HASH(0x558b864534a8))
94189-Dec  2 01:12:38 SRUC-FMC[19990]:           called at /usr/local/sf/lib/perl/5.24.4/SF/Synchronize/ line 788
94190-Dec  2 01:12:38 SRUC-FMC[19990]:      SF::Synchronize::Transaction::processFunctions(HASH(0x558b864534a8), "logic")
94241-Dec  2 01:12:38 SRUC-FMC[19990]:                  '-line' => '2376',
94242-Dec  2 01:12:38 SRUC-FMC[19990]:                  '-file' => '/usr/local/sf/lib/perl/5.24.4/SF/Synchronize/',
94243-Dec  2 01:12:38 SRUC-FMC[19990]:                  '-package' => 'SF::Synchronize::Transaction'
94244-Dec  2 01:12:38 SRUC-FMC[19990]:                }, 'Error::SFActionQueueFatal' );
94245-Dec  2 01:12:38 SRUC-FMC[19990]: Setting failure code to device_failure_configuration at /usr/local/sf/lib/perl/5.24.4/SF/UMPD/ line 1009.
94246-Dec  2 01:12:39 SRUC-FMC[19990]: hasActiveSession... at /usr/local/sf/lib/perl/5.24.4/SF/ 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,


0 Replies 0
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers