When nrdirmap can no longer place alarms in OpenView it creates a buffer file in /usr/nr/var.
It, however, only rereads this buffer file when OpenView is restarted.
So what you might be seeing is not the exact saem alarms that you deleted but similar ones that were buffered.
So you can either cycle through all of the old alarms by deleting alarms from OV, stop OV, start OV, and delete the next set of buffered alarms, and continue until all of the old buffered alarms are read in.
Or delete alarms from OV, stop OV, go to the /usr/nr/var directory and delete the nrdirmap buffer files, then restart OV and you should only see new alarms after that.
9 times out of 10, the problem here is what Marco described - specifically, that events have been buffered in the /usr/nr/var/nrdirmap.buffer.txt file. Did you have a file there and did you delete it? The presense of a buffer file indicates that you are receiving alarms faster than the director can handle them. Therefore, if you see an nrdirmap buffer file, you should look through the file to determine what types of alarms are being sent, then reconfigure the Sensor to stop sending the false positives.
Once you have reconfigured the sensor to stop sending all the false positives, delete all the alarm icons from the OpenView map, then shut down ovw, then delete the nrdirmap.buffer file, then bring the user interface back up and see what happens.
If you still get lots of alarms in the display after all this, then there are two possible causes:
1) The sensor is still sending reams of events to the Director. To test this, look at the log files in the /usr/nr/var directory. If there are lots of large files here that are getting created at short intervals, then the Sensor is still to blame. If you don't know how to configure the sensor to reduce the alarm load, you could reconfigure the Director to only display, say, level 5 alarms. To do this, click on the "packetd" icon in the openview display, and then select "object properties" or "modify/describe object" (depends on the version of openview you are using). Set the "minimum marginal severity status" and "minimum critical severity status" levels to 5, and then press OK.
This should cause OpenView to display only 5 and higher alarms from this sensor. This might help reduce the clutter on the screen.
2) If alarms keep coming on the screen and you are sure that the sensor isn't sending any new events, then there is only one other possible cause: You have multiple OpenView maps, and you are deleting the alarms from one map but not from all maps. To test this theory, go to the command line and type:
If you get multiple lines here, then it means that you have multiple maps defined. If the alarms exist on more than one map, then the act of deleting the alarms from one map will not delete them from the database. To delete them from the database, you have to delete them from all maps.
The method for doing all this is complicated, but in short you have to launch each map individually with from the command line with the command:
and then select the alarms and then delete them.
A few comments about multiple maps:
A) If you can avoid having multiple maps, then only use a single map. If you feel like you only need one map, bring up openview and use the File->Delete Map menu function to delete all the other extraneous maps. This reduces disk usage and improves performance.
B) Generally, having multiple maps should not cause the alarms to pop back up on a single map.... This should only occur if there is something strange going on on your machine. For example, if the system time is set incorrectly on your machine, then that could do it (go to the command line and type "date" - if the date is wrong, reset the date to the right value and then shut down the openview user interface and daemons and bring it back up). Also, if someone added a "-f" (force) option to your nrdirmap's registration file (in $OV_REGISTRATION/C), then this could cause the alarms to come back after deletion. If someone added this -f option to the nrdirmap registration file, remove it then shut down and restart the ovw user interface.
A few final comments:
The alarm handling capability in Cisco's CSPM (Cisco Secure Policy Manager) is far superior to that of the OpenView NetRanger Director. If you have not had a CSPM demo, I highly recommend that you get a demo. It is far, far, far better than the OpenView director. There are some fundamental limitations in the OpenView database that cause alarm handling to be less than optimal.
If you refuse to use CSPM (because it is an NT-only product), then I highly recommend that you look into Cisco's MDC (multi-device controller) IDS management software that should be ready for release within the next few months. It is web-based (so therefore works on NT and Unix) and uses a kick-ass and reliable relational database for alarm storage. This product will be the mother of all event viewing user interfaces and will simply blow you away. Please ask your Cisco IDS representative for a demo of this MDC product.
Under CSPM Event Viewer, where does all the events get saved and what program do u use to read it ? I wanted to purge the old log (it has exceeded 10,000 record) but can find any Save function provided in CSPM.
In IDS Director, I would usually do a Show alarm details for a particular Sensor and save all logs to a file. Is there a file where all this info is saved or other ways to save these alarm log info ? Thanks in advance.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...