Another SSM 20 performance complaint? Follow-up...

Unanswered Question
Dec 11th, 2008

(I did dig up 5 bug's that might indicate high cpu utilization that you all might be interested in...TAC case next...)



100% CPU usage



CSC jumps to 100% CPU usage, but new connections can be established and

traffic scanned.


CSC-SSM module CPU pegged at 100% usage.



CSC SSM CPU usage at 100% when running 6.1.1569.1 image.



CSC HTTP scanner may have issues with a few websites (e.g., OCLC) or

cause 100% CPU busy.


I can go in to detail if needed but I'd rather ask one upfront question:

I have read several discussions, both here and elsewhere, that say the SSM module's rated performance numbers are far below their published numbers. (e.g. a CSC-SSM-20 in a 5540 is rated at 500 MB of throughput.)

Whether the underperformance is at 50% or 70%, is it a consensus opinion here that these modules under perform their published capabilities ??

-- I am currently seeing behavior that would tend to support this contention --

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Farrukh Haroon Wed, 12/24/2008 - 00:10

IMHO a much better place to complain would be through your local Cisco Account Team.



marcabal Mon, 01/05/2009 - 07:57

Just wanted to clarify something for you.

There are 2 types of SSMs.

The AIP-SSM runs the IPS software, and the AIP-SSMs are what people are typically referring to here in the IPS forum.

The CSC-SSM on the otherhand, is the anti-x module running different software. The CSC-SSMs are only rarely referred to in this forum.

All of the bugs you are referring to are for the CSC-SSM and do not apply to the AIP-SSM.

However, there are other bugs that do affect the AIP-SSM about high CPU usage. But these are often specific situations causing the high CPU usage. It is recommended you run the latest service pack of the major/minor version you are running to ensure you have all of the latest fixes.

There are no Mbps performance numbers for the CSC-SSM in the data sheet. If you are running the CSC-SSM then you need to discuss with your account representative what the performance numbers for the CSC-SSM would be. Do not use the AIP-SSM performance numbers when trying to determine CSC-SSM performance.

The AIP-SSM performance numbers are documented in the Data Sheets, and the 500Mbps througput number you refer to is for the AIP-SSM 20 with in ASA 5540 and not for the CSC-SSM 20.

If it is the AIP-SSM 20 with ASA 5540 that you are concerned with rather than the CSC-SSM 20, then the next post is a further discussion of the performance numbers.

marcabal Mon, 01/05/2009 - 07:58

One thing to understand is that the performance numbers provided in the data sheet specifically state "Up to" the specific Mbps number.

You can read this as stating that in optimal conditions the 5540/AIP-SSM 20 combination can performance "Up to" 500 Mbps.

Which means in most real world situations the performance will actually be lower.

Let me compare this to performance numbers we state for the IPS-4260 and IPS-4270 IPS Appliances.

We have gone to a method of stating 2 different performance numbers for each platform. We have two primary performance tests that are run against the platforms. The first is what we call a Transactional test, and the second is what we call a Media Rich test. The Transaction test is configured to use short lived connections downloading smaller files. The Media Rich test is configured to use longer lived connections downloading larger files.

The IPS-4260 is rated at 1 Gbps for Transactional and 2 Gbps for Media Rich.

The IPS-4270 is rated at 2 Gbps for Transactional and 4 Gbps for Media Rich.

The theory is that most customer networks will fall between these 2 types of traffic and so the REAL performance of the sensors on your network would be somewhere between the Transactional and Media Rich ratings.

(NOTE: There are a few exceptions where the REAL performance may actually fall below the Transactional rating. This usually happens in situations where the customer is running a web server used for higher rates of small transactions than what is simulated in our Transactional performance test. By the same token there are also a few sites where REAL performance is even higher than our Media Rich test because the web sites serves out extremely large files.)

So if you are a typical customer (and not one of the extremes) you would expect performance somewhere between the Transactional rating and the Media Rich rating.

So we've told you what the Transactional and Media Rich ratings are for the Appliances, but you won't find those terms when looking at the Data Sheets for the AIP-SSM combinations.

What you would need to know is that the "Up to" performance numbers documented in the AIP-SSM data sheets is the equivalent of the Media Rich performance test rating.

So the 500Mbps for the AIP-SSM 20 and ASA 5540 is how that combination did in the Media Rich test.

As for the Transactional test ratings, these have not been published for the AIP-SSMs.

However, I can give you some rough estimations.

AIP-SSM 10 => 100 Mbps

AIP-SSM 20 => 200 Mbps

AIP-SSM 40 => 400 Mbps

(Note: these are just rough numbers. The actual performance with the Transactional test will vary depending on the ASA chassis that the AIP-SSM is placed within)

So for your AIP-SSM-20 and ASA 5540 combination you could expect a REAL performance somewhere between the rough 200 Mbps Transactional rating, and the data sheet documented 500 Mbps Media Rich rating. The REAL performance in your network will depend on whether your traffic is more like our Transactional test or more like our Media Rich test.

Here is a link to the White Paper that talks about the 2 tests I mentioned above:

mprescher Mon, 01/05/2009 - 10:19

Yes, understood. Thanks for that clarification. This issue was with the AIP-SSM.

Turns out the answer was, 96-100 percent cpu utilization is normal and the more important indicator of an issue is the inspection utilization rates.

Also, the existence and sizing of the Normalizer buffer and the 4 second wait time, can play a huge role in TCP performance. This performance was really at the root of the initial questions from a performance perspective.


This Discussion