[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

2296.0. "PING alarming doesn't work !!!" by ZUR01::FUEGLISTER (Roland Fueglister, 760-2498) Fri Feb 07 1992 11:25

I have encountered a problem with alarming and notification. 
I want to test my IP environment with the new Ping capability (snmp attribute
ipReachability)

I have the following hardware:
	DECstation 5000 Model 200
	24 Mbyte Memory
	1 RZ57

I have the following software:
	Ultrix V4.2 
	DECmcc T1.2.4



I have created one domain with 42 SNMP domain members. In this domain I have
created 41 ipReachability rules (except my DECmcc station). The polling
intervall is 5 minutes. All 41 SNMP members are on the same Ethernet Lan as the
DECmcc station. Here is an example of such a rule:

!	ipreachability_<name>
!
create domain LOCAL_NS:.rle rule ipreachability_<name> 	-
expression	= (snmp LOCAL_NS:.<name>  ipreachability <> up 	,-  
			at every 00:05:00)	,-
severity	= critical	,-
description	= "Ping does not work"	,-
auto enable	= no
!		


All this 42 rules are enabled in the rc.local file during system boot.
The process, which is running in the background, is the following:

/usr/bin/mcc_fcl do /usr/mcc/mcc_system/alarms/enable_rule

The contents of the file enable_rule is the following:

enable domain LOCAL_NS:.rle rule *
test mcc 0, at start = (+9999-00:00:00)

Notification should be automatically enabled during IMPM startup. But the
notification notify requests window tells me that it is hanging in the "Being
Created,Enabled .rle" state all the time.

After an hour I did the following FCL commands:

MCC> show domain LOCAL_NS:.rle rule * all count

There are no Evaluation Errors
The sum of Evaluation True + Evaluation False  was in most
cases one or two, although the rules should run every 5 minutes!!!


MCC> show domain LOCAL_NS:.rle rule * all status

The time of last evaluation is almost one hour back, several rules have the
folloing error condition:
	"%MCC-E-TRANSMITERROR,error trying to transmit a packet"

On the Iconic Map almost nothing works if alarming is running in the
background.

The following IMPM commands are just hanging:
	show snmp IP_HOST status
	show snmp IP_HOST identifiers

The following commands give the response "No response from entity" back:
	show snmp IP_HOST counter
	show snmp IP_HOST characteristics





I have also tried to enable all alarm rules in the IMPM:

Unfortunately the select Class command does not work for my 42 alarm rules; I
get always the Map Window message: There are no instances of the selected
entity class. No matter, which type of rule, I have selected!!!

Now almost all rules are firing with severity critical, but again the above
discribed commands don't work!!!
 
Despite that DECmcc with alarming enabled doesn't work at all, the simple Unix
Ping command works all the time!!!!

Now I have a some questions about this "PING" implementation.

I would like to know what is the retry count and retransmit timer of the ICMP
echo message. Are these values adjustable as the UDP values are?

As described above the ping alarm rules fire with severity critical because
iprechability = down ??
How can this being tested? I would suggest, that there are only two
possibilities: IP host reachable or IP host unreachable. 
-If the IP host is not reachable via ICMP Ping, the alarm should fire with severity
indeterminate.
-if the IP host is reachable via ICMP Ping the alarm should not fire
Can somebody explain this behaviour.


				Regards,

				Roland

T.R	Title	User	Personal Name	Date	Lines
2296.1		YAHEY::BOSE		`Tue Feb 11 1992 17:19`	22
	I tried exactly what you did, but on only three hosts, one of which was down. When the host is unreachable, the alarm fires with severity critical, while when the host is reachable, no alarm is fired. I guess this is the sort of behaviour you have been expecting all along. Regarding your questions about "ping" implementation, the timeout period is hard-coded to be 30 secs and there are no retries. This large timeout period, along with the fact that only one thread is allowed to do a ping at any point of time, might explain why your 42 alarm rules do not work correctly. The ping timeout period should be a settable attribute and a QAR has been filed against the SNMP AM regarding this (MCC_INTERNAL QAR #02282). I am also looking into the possibility of allowing multiple threads to send ICMP echo requests at the same time. Thank you for pointing out this problem. Rahul.
2296.2	Is the main problem really QARed?	ZUR01::FUEGLISTER	Roland Fueglister, 760-2498	`Tue Feb 18 1992 11:56`	55
	-< PING alarm problem must be QARed !! >- Regarding .1 /I am also looking into the possibility of allowing/ /multiple threads to send ICMP echo requests at the same time./ According to the DECmcc V1.2 Features and Functions Description from John Egolf PING support is added for reachability testing/alarming. I have already two customers which intend to set up their alarm environment with this PING capability. Regarding .0 not only alarming doesn't work but ... /On the Iconic Map almost nothing works if alarming is running in the/ /background./ // /The following IMPM commands are just hanging:/ / show snmp IP_HOST status/ / show snmp IP_HOST identifiers/ // /The following commands give the response "No response from entity" back:/ / show snmp IP_HOST counter/ / show snmp IP_HOST characteristics/ I'm just using one of the basic functionalities of DECmcc, i.e. Alarming with 41 ipReachability rules, and DECmcc is not anymore usable!! This problem must get a highest priority QAR!! I agree with you that with only three rules enabled everything works perfect; I have tried it out. Regarding .1 / I tried exactly what you did, but on only three hosts, one of which/ / was down. When the host is unreachable, the alarm fires with / / severity critical, while when the host is reachable, no alarm is/ / fired. I guess this is the sort of behaviour you have been expecting/ / all along./ I did the following for testing IP host reachable/unreachable: I just disconnected the tranceiver cable from a IP host. In this case, the ipReachability rule cannot access the entity and should generate an exception, i.e severity equal to indeterminate. But I get the same result as you --> the alarm rule fires with severity critical. The question is still remaining: Should there be a rule exception if the entity is not reachable? Roland
2296.3		TOOK::R_SPENCE	Nets don't fail me now...	`Tue Feb 18 1992 14:07`	11
	How often are you testing each of the 40 rules? It seems to me (my opinion here) that if you are testing for reachability and you specify "Severity=Critical" and it is unreachable, then you are getting what you asked for. This seems to be a special case of alarms to me. If I need info FROM the entity and I can't reach it, then it should be an exception. s/rob
2296.4	Changes coming in next release.	DANZO::CARR		`Tue Feb 18 1992 16:19`	14
	Roland, The following changes have been made and will be available in the next release (FT update or SSB). The default timeout value for ICMP Echo has been changed from 30 seconds to 5 seconds. A new characteristic attribute has been added to the TCPIP_AM child entity of MCC, ICMP Timeout. This is a settable attribute. Also, the FT software forced a single thread of execution through PING code in the AM. This is no longer the case. This code is now multi-threaded. These changes should solve the problem you are having. Dan