Cisco ASA 5585-60 in context mode ver. 8.4.4(9)
with SSP-60 IPS using virtual sensors ver. 7.1(4)E4
Host A (linux) runs curl command to download a file from Host B (linux) around 72MB in size. Host A is on a different subnet than host B and they use the Cisco ASA as their default gateway. The ASA firewall is a virtual context using a virtual sensor with default signatures enabled, no customization other than the mgmt ip address we defined several months back.
Problem: With IPS enabled we note a 90% decrease in throughput when running the same command versus with IPS on. To put a number on it, we usually get 33-34MB (yes that's MegaBytes) per second with IPS off. When IPS is enabled we're lucky to get 3MBps. I've created an ACL to redirect ONLY this traffic to the IPS and tracked which IPS signatures we're being hit while we ran the download. Turns out NONE of the signature hit counts are increasing. Im gathering this info by refreshing the statistics in IDM and reviewing hit counters over a 30 minute period. So what else can we check for here? If no signatures are being hit, what else can I check to determine the drop in throughput. With the biggest IPS you make I wouldn't expect to see this big of a drop here.
Some other points to note here:
SCP copies in the same direction show no problem with IPS on or off, I suspect its due to the fact that the IPS cannot see this traffic so it ignores it. We also note that if we change from port 80 to say port 8067 we DO NOT see the issue either. If we do use 8080 the problem does present itself. Very strange one.
Ive attached the Diag report to maybe help with this. Any help would be appreciated!
I also have a similar situation, The bug tool kit does not seem to give us any way ahead. we do not have a work aroud
or an release to Upgrade to. and also the bug severitiy is set as 3-Moderate which in not so In my case. The complete Intenet traffic is effected. we are using an IPS 4260 running 7.1(4)E4. If you recommend a downgrade, untill a fix is not availiblle, Please suggest which version to go to.
I did follow-up on this, and the bug you mentioned seems to be very clear that one of the 24 CPU's would peg at 100% during this flow. However that is not the case in our situation. I may see a spike on one of the CPU's up to 50-60% during my http GET transaction which I allow to run for 2 minutes. But nowhere near 100% as the bug suggets.