[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

3328.0. "SNMP trap problem" by FILTON::EVANS_M () Wed Jul 08 1992 14:22

    I have a odd situation with the SNMP traps running on MCC V1.2.7 (with
    corresponding SNMP access module) and hope someone can help.
    
    I have set up two alarm rules to check the link status on Vitalink
    Transpath 350's connected in a triangular network using the linkdown 
    and linkup traps.
    
    I find that when an interface cable is disconnected the MCC reports
    two link down and one link up trap for each Transpath affected by the
    disconnected link. 
    When the interface cable is reconnected the MCC reports two link up
    and one link down trap for each Transpath.
    
    This obviously gives a false indication of the link state and the final
    trap that comes in is the opposite way around from the true link state.
    
    The MCC alarms are reporting correctly what the SNMP access module
    sink is seeing, because if you look at the sink counters the link down,
    link up traps corrispond to the number of traps reported by the alarm rules.
    
    Questions.
    
    
    1.	Why do you get three traps rather than just one link down trap for
    	each affected Transpath.
    
    1. 	Is the SNMP access module sink getting the link up and link down the
    	wrong way around or is MCC evaluating the alarms out of sequence.
    
    Yours confused
    
    Mat Evans

T.R	Title	User	Personal Name	Date	Lines
3328.1	what is the agent sending?	BMAJOR::PERRY		`Wed Jul 08 1992 16:35`	29
	Yes it does seem odd that 3 traps are received when you disconnect/connect an interface cable, but it's even odder the order that you received them. We have, however, seen some agents which send duplicate traps so I suspect that you are seeing what the Vitalink's agent is sending. We need to know exactly which traps the Vitalink agent is sending and what order it is sending them. If Vitalink's agent supports MIB II and specifically the SNMP group within MIB II, you can show the value of the attribute "snmpOutTraps" before and after disconnecting/connecting the interface. I suspect this value will go up by 3 each time whereby accounting for the 3 trap you see. Unfortunately, this won' tell you the type or order of the traps. If you have an Ultrix machine, we have a tool, written at Carnagie Mellon University, which will dump snmp traps out to sysout. You could run this tool to see what it is getting. We have the documentation, source, and executables. Let me know if you want them. You could also connect a line analyzer to see exactly what is going over the wire. There appears to be a problem here but it isn't clear where (agent or manager). If you find out that the agent is in fact sending the correct traps ,please post your findings here. Thanks. Jim
3328.2	TransLANs are a wacky bunch anyway...	TOOK::MCPHERSON	Life is hard. Play short.	`Wed Jul 08 1992 21:54`	20
	This is odd. I assume that you're running 10.5 on the TransLAN. Does it have a letter designator after the version $ (e.g 10.5Q) ? If som, what is it? TransLANs are an odd sort of beast to begin with. (E.g. they play tricks that let you make Ethernet loops, split paths and fool Mother Nature in various interesting ways...) I would suspect a bug with their Agent... It's not unlikely, given then enormous amount of agent code in those boxes (Remember, they're supporting two management agents concurrently; three if you count the console interface.) I will _irresponsibly_ speculate (even though I haven't seen any packet dumps) that the Vitalink agent may be sending a trap for both a LINE and a GROUP when a LINE goes down or up and that their logic was incomplete (i.e. their code caught both transitions for only one of the two: line or group.) Default setting is a 1:1 correspondence between LINEs and GROUPS, however that needn't always be the case. /doug
3328.3	Where this "SNMP tracer" can be found ?	ZTOIS1::VISTA	Renato VISTA, SIS Strasbourg, France	`Thu Jul 09 1992 05:36`	14
	To .1 ... Hi Jim, I'm interested by your "SNMP tracer" of Carnagie Mellon Univ. for Ultrix platform. Is it possible to have a pointer of a kit + documentation of that software ? Thank in advance ! Regards, Renato
3328.4		CSOADM::ROTH	Look! Look! Godzilla!	`Tue Jul 14 1992 10:46`	6
	I've seen the same behavior as mentioned in .0 and I'm running 10.5(nothing) of their s/w. I'll watch the traps on an analyzer and post the info here. Lee
3328.5	cmu software	BMAJOR::PERRY		`Fri Jul 17 1992 17:10`	15
	Renato, You can copy the CMU software from: hamma::/usr/users/carr/snmptrap All their applications (source and executables), documentation, and makefile are in this directory. Send me mail if you have any problems accessing it. Have a good time! Jim
3328.6	Hidden nodes lose...	RACER::dave	Attending The School of Comparative Irrevelevance	`Fri Jul 17 1992 18:13`	1
	Note that HAMMA is address 62.879 in a hidden area behind some other node...
3328.7	more on multiple traps seen	HERON::PATEL_A	LoLo-AQIC-I82Q-B4IP, - LMF	`Mon Jul 27 1992 09:00`	17
	I found that if you set the community names as follows in the snmpd.conf of an Ultrix system ... community trap1 1.0.0.10 traps community trap2 1.0.0.10 traps community trap3 1.0.0.10 traps then on the mcc system you will see 3 traps of any kind generated from the remote system, ie kill the snmpd and you will see 3 cold starts. I could not get it to work at all with community public -- can any one explain this. I suspect that trap1 - trap7 is used as the "classified" traps so that various types of traps can be sent to various systems, if so then is the implementation of traps handling in mcc wrong ? thanks, Amrit