[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 14: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.RTitleUserPersonal
Name		DateLines
2296.1YAHEY::BOSETue Feb 11 1992 20:1922
	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.2Is the main problem really QARed?ZUR01::FUEGLISTERRoland Fueglister, 760-2498Tue Feb 18 1992 14:5655
		-< 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.3TOOK::R_SPENCENets don't fail me now...Tue Feb 18 1992 17:0711
    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.4Changes coming in next release.DANZO::CARRTue Feb 18 1992 19:1914
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