Data transfer from AWS S3 tcp 443 to on-prem - LINA cpu spikes 20%

[plwalsh]

Hi,
I've noticed when a particular on-prem host downloads a large dataset from AWS S3 using SSL/TLS on tcp 443, my FTD 6.6.5.2 has its LINA CPU spike by 20%-25%. The flow is 800Mbps for several hours. I identifed the traffic and fastpathed it using pre-filter but that made no difference.  If fastpath didn't help then IAB for snort won't either. The LINA cpu is a total mystery -its always high even under modest load, but this 20% spike uses up any apparent spare capacity. I didn't experience any interruption to services but running at 97 to 99% for hours can't be good.

One thought I had is to allow the on-prem host access to internet udp 443 as well as tcp 443 - could that help?

Has anyone experienced anything like this and been able to mitigate?
I am planning to upgrade to the recommended 7.0.5 - maybe that will help.

[Cisco_Virtual_Engineer · Accepted solution]

It's not uncommon for LINA CPU usage to spike during high traffic loads, especially when dealing with SSL/TLS traffic. However, consistently running at 97-99% CPU usage for hours is indeed concerning, as it can potentially lead to performance degradation.

Here are a few suggestions to help mitigate the high LINA CPU usage:

1. **Upgrade to FTD 7.0.5**: As you already mentioned, upgrading to the recommended version might help in resolving any performance-related issues or bugs present in FTD 6.6.5.2.

2. **Allow UDP 443 traffic**: Allowing the on-prem host to access the internet using UDP 443, in addition to TCP 443, could potentially help. QUIC protocol, which is used by some applications and services, uses UDP 443 for faster and more efficient data transfer. However, this may or may not have an impact on the LINA CPU usage, depending on the specific application and traffic patterns.

3. **Optimize SSL/TLS inspection**: If your FTD is configured for SSL/TLS inspection, consider fine-tuning the inspection policies. For example, you can configure SSL/TLS inspection to bypass certain trusted sites or low-risk traffic.

4. **Review Security Policies**: Review your security policies and ensure that only necessary inspections and features are enabled. Disabling unnecessary inspections or features may help in reducing the LINA CPU usage.

5. **Monitor and Analyze Traffic**: Regularly monitor traffic patterns on your network to identify any unusual or excessive traffic that may be causing the high LINA CPU usage. Analyzing traffic patterns can help in identifying potential bottlenecks and optimizing the network configuration.

6. **Consider Scaling**: If your network traffic has grown significantly and consistently, it might be time to consider scaling your FTD deployment. You can either upgrade to a higher-capacity FTD model or deploy multiple FTD devices in a load-balanced configuration to better handle the increased traffic load.

Lastly, it's always recommended to work closely with Cisco TAC for any performance-related issues, as they can provide in-depth analysis and optimization recommendations tailored to your specific environment.

[tvotna · Accepted solution]

It all depends on the hardware platform in use, but 800Mbps flows like this can potentially cause performance issues on any ASA or Firepower platform. Even on high-end multicore appliances each flow is owned and handled by a single CPU core, so single CPU core performance can become a bottleneck, "no buffer" or "overrun" counters will increment as well as dispatch-queue-limit "show asp drop" drops on multicore platforms.

Upgrade to 7.0.5 definitely won't help in this scenario, because this is an architectural limitation of the software.