IPS system message problem

[Michael Soliman]

I have IPS 4260 has the last IOS version 7.0(5)E4 and when I run diagnostic report I have the following messages

08Aug2011 13:34:15.593 0.000 sensorApp[510] sensorApp/E transmitPacket: Error TX  Queue full, no lost buf yet16693 if = 0

08Aug2011 13:34:15.593 0.000  sensorApp[510] sensorApp/E transmitPacket: Error TX Queue full, no lost buf  yet24108 if = 0

08Aug2011 13:34:15.594 0.001 sensorApp[510] sensorApp/E  transmitPacket: Error TX Queue full, no lost buf yet39703 if = 0

08Aug2011  13:34:15.594 0.000 sensorApp[510] sensorApp/E transmitPacket: Error TX Queue  full, no lost buf yet15644 if = 0

08Aug2011 13:34:15.594 0.000 sensorApp[510]  sensorApp/E transmitPacket: Error TX Queue full, no lost buf yet38045 if =  0

08Aug2011 13:34:15.595 0.001 sensorApp[510] sensorApp/E transmitPacket:  Error TX Queue full, no lost buf yet19080 if = 0

08Aug2011 13:34:15.595 0.000  sensorApp[510] sensorApp/E transmitPacket: Error TX Queue full, no lost buf  yet31928 if = 0

08Aug2011 13:34:15.595 0.000 sensorApp[510] sensorApp/E  transmitPacket: Error TX Queue full, no lost buf yet40998 if = 0

08Aug2011  13:34:15.596 0.001 sensorApp[510] sensorApp/E transmitPacket: Error TX Queue  full, no lost buf yet18245 if = 0

08Aug2011 13:34:15.596 0.000 sensorApp[510]  sensorApp/E transmitPacket: Error TX Queue full, no lost buf yet44343 if =  0

and that's make the IPS hangging and stop working sometimes ,Does any one has solution for this problem?

[Jennifer Halim]

Sounds like the IPS appliance might have been overloaded hence there is not enough buffer in the transmit Queue.

Here is a bug that contains information on what might be the issue: CSCtc18038

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtc18038

[Michael Soliman]

Hello Jennifer

Actually The IPS IOS version I have is 7.0(5)E4,I believe the problem is solved in this version.

Please get back to me quickly as this is stopping my IPS service and I will be unable to manage the IPS.

[haivrajesh]

Stop the Global corrrelation update and check.

[alexpara72]

Hi.

I have the same problem. But I have to explain a little.

I have two ASA with an AIP-SSM-20 module each. The ASA are in failover configuration. Since this summer, when I begun to manage the IPS modules, I had problems with them because each module data-plane was going down after some time (about 3 days) it was up. I reset them, but they again went down on data-plan. This, obviously, caused the ASA to failover every time the primary module data-plane went down. The situation is the same nowadays.

This is an output from the show failover on the primary ASA:

slot 1: ASA-SSM-20 hw/sw rev (1.0/7.0(5a)E4) status (Up/Down)

I had to shutdown the IPS module on secondary ASA to not have it becoming active.

Looking at the show tech-support on the module, I saw the lines sent on this thread at the firs post from Michael Soliman.

I also looked at the link sent by Jennifer, but the wos no solution in it but only a workaround.

The modules firmware you can see in the line above. Instead the ASA version is 8.0(5)25.

In other investigations I made on the Internet, I saw that some people resolved this issue having the ASA appliance substituted.

Is that the only way to the resolution?

Thanks in advance.

[tiwang]

hi again

Had a similary problem this spring - had to migrate 2 ASA5510 with SSM-10 to 2 brandnew ASA5520 with SSM-20 - while I tested the new setup - simple burn-in test running a week - there I also expirienced that after a few days I suddenly got failover because the SSM20 module failed - got a replacement and they have now been running without problems. But honestly - no idea of what was wrong with the SSM20 module - but I swapped it between the ASA's and the problem followed the SSM module

[alexpara72]

Hi tiwang.

Thanks for your answer.

Just a question: did you replace the module itself or the entire ASA?

My problem is that I have this issue on both modules. For this reason I have to keep one shutdown :O(

I hope there is another solution.

Regards.

[tiwang]

hmm - both modules? anyway - since the ssm module was part of a bundle I got the whole asa box replaced

best regards /ti

[alexpara72]

Hi.

Yes, tiwang, both modules. Anyway, I think I'm going to open a  TAC to Cisco to have the ASAs replaced because I noticed also other  issues. I don't want to get OT now, but I think those modules behave  very strangely. For example, they don't alert for a port scan I did, but  the same scan done against another ASA, in another environment, with  the SSM configured in the same way and with the same firmware, gets  logged immediately.

Moreover, till yesterday I had a simple config to divert traffic  to the IPS: a class map matching an acl of type ip any to any, this  class map called by the global-policy and the service policy applied  globally. In such situation the IPS logged every internal traffic (we've  many vlan on the ASA) and it was tedious going to guess the best filter  to see only what I wanted to see. So, yesterday I decided to remove the  traffic diversion from the global policy creating a new policy and  applying this only on the outside (internet) interface. The result is  that I still don't see any scan made against the firewall or the natted  services and moreover I still can see some (really, not much) packet  logged regarding internal traffic.

This is the current traffic diversion config:

access-list IPS-OUTSIDE extended permit ip any any

!

class-map IPS-Outside

match access-list IPS-OUTSIDE

!

policy-map IPS-Outside-policy

class IPS-Outside

  ips promiscuous fail-open

!

service-policy IPS-Outside-policy interface outside

Anyway, browsing the Internet, I din't find an official  announcement regarding the proplem in this topic (modules going down at  data-plane level) and an official resolution by Cisco.

I only found posts telling that the only resolution was the replacement of the entire ASA.

This is very discouraging.

Thanks a lot.

Regards.