[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

4838.0. "Community name storage and Alarms FM ?" by ZUR01::FUEGLISTER (Roland Fueglister, 760-2498) Wed Apr 07 1993 11:40

I did some testing with the new MCC feature "Community name storage per
instance for read, read/write"  together with the Alarms FM.

With DECmcc V1.2, community name storage was not possible. To enable alarm
rules we had to use the qualifier /by password "communityname"/.

With DECmcc V1.3 we are able to store community names and the question is, if
the Alarms FM is picking up the stored community names when the snmp alarm rule
will be enabled and/or evaluated. 

I have created an alarm rule like :
Expression = (snmp * ifnumber = 0, at every 0:05:0) 

The alarm rule was running with 3 Cisco routers with a community name <>
"public" and to my surprise evaluation was always "false"
Does this mean, that the alarms FM is first searching for stored community
names?

Then, I added some other SNMP devices with community "public" to the same
domain and enabled the SNMP wildcard rule again.
During this time I got alarm exceptions from the Cisco routers.

I would like to have a clear answer if this new DECmcc V1.3 feature can be used
together with the Alarms FM.

The idea is to have all SNMP devices in one domain with only one SNMP wildcard
reachability rule regardless of different community names.


				Best Regards,


				Roland

T.R	Title	User	Personal Name	Date	Lines
4838.1		MOLAR::YAHEY::BOSE		`Wed Apr 07 1993 16:42`	12
	The Alarms FM calls the SNMP AM which always uses the correct community name associated with the entity in question. This will be true even for alarms global wildcarding. The IPReachability status attribute is evaluated using ICMP pings and does not use any SNMP requests. Thus the community name is not relevant for this operation. Have you tried using the IP Reachability Poller which is shipped with V1.3? You will not need to write any alarm rules to get notified of reachability status changes of IP nodes. Rahul.
4838.2		MCDOUG::doug	pre-retinal integration	`Wed Apr 07 1993 16:52`	10
	> The Alarms FM calls the SNMP AM which always uses the correct > community name associated with the entity in question. This will > be true even for alarms global wildcarding. You know, that this sort of change DOESN'T require a change to a generic FM should point out one of the really nifty things about MCC... Oh well. Back to the brickbats. /doug
4838.3	Problem currently not reproducable	ZUR01::FUEGLISTER	Roland Fueglister, 760-2498	`Thu Apr 08 1993 05:19`	19
	Hi Rahul, After your answer I did some further testing in the office. After enabling the rule mentioned in .0, I changed community names on the fly and the wildcard alarm rule worked always properly. At the first look, the problem I experienced at customer site is not reproducable; I will do a second try. I will also try out the new IPreachability Poller. In the past we had a lot of PING phantom alarms, that is the reason why we are currently polling everthing with SNMP. Best regards, Roland
4838.4		MOLAR::YAHEY::BOSE		`Thu Apr 08 1993 11:47`	10
	>>In the past we had a lot of >>PING phantom alarms, that is the reason why we are currently polling everthing >>with SNMP. Roland, I understand why you are using SNMP to test for reachability. However, I am curious to find out if the IP Poller is any more reliable than alarming on the ipreachability attribute. Rahul.
4838.5		ZUR01::FUEGLISTER	Roland Fueglister, 760-2498	`Tue Apr 13 1993 13:28`	6
	Hi Rahul, I will give you feedback. Earliest date for testing IP reachability poller at this customer site will be possible at week 18 or 19. Roland