Is there any way to flush/purge the alarms stored in the Cat 6000's?
We tried to update the base code to 3.0(2)6, which made it alarm on 100% missed packets. We have subsequently been told that whatever bug is causing this is fixed in version 3.0(2)10. Before we upgrade though, I want to find out why the cat 6000 transmits alarms back to the director only after we log out from the director and restart openview. These alarms are dated a couple of months old and we seem to get a bit closer to present every time we log out and back in.
Is there any way of checking what alarms are on the blade and purging them?
These alarms were probably received by the director a couple of months ago and were buffered.
They are not being strored on the IDSM.
What is happening:
A couple of months ago the IDSM was sending alarms to your director, but then the director map for the IDSM filled up with more than the allowed number of alarms. WHen this happens the director will buffer the extra alarms into the /usr/nr/var/nrdirmap.buffer file (not positive on the name of the file). NOTE: This is on the director and not the IDSM.
Normally you might think that if you delete the alarms from openview then the alarms from the buffer would be read in, but infortunately that is not how it works.
Instead the director will only read the buffer file when ovw is restarted.
What does the user have to do:
1) If you want to look at all of the buffered alarms.
a) start ovw
b) wait for the alarms to be read in (a few minutes)
c) delete the alarms from the map
d) stop ovw
e) start ovw again to get the next set of alarms.
2) If you don't care about the buffered alarms, and just want the new alarms
a) stop ovw
b) cd /usr/nr/var on the director
c) remove the nrdirmap.buffer file (name may differ slightly)
d) restart ovw
e) delete any old alarms hanging around
f) wait for new alarms to come in.
How do I prevent this from happening:
By reducing the number of alarms that wind up in openview.
2) Use filters to exclude false positives on your network which for many users are the majority of alarms they see on a daily basis.
3) If an alarm starts firing often then change the alarm severity to 2, this will log it on the director without filling the director's map with icons. In the case of nimda and other viruses which may send several thousand alarms a day, this may be the best method since you couldn't deal with that many individual alarms anyway.
If you notice a large number of alarms in your GUI, then check to see if a nrdirmap buffer file is being created in /usr/nr/var. If so then you will need to follow the steps that I mentioned earlier to read in those buffered alarms.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :