Cisco IPS Ver 7.x problems???

Unanswered Question
May 18th, 2009

Is anyone running the 7.x code on the Cisco IPS yet? Any problems? Turn on the global correlation yet?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
avanzaadmin Tue, 05/19/2009 - 04:55

I run it on two IDSMs and the only thing I've noticed so far is that the modules are more prone to reach max CPU and drop packets than with 6.x. I've yet to have a clear case where an alert has been generated due to poor reputation.



jnommensen Tue, 05/19/2009 - 16:37

Anyone having the same problems with Sig updates crashing the sensor that were present in 6.x? I checked the readme for 7.x and did not see any mention of this bug.

delawarecity Wed, 05/20/2009 - 09:26

Version 7 fixed that problem for me. I can actually turn on auto upgrade and not have to worry about coming in the next day and having the sensor down.

For what it is worth, I have had about 50 packets denied in the last couple of days due to reputation filtering. I also have the Global correlation inspection set to aggresive and haven't had any problems (so far) with false positives that I am aware of.

Good upgrade.

avanzaadmin Thu, 05/21/2009 - 21:50

How are you notified that Global correlation has been triggered? I've been searching my logs for any reference and yet to see any.


clausonna Fri, 05/22/2009 - 07:43

Any news on when 7.0 will be supported in CSM?

I created custom sigs using the Emerging Threats IP lists (RBN, BotCC, SpamHaus DROP) and I'm getting tons of hits. As soon as I can support 7.0 in CSM I'll deploy, but not until then (too many sensors and Group Policies.)

avanzaadmin Tue, 05/26/2009 - 01:14

Ok, but how would this show if your sensor has triggered on global correlation? A rule based on "bad IPs" would, unless I'm missing something, only show if you're accessed by those IPs not if your sensor has reacted in any way.


marcabal Tue, 05/26/2009 - 06:55

You can run "show stat global-correlation" to see if your sensor has been receiving the updates.

If your sensor Has been reeiving updates, then you will want to look in IME Event Monitoring.

There is a column in IME for Reputation. It is this column that gets filled in with a negative number if you have been attacked from IPs in the reputation updates from global correlation.

If you right click on one of these events and select to show all details, then in the middle of the output you can see the reputation and what global correlation adjustments were made to the alert.

In addition in the IME Reports there is a report for Global Correlation that can show you graphically what affect it is having on the number of packets your sensor is denying.

ssearls Tue, 05/26/2009 - 07:00

Hello Marcabal! Since you are from Cisco, Can you shed some light on the high CPU utilization in Version 7.x of the code? Is this expected behavior?

marcabal Tue, 05/26/2009 - 08:43

There is always an expectation of a slight increase in cpu when new features are added to the sensor.

Additional features will require additional processing.

In addition there may be other things in 7.0 besides the new features that may be affecting cpu.

7.0 is based on Engine Update E3. Engine Update E3 had some threading changes that caused increased cpu usage.

7.0 also ships with the latest signatures. Each signature update has the potential of increasing cpu as well because of the additional analysis for the new signatures.

7.0 also has additional bug fixes not yet released in other versions. There is the possibility that these bug fixes may cause additional cpu usage.

So additional cpu usage may comes from

1) new global correlation features

2) E3 changes

3) new signatures

4) new bug fixes

I have not heard of specific issues with cpu usage with 7.0 that weren't seen in earlier versions.

But I have also not been directly tracking 7.0 isues either. So there may be some that I am not aware of.

Also keep in mind that cpu usage is not the best indicator of the sensors monitoring capability. Within "show stat virtualsensor" there is a "Processing Load Percentage" that is a better measure of the current load placed on the sensor.

If you want to run your own tests then these are what I would recommend:

1) Run version 6.2(2)E3 at the latest signature update level, then later upgrade to 7.0(1)E3.

6.2(2)E3 is the best version to compare against 7.0(1)E3. The only differences will be in the new 7.0(1) features and bug fixes.

If there is little difference between 6.2(2)E3 and 7.0(1)E3. Then cpu usage concerns may not be specific to 7.0(1) features or bug fixes, and may instead be because of E3 and/or 6.2 architecture changes that happened.

If there IS a difference between 6.2(2)E3 and 7.0(1)E3, then try the following:

2) Disable the netowrk participation, global correlation, and reputation filter features in the sensor (the new features in 7.0).

If 7.0(1)E3 gets back to similar cpu usage as 6.2(2)E3 then the additional cpu usage is from the new 7.0 features.

If cpu usage for 7.0(1)E3 is still higher than for 6.2(2)E3, then it may then be because of the bug fixes in 7.0(1)E3.

Farrukh Haroon Wed, 05/27/2009 - 04:28

Hello Marcoa

I could not locate the "Processing Load Percentage" parameter in an IDSM running 6.0(5)E3. Is this paramer available only in the newer versions?

Also we are facing the same high cpu issue on four different IDSM-2 modules after the E3 upgrade.

This is the CPU utlization on the two active IDSM-2 now (bundled in the same chassis with etherchannel):

IDSM-2# show statistics host | include Usage

Memory Usage

Usage over last 5 seconds = 95

Usage over last minute = 50

Usage over last 5 minutes = 46

Usage over last 5 seconds = 18

Usage over last minute = 20

Usage over last 5 minutes = 20

IDSM-1# show statistics host | include Usage

Memory Usage

Usage over last 5 seconds = 35

Usage over last minute = 58

Usage over last 5 minutes = 88

Usage over last 5 seconds = 18

Usage over last minute = 29

Usage over last 5 minutes = 37

These are CPU stats from the same sensor(s) captured a few months ago:

CPU Statistics

Usage over last 5 seconds = 0

Usage over last minute = 0

Usage over last 5 minutes = 5

Usage over last 5 seconds = 1

Usage over last minute = 0

CPU Statistics

Usage over last 5 seconds = 0

Usage over last minute = 1

Usage over last 5 minutes = 2

Usage over last 5 seconds = 1

Usage over last minute = 0

Usage over last 5 minutes = 0

I did not make up these statistics, trust me :)

Traffic load is about 1-20 mbps usually. Sometimes reaching till 100 mbps.



marcabal Wed, 05/27/2009 - 10:46

Correct that the Processing Load Percentage is only available in 6.1 and higher sensors, so you won't find it in your 6.0 IDSM-2s.

The E3 changes included a fix to a problem with high latency during low traffic loads. The fix was to have sensorApp check the packet buffers on the driver more often. So the packet could be pulled off the driver queue quicker for analysis instead of waiting for the driver to fill the queue before passing it to sensorApp. This increased checking caused a corresponding increase in cpu usage.

This may or may not be what you are seeing in your cpu usage statistics since E3.

If you are not seeing any packet drops on the interfaces, then it is a good chance that you are just seeing the increased checking of packet buffers.

If, however, you are seeing packet drops in E3 that weren't happening in E2 then there may be something else going on.

Farrukh Haroon Wed, 05/27/2009 - 12:29

Ahh I saw that in the release notes, but thought that was only restricted to the 4270 sensor (and not the IDSM-2).

Anyway thanks a lot for your detailed response.




This Discussion