Re: VMS IDS receiver failing silently

mjuckett · ‎10-04-2005

Twice in two weeks the Event Viewer has quit showing alerts. It takes restarting the services from CW to have events start showing up again. Looking through the logs on the server, I found one log file with errors at the corresponding times for when the events stopped. The file is called IDS_Receiver. The error is:

"Sensor <Name>: Fatal RDEP/SDEE Collection error - exiting collection."

It does this to every sensor within a few minutes. Once this error occurs, no events are collected in the database. So, any events that occured between this failing silently and when the application services are restarted are lost.

Has anyone seen this error before or experienced anything like it? Were you able to determine the cause?

Thanks,

MJ

crmoore · ‎10-07-2005

MJ,

We've just experienced the same issue with 5 of our IDSM-2 Modules. In a period of 90 sec. all 5 received an RDEP/SDEE Collection error. The VMS Server had to be bounced to restore connectivity. Research thus far hasn't turned up any specific cause.

Craig

974312magr · ‎11-08-2005

Hi.

I have the same issue with some IOS IPS in Security Monitor 2.1.0 (Build 123) of CW VMS 2.3. In audit logs, the server shows the next messages near to the time when server stop to collect the events:

RDEP/SDEE Collector Parser Exception(XMLParserException) : - Ran out of memory for parse buffer.

Sensor : Fatal RDEP/SDEE Collection error - exiting collection.

I searched in a bug toolkit, but I don´t find any bug related with it.

Someone knows something about it? It is a well known bug of CiscoWorks VMS?

Thanks.

g.froehlich · ‎11-23-2005

Same happens to my systems. The have run for some months now. Since 2 weeks the connections resets every weekend.

Ecaroh

974312magr · ‎11-23-2005

Yes, all times except one, it happens in my Security Monitor in weekend.

I found the CSCsc51355 bug. I think is new, I didn´t see before, and I was searching about it. I think the bug refers about our issue.

But the bug is not clarify to me. It said "First Found-in Version 2.2(310)". I have the version 2.1.0 (Build 123). I thinked is the newest.

The status is "Resolved", and the workaround is "One can try to alleviate the problem by increasing the page size. This may not be effective, and an upgrade is the only solution."

I can´t to increase more the page size memory. the server has more than the recommended memory. What about the upgrade? Which version? I searched, but I didn´t find any newer version. Is a newer version available?

Thanks.

g.froehlich · ‎11-24-2005

Unfortunatly i have no access to tac at the moment. But one thing which is related to memory is the periodical increasing memory consumption. This fills RAM and moreover results in heavily allocating swap memory using more and more swap space on disk. I start new with 1 GB RAM fresh booted and get 1,5 GB after two days. After one week 2 GB RAM are filled and the host starts swapping. When 2,5 GB are reached Cisco Works don't work anymore. :-/

Quick workaround for me till i have tac back again is to reboot the host (Windows 2000) periodical all 3 days. CW is 2.2 with IPS MGMT and Sec. Mon. 2.1.

Ecaroh

r.stahlbrand · ‎11-25-2005

I got similar problems as Ecaroh. The IDS_receiver (receiver.exe) clearly contains a serious memory leak. This conclusion is established after verifying that no events are lost while the IDS_receiver is running.

RAM and swap usage is constantly increasíng until receiver.exe has allocated about 2,9GB of RAM & Swap. My dirty solution is to restart the IDS_receiver process from CW before it allocates 2,9GB of RAM & Swap.

This restarting has a serious drawback: About 50-200 alarms are "lost" each time the IDS_receiver is restarted. This is probably due to the IDS_receiver fails to store the events located in the IDS_receiver buffers.

This is the only error message in the audit logs when reaching 2,9GB of RAM & Swap:

Sensor : Fatal RDEP/SDEE Collection error - exiting collection.

cskipper · ‎12-01-2005

All

This issue pertaining to the receiver failing has been resolved in the upcomming release of IPS MC 2.2. This release is expected in December 05'.

Thanks to everyone bringing this to our attention via NetPro and for their continuing support.

r.stahlbrand · ‎12-14-2005

Has the 2.2 version been relesed yet?

cskipper · ‎12-15-2005

IPS MC 2.2 is looking to be release 16 December.

Thanks

974312magr · ‎12-20-2005

Hi.

I downloaded the install file of IPS MC & Sec. Monitor 2.2.

In "Installing VMS" topic of the cmRn22.pdf file included in the install file, it shows:

"IPS MC and Security Monitor are components of the VPN/Security Management

Solution (VMS). CiscoWorks Common Services 2.3 is required for IPS MC and

Security Monitor to work. CiscoWorks Common Services 2.3 provides the

CiscoWorks Server base components and software developed to support IPS MC

and Security Monitor, including the necessary software libraries and packages."

My CiscoWorks VMS 2.3 has Common Service 2.2. I think is the recommended for CW VMS 2.3. What about of this comment? Is it true? Is necessary an upgrade of Common Service?

Besides, in "Resolved Problems" topic, I did not find the CSCsc51355 bug. Is it truely resolved in this version 2.2 of IPS MC & Security Monitor?

Thanks.

r.stahlbrand · ‎12-20-2005

It installed fine for me with Common services 2.2 SP3.

The receiver.exe memory bug is fixed :-).