Firepower Threat Defense on ASA - Can't deploy changes to config due to SRU update

[Jonathan Bayless]

I've run into this pretty consistently now. I have an ASA 5506 running Firepower Threat Defense 6.2 Build 362. It seems to work mostly fine (though I have noticed that the Lina process appears to take 100% of a single core of the firewall all the time, no matter what) except a few annoying things.

The most annoying thing is that any change to the configuration basically requires a reboot. I can tell it to deploy the changes but it always says the deployment is queued. When I look at the task list there is an SRU update that is scheduled to run at some point (I have tried changing it to run at different times). As long as that SRU update is in the queue, it prevents the configuration change deployment from running.

I can't see any way to delete that SRU update from the queue and even though it may be hours, days or weeks away from being run, it prevents the configuration deploy from being processed.

So far I have found that if I reboot the firewall it will then allow the config change to deploy. Obviously this is unacceptable.

Any thoughts?

[Jonathan Bayless]

By the way, I think we need a new sub-community. This obviously is not about event analysis but I was forced to pick something and this seemed the least wrong. A community under Firepower for Firepower Threat Defense would be good.

[Veronika Klauzova]

That's very good idea, I don't have privileges to do so, but have reached out already to Support team to see if they can create a new discussion community board called "Firepower Threat Defense". Will keep you posted with progress.

[Veronika Klauzova · Accepted solution]

Hello Jonathan,

regarding your note with high CPU of LINA process, you can find great explanation over here, but long story short this behaviour is expected:

http://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200950-Clarifying-the-Firepower-Threat-Defense.html

When comes to SRU update issue, I do agree that reloading device is not proper way to go around issue. This way process will abort, but it is not good idea in general as it might cause that next SRU update fail if previous one was improperly terminated. It should be investigated why the SRU takes that long at the first place, on low end platform this task takes longer time but definitely it  should not last weeks. When this re-occur, please gather and examine SRU installation log file from CLI perspective: /var/log/sf/sru-2017-05-18-001-vrt/status.log (note change sru folder name per sru that is being installed) - i would be curious to see whether the installation just take that long time or whether it fully hang. But in general I do believe that this issue seems to be better fit for TAC case and live troubleshooting.

Best regards,

Veronika

[Jonathan Bayless]

Thanks for that information, I searched for a good while for information on the lina process but could not find anything helpful.

Since I have now updated the firewall in the last couple of days it seems to be working better. I also redid the schedule of the updates so they are less frequent. I think maybe it was trying to start another update before one could finish. It seems like maybe the 5506-X is not a fast enough platform to really run the FTD software very well. It takes a looooong time for startup if you power cycle it without clean shutdown and updates take ages. It was never meant to run this stuff so it seems like they really shoehorned it in there.