ASA 5545X & Firepower Issues

[philipspe]

This is my first time posting here, so bear with me.

Our company runs ASA5545X with Firepower in each of our 2 data centers. For the last 2 years, we have been having an ongoing issue where they stop passing traffic. In the last couple months, it has gotten really bad and happens sometimes multiple times a week requiring us to manually failover to restore services. We have opened multiples tickets with TAC and they don't ever find anything really that points to an issue. We have been instructed to go through multiple code upgrades but issue continues. Most recently this week we have upgraded the SFR's to 6.6.7 and the ASA is at 9.8.4(44). From what we can tell, it seems to be the SFR's causing the issue but I can't confirm anything. When it happens , I can ping the outside interface from our outside polling solution 24x7. From the ASA and our internet router we can ping out to google. You just can't ping from inside the network out or make it past the firewall from outside. Has anyone experienced this kind of issue? It's affecting both data centers and we have 2 units per data center. 

[TODavies]

We are running 6.6.7 and continued to suffer issues until we optimized our snort policies. We had multiple intrusion polices and so combined them all into one policy, then applied this single policy to the rules that required it. There have been no further issues since doing this. Geolocation and snot updates are enabled although we don't have the option enabled to deploy to the target devices immediately after an update is downloaded, this is done at the next manual policy deployment.

Hope this helps!

[TODavies]

I might have spoken too soon, we upgrade the FMC to 7.0.4 and after the first policy deployment to the SFR modules running 6.6.7 this issues has reoccurred. Case logged with TAC.

[philipspe]

Its crazy! It's almost like if you getting it running well, you're doomed if you do another deployment to the SFR's whether it be Geo DB update or VDB update. Cisco has dropped the ball and has yet to provide a solution for us. The latest from our ongoing TAC case is they have released to us VDB 362 which I was told hasn't been released to general yet, so we are going to try that and take off monitor only mode to see if that helps. 

[TODavies]

Thanks for the info, let me know how you get on. We have just received the same message from TAC. - Roll back to VDB 356 (or earlier) or install VDB 362 (VDB-lite). BugID CSCwd55058

[MHM Cisco World]

can you share
show asp drop 
before and after issue arise  

[geocoles]

We have the same problem.  Pair of 5525x's with Firepower. We may go a day or may go a month, but the symptom continues, forcing us to fail over to recover. I too have worked with TAC and have not been able to resolve. We do know it has to do with the SFR's because we have a couple subnets that don't go through the SFR's and they continue to work when the processed subnets stop. 

[Marius Gunnerud]

I have had this issue at a client a few years ago on ASA5585x with SFR module.  We ended up migrating to FTD4110 after which the problem solved.

I also had a TAC case on this and we came to the conclusion it had to do with logging.  We had around 700 rules and all of then had logging enabled.  Solution was to, of course, disable logging on the rules, which was not desired hence the migration to new hardware.

[philipspe]

I've heard this a few times about logging possibly being the issue. We only have 23 rules on ours and 3 intrusion policies which are exactly the same. Running prevention balanced/security. 

[philipspe]

Yeah, we know it's the SFR's because if we fail over or place in monitor mode, it immediately fixes the issue. It's so unstable it has crippled our company. My upper management has been so put out with this and no fix from Cisco that we are going to be forced to go to Fortinet or Palo at this point. We're paying high price for Smartnet and there's no fix being given.