Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Users might experience few discrepancies in Search results. We are working on this on our side. We apologize for the inconvenience it may have caused.
New Member

IDSM Not Responding Error

Anyone seen this before and/or have suggestions on this problem? When I try to SSH into the IDSM, or session in from the switch I get the following out put. I have a couple of both 4.1 and 3.0 IDSM's giving me this error. I spews out that error, and disconnects your session. I have reset modules via the switch. I first noticed it when monitor console had "Not Connected" under the monitor sessions screen.




6509-Sw1> (enable) session 6

Trying IDS-6...

Connected to IDS-6.

Escape character is '^]'.

login: ********

Password: ********

Error: Cannot communicate with system processes. Please contact your system administrator.

6509-Sw1> (enable)





Cisco Employee

Re: IDSM Not Responding Error

On a version 4.x IDSM2 this error will ocurr when the mainApp process (this is the system processes in the error) on the sensor is not communicating with the CLI.

I have seen this a few times with version 4.0 and 4.1 on the IDSM-2.

Please contact the TAC if you have not already done so. There a few issues being tracked which have similar symptoms. Engineering has put together an engineering build to address most of these issues, and the TAC is providing this to customers when it is determined that they are running into these problems. In addition these same fixes are being put into a service pack that is currently being tested.

If your issue is not resolved by the TAC then have the TAC escallate your TAC case to get it looked at by TAC personnel more focused on the Security Products. They will be able to better diagnose the issue, and determine if you need to apply the engineering fix until the service pack is released.

Just so you know:

The majority of TAC calls are basic question and answer types. How can I upgrade this or configure that. So when a user calls the TAC they are first sent to engineers than can answer these standard questions. Quite often these initial engineers are from outsourced companies or contractors or new TAC engineers who have some working experience with the products but not the detailed knowledge necessary to troubleshoot some of the major issues. When a more difficult question comes in or a major bug, then the initial TAC engineer can escallate the TAC case to an internal TAC team that specializes in that product area. In the case of major issues you can ask the initial TAC engineer to escallate your case to the TAC team specializing in Security Products.

As for version 3.0 on the older IDSM-1. I am not aware of any similar issues on the older 3.0 version that have not already been addressed in the released service packs.

The version 3.0 IDSM-1 runs a completely different code base than the 4.x IDSM-2 modules.

So a similar problem on 3.0 should be tracked separately in a separate TAC case to keep from confusing the 2 issues.

The error may be similar in version 3.0, but is likely being seen for a completely different reason. Asking about both the version 3.0 IDSM-1 and the 4.1 IDSM2 in the same TAC call could confuse things. It would be best to open 2 cases, one for each version.

Other troubleshooting suggestions:

For both version 4.1 and 3.0 a reset of the module should start the processes back up and let you get up and running again.

If the system is still not responding after the reset you might try waiting a few minutes and attempt to log back in. There are a few minutes after a resest in which the sensor will still be initializing the processes and not be able to communicate with user's CLI session.

In version 4.x IDSM2 you may also want to consider creating a service account. When you see the error you can log in with the service account and run "ps -ef" to see if the mainApp process is running.

You can also run "top" and see how much cpu and memory is being consumed in the system.

CreatePlease to create content