cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1125
Views
0
Helpful
3
Replies

ASA-SSC-AIP-5 stops responding, but local session works fine.

BEHowardGRDA
Level 1
Level 1

I have several Cisco ASA 5505s with the ASA-SSC-AIP-5 IPS modules installed.  Some of the IPS sensors are responsive, but others are quite stubborn and unresponsive.  I can reach all of them via the session 1 from the host ASAs SSH terminal or console.  Is this a problem with the rev os software currently installed or is it the modules themselves?  Current loaded rev is 6.2(2).

1 Accepted Solution

Accepted Solutions

Dustin Ralich
Cisco Employee
Cisco Employee

There were multiple (some critical) defects fixed in the 6.2(3)E4 software release that could be the cause(s) here (specifically fixes to both the mainApp and sensorApp processes). A good first step would be to properly reboot ("reset") each module, and after they come back online and are running normally, install the 6.2(3)E4 upgrade package.

Once upgraded, if this behavior persists, please elaborate on "others are quite stubborn and unresponsive"... they are unresponsive to remote management connection attempts (SSH and HTTPS) but you can session into them from their host ASA and issue commands successfully (without error)? How long are they up/online before becoming unresponsive? If you session into one of these modules _when it is unresponsive_ and issue the 'show version' command, are the mainApp and sensorApp processes shown as "Running"?

Software defects aside, the generally-seen cause for sensors going unresponsive is sensor oversubscription. Another thing to keep in mind is that on this particular platform/model (AIP-SSC-5), signature updates can take quite longer to complete than on the more powerful models (which can be perceived as the sensor becoming unresponsive).

View solution in original post

3 Replies 3

Dustin Ralich
Cisco Employee
Cisco Employee

There were multiple (some critical) defects fixed in the 6.2(3)E4 software release that could be the cause(s) here (specifically fixes to both the mainApp and sensorApp processes). A good first step would be to properly reboot ("reset") each module, and after they come back online and are running normally, install the 6.2(3)E4 upgrade package.

Once upgraded, if this behavior persists, please elaborate on "others are quite stubborn and unresponsive"... they are unresponsive to remote management connection attempts (SSH and HTTPS) but you can session into them from their host ASA and issue commands successfully (without error)? How long are they up/online before becoming unresponsive? If you session into one of these modules _when it is unresponsive_ and issue the 'show version' command, are the mainApp and sensorApp processes shown as "Running"?

Software defects aside, the generally-seen cause for sensors going unresponsive is sensor oversubscription. Another thing to keep in mind is that on this particular platform/model (AIP-SSC-5), signature updates can take quite longer to complete than on the more powerful models (which can be perceived as the sensor becoming unresponsive).

Thanks for the reply!  I began upgrading the modules soon after I posted the question.  I still have a couple of sensors that don't respond as expected.  These sensors are on the same VLAN as the others, but do not appear to have consistent network connectivity.  I have verified that the IP/Mask/Gateway are correct.  Pinging from the sensor to the host running CSM, my get 50 to 75% packet loss.  Worst case I will just get these replaced, but I want to verify they are faulty before pursuing that route.

Thanks for the reply!  I began upgrading the modules soon after I posted the question.

You're welcome .

I still have a couple of sensors that don't respond as expected.  These sensors are on the same VLAN as the others, but do not appear to have consistent network connectivity.  I have verified that the IP/Mask/Gateway are correct.  Pinging from the sensor to the host running CSM, my get 50 to 75% packet loss.  Worst case I will just get these replaced, but I want to verify they are faulty before pursuing that route.

That sounds more like an IP conflict or other network problem, not a sensor hardware problem. If the problem occurs even almost immediately after a clean reboot of the sensors, then it sounds more like the IP addresses assigned to these sensor modules are already in-use (or conflicting with something else on the network).

Is the test host (CSM) that you are pinging to on the same VLAN as the sensors' management IP addresses? Or, is there other infrastructure in-place between? If you start a ping from the sensors to their default gateway, do you observe packet loss? What about to another IP address in the same VLAN? Preferrably something connected to the same switch. Also, what is the Inspection Load / Processing Load Percentage on these sensors?

Review Cisco Networking products for a $25 gift card