[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

4165.0. "RULE firing but no colour change" by SIOG::TINNELLY (Consultancy for fee NOT free..) Mon Nov 30 1992 09:15

    
    Hello Folks,
    
    I have a rule set up to test for IPreachability as follows:
    
    expression SNMP * IPREACHABILITY = DOWN, at every =00:05:00
    
    This works fine, when the server is powered down everything works,
    the server icon changes colour and the colour change bubbles up
    through the different domains.
    
    However if I change the rule to poll the specified entity i.e.
    
    expression SNMP .DFHQ_INT IPREACHABILITY = DOWN, at every= 00:05:00
    
    the rule is firing when the server is powered down, the domain icons
    are changing coulour, but the server icon itself is not changing
    colour. The notification window shows the rule firing message with the
    colour change highlighted etc.
    
    When I check the window where I fired up MCC_ICONIC_MAP, I am getting
    an error message as follows:
    
    "Unable to get alternate identifier for alarm .snmp.dfhq_int using
    primary identifier. This is obviously the clue -)
    
    What am I missing ?
    
    many thanks for help.
    
    Peter

T.R	Title	User	Personal Name	Date	Lines
4165.1	re .-1	ANOSWS::COMFORT	Spent a little time on the hill	`Mon Nov 30 1992 16:09`	21
	Since I got caught by the same thing and was helped previously, its my turn. You can avoid this problem (no icon color change) by including the namespace name in the entity string. Otherwise, MCC attempts to resolve the string as a full internet name. Note though, I have found that the ipreachability field is not particularly good for testing a host. Apparently the evaluation of this variable uses the LOOP (PING) process of UCX. My experience has been that I received alarms firing on ipreachability = down when in fact the host is up and running fine. The next evaluation of the same alarm would be correct. I believe that the LOOP/PING command does not refresh the ARP cache and when the ARP cache entry for a host times out, one gets incorrect ipreachablility = down because the first set of packets sent out by a LOOP in UCX will always return a failure UNLESS the system is already in the ARP cache. The second loop will, but it seems that subsequent loops do not refresh the cache. I therefore have switched all my rules to check the ifOperStatus = Up MIB variable on interface 1 of the host in question and my problem went away. Dave
4165.2	QAR for UCX?	TOOK::MINTZ	LKG2-2 near pole X3, cube 6072, dtn 226-5033	`Mon Nov 30 1992 16:25`	3
	Has anyone let the UCX folks know that they have a problem here? That certainly is not proper behavior for a ping command.
4165.3	re .-1	ANOSWS::COMFORT	Spent a little time on the hill	`Mon Nov 30 1992 16:58`	14
	Eric - I have surmised the former after experiencing this and talked it over with UCX internal support, briefly. At that time I was mainly interested in determining if UCX 2.0 had an ARP cache timer that could be adjusted. I guess I've neglected to state that I have seen this behaviour only under UCX 1.3. I do not have information on patched versions. So I have not SPR'd or QAR'd or anything, as usual in the field I was just trying to get the stuff to work correctly for a customer. I will be happy to test this under UCX V2.0 when I get a chance. Dave
4165.4	1200 baud - keep it brief	SIOG::TINNELLY	Consultancy for fee NOT free..	`Tue Dec 01 1992 12:01`	7
	many thanks for the fast response. I will test it out with the namespace name, and probably change my rule. thanks again Peter
4165.5	Works	SIOG::TINNELLY	Consultancy for fee NOT free..	`Sun Dec 06 1992 07:57`	4
	Thanks, it now works with the namespace name included. regards peter
4165.6	Checing ifOperStatus requires more work	FARMS::LYONS	Ahh, but fortunately, I have the key to escape reality.	`Sun Dec 06 1992 13:10`	5
	In general, PING is much "Lighter Weight" than checking ifOperStatus. Checking for ifOperStatus requires an SNMP agent, while the Ping does not. Also, the agent may not be supporting community name PUBLIC, or anything else you have access to. Community PUBLIC is only agreed upon by the router MIB group, not the rest of the IETF.