[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

4080.0. "Question for DECmcc engineers" by CSC32::W_MCGAW () Thu Nov 12 1992 17:24

    
     
    Hi,
    
    This is mainly directed at the engineers for DECmcc.  I have a customer
    that is having problems with SNMP alarm rules that stop evaluating. 
    THe rule still says it is enabled and running but the time of last
    evaluation stops getting updated and the rule appears to be stuck. 
    This customer is also having problems graphing live data in much the
    same way.  The man in the graph is in the running position but the
    graph stops being updated.
    
    This customer is using TGV Multinet ip and when he questioned them,
    they asked if we are using read or write ASTs in DECmcc.  What can I
    tell him?

    Thanks,
    Walt

T.R	Title	User	Personal Name	Date	Lines
4080.1	SNMP AM question for DECmcc engineers	YAHEY::BOSE		`Thu Nov 12 1992 17:49`	5
	We have seen similar problems where Alarms and SNMP AM hangs with TGV's Multinet software. This is currently under investigtion. /rb
4080.2	I am aware of the TGV problems.	CX3PT3::SHOTO::W_MCGAW		`Fri Nov 13 1992 10:54`	6
	Yes, I know. I have CLD'd the customer in question for both an alarm rule problem and also graphing of SNMP entities that appears to just suspend even though the man in the graph box is still in the running state. Walt
4080.3	More information on the TGV problem from the customer	CX3PT1::SHOTO::W_MCGAW		`Mon Nov 16 1992 16:12`	166
	Hi, This is an extract from a workunit the customer sent to me concerning the alarm rule and graph problems with TGV Multinet IP transport. I thought this might be helpful and if there is anything you would like to have the customer try, please let me know. Walt \+----------------------- Beginning of Screener's Text -----------------------+ \MCC 1.2 graphing and private MIB woes \ This call created by the customer using DSNlink for VMS. \ This is additional information to the call owned by 115220 \+--------------------------- End of Screener's Text --------------------------+ ---------< This work unit was entered by DSNlink - 137 lines >---------- From: (76977) KUHUB::PAUL "Craig Paul (16-NOV-1992 14:33)" To: DSN%SRQ$C921028-1299 Subj: RE: MCC 1.2 graphing and private MIB woes System KUHUB is a VAX 9000-210 running VMS V5.5-1. (HW Ver=00B00000000000040E84116E, SID=0E84116E, XSID=00000101) Walt (DEC) and Bruce (TGV) I ran a second DECterm session on the workstation that runs MCC 1.2 and used TGV/Multinet's tcpdump to watch snmp output. I used CMU's snmp package for VMS (converted by TGV) to issue some snmp commands and watched the packets get displayed by tcpdump just fine. Then I went into MCC and typed show snmp midnet-gw.cc.ukans.edu proteon xface peth, via port 4, in domain midnet and saw NO snmp packets issued, yet a few seconds later I got the attribute not getable window-full (In line mode I see) MCC> show snmp midnet-gw.cc.ukans.edu proteon xface peth, via port 4,- _MCC> in domain midnet Using default ALL IDENTIFIERS SNMP midnet-gw.cc.ukans.edu proteon xface peth AT 16-NOV-1992 14:25:26 Identifiers Examination of attributes shows: MCC> Yet MCC> show snmp midnet-gw.cc.ukans.edu proteon admin status all attributes,- _MCC> in domain midnet SNMP midnet-gw.cc.ukans.edu proteon admin status AT 16-NOV-1992 14:26:53 All Attributes proAdminStatusCrashMsg = %X52656C6F6164656400202020202020202020 20202020202020202020202020202020202020 20202020202020202020202020202020202020 2020202020202020 proAdminStatusReloadTime = 112308000 proAdminStatusStarts = 5 proAdminStatusCrashes = 0 MCC> During those last two snmp requests from MCC here's the tcpdump that I see $ tcpdump/hex/snap=1536 port snmp 14:29:34.64 midnet-gw.cc.ukans.edu.snmp > bali.cc.ukans.edu.3341: GetResponse(12 3) system.sysUpTime.0=104077991 system.sysDescr.0="Portable MC68020 C Gateway "KU Proteon" S/N 263 V11.0d [ " system.sysObjectID.0=E:proteon.1.1.42 4500 00a7 0483 0000 3b11 74dd 81ed 0105 E.......;.t..... 81ed 0107 00a1 0d0d 0093 167c 3081 8802 ...........\|0... 0100 0406 7075 626c 6963 a27b 0201 0102 ....public.{.... 0100 0201 0030 7030 1006 082b 0601 0201 .....0p0...+.... 0103 0043 0406 341a a730 4506 082b 0601 ...C..4..0E..+.. 0201 0101 0004 3950 6f72 7461 626c 6520 ......9Portable 4d43 3638 3032 3020 4320 4761 7465 7761 MC68020 C Gatewa 7920 224b 5520 5072 6f74 656f 6e22 2053 y "KU Proteon" S 2f4e 2032 3633 2056 3131 2e30 6420 5b20 /N 263 V11.0d [ 3015 0608 2b06 0102 0101 0200 0609 2b06 0...+.........+. 0104 0101 0101 2a ......* 14:29:34.74 bali.cc.ukans.edu.3341 > midnet-gw.cc.ukans.edu.snmp: GetRequest(29) E:proteon.1.2.4.0 4500 004c 6cfa 0000 3c11 0bc1 81ed 0107 E..Ll...<....... 81ed 0105 0d0d 00a1 0038 2c99 3082 002c .........8,.0.., 0201 0004 0670 7562 6c69 63a0 8200 1d02 .....public..... 0102 0201 0002 0100 3012 3082 000e 060a ........0.0..... 2b06 0104 0101 0102 0400 0500 +........... 14:29:34.74 midnet-gw.cc.ukans.edu.snmp > bali.cc.ukans.edu.3341: GetResponse(91 ) E:proteon.1.2.4.0=52_65_6c_6f_61_64_65_64_0_20_20_20_20_20_20_20_20_20_20_20_2 0_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_2 0_ 20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20_20 4500 0086 0484 0000 3b11 74fd 81ed 0105 E.......;.t..... 81ed 0107 00a1 0d0d 0072 880c 3068 0201 .........r..0h.. 0004 0670 7562 6c69 63a2 5b02 0102 0201 ...public.[..... 0002 0100 3050 304e 060a 2b06 0104 0101 ....0P0N..+..... 0102 0400 0440 5265 6c6f 6164 6564 0020 .....@Reloaded. 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 14:29:35.17 bali.cc.ukans.edu.3345 > midnet-gw.cc.ukans.edu.snmp: GetRequest(59) system.sysUpTime.0 system.sysDescr.0 system.sysObjectID.0 4500 006a 6cfd 0000 3c11 0ba0 81ed 0107 E..jl...<....... 81ed 0105 0d11 00a1 0056 3be7 3082 004a .........V;.0..J 0201 0004 0670 7562 6c69 63a0 8200 3b02 .....public...;. 0101 0201 0002 0100 3030 3082 000c 0608 ........000..... 2b06 0102 0101 0300 0500 3082 000c 0608 +.........0..... 2b06 0102 0101 0100 0500 3082 000c 0608 +.........0..... 2b06 0102 0101 0200 0500 +......... 14:29:35.18 midnet-gw.cc.ukans.edu.snmp > bali.cc.ukans.edu.3345: GetResponse(12 3) system.sysUpTime.0=104078046 system.sysDescr.0="Portable MC68020 C Gateway "KU Proteon" S/N 263 V11.0d [ " system.sysObjectID.0=E:proteon.1.1.42 4500 00a7 0485 0000 3b11 74db 81ed 0105 E.......;.t..... 81ed 0107 00a1 0d11 0093 df77 3081 8802 ...........w0... 0100 0406 7075 626c 6963 a27b 0201 0102 ....public.{.... 0100 0201 0030 7030 1006 082b 0601 0201 .....0p0...+.... 0103 0043 0406 341a de30 4506 082b 0601 ...C..4..0E..+.. 0201 0101 0004 3950 6f72 7461 626c 6520 ......9Portable 4d43 3638 3032 3020 4320 4761 7465 7761 MC68020 C Gatewa 7920 224b 5520 5072 6f74 656f 6e22 2053 y "KU Proteon" S 2f4e 2032 3633 2056 3131 2e30 6420 5b20 /N 263 V11.0d [ 3015 0608 2b06 0102 0101 0200 0609 2b06 0...+.........+. 0104 0101 0101 2a ......* 14:29:35.20 bali.cc.ukans.edu.3345 > midnet-gw.cc.ukans.edu.snmp: GetRequest(65) E:proteon.1.2.1.0 E:proteon.1.2.2.0 E:proteon.1.2.3.0 4500 0070 6cfe 0000 3c11 0b99 81ed 0107 E..pl...<....... 81ed 0105 0d11 00a1 005c 32b6 3082 0050 .........\2.0..P 0201 0004 0670 7562 6c69 63a0 8200 4102 .....public...A. 0102 0201 0002 0100 3036 3082 000e 060a ........060..... 2b06 0104 0101 0102 0100 0500 3082 000e +...........0... 060a 2b06 0104 0101 0102 0200 0500 3082 ..+...........0. 000e 060a 2b06 0104 0101 0102 0300 0500 ....+........... 14:29:35.21 midnet-gw.cc.ukans.edu.snmp > bali.cc.ukans.edu.3345: GetResponse(65 ) E:proteon.1.2.1.0=112326000 E:proteon.1.2.2.0=5 E:proteon.1.2.3.0=0 4500 006c 0486 0000 3b11 7515 81ed 0105 E..l....;.u..... 81ed 0107 00a1 0d11 0058 8017 304e 0201 .........X..0N.. 0004 0670 7562 6c69 63a2 4102 0102 0201 ...public.A..... 0002 0100 3036 3012 060a 2b06 0104 0101 ....060...+..... 0102 0100 4304 06b1 f570 300f 060a 2b06 ....C....p0...+. 0104 0101 0102 0200 4101 0530 0f06 0a2b ........A..0...+ 0601 0401 0101 0203 0041 0100 .........A.. It was gratifying to see one of my snmp alarms poll a few minutes later. So it looks as though MCC is not issuing one of the commands to look into the Proteon private MIB!
4080.4		YAHEY::BOSE		`Tue Nov 17 1992 14:13`	25
	>>MCC> show snmp midnet-gw.cc.ukans.edu proteon xface peth, via port 4,- >>_MCC> in domain midnet >>Using default ALL IDENTIFIERS >>SNMP midnet-gw.cc.ukans.edu proteon xface peth >>AT 16-NOV-1992 14:25:26 Identifiers >>Examination of attributes shows: >>So it looks as though MCC is not issuing one of the commands to look into >>the Proteon private MIB! The "peth" child entity does not have any identifier attributes. So the above command does not return any attribute values, nor does it send out any SNMP requests. The only attributes present for the child entity are counter attributes. So the above command with "all counters" will give a different result. Question about graphing. Can the user do a SHOW operation for the attributes he is trying to graph? Rahul.
4080.5	The problem is Proteon's mib.	YAHEY::BOSE		`Thu Nov 19 1992 16:16`	22
	Walt, I've finally figured out what the problem is. After talking with some other folks having the same problem, it has become apparent that the "peth" object is actually a columnar object with instances. However, the Proteon mib does not define it as a table object. So, there is a major mismatch between what the mib says and what the agent knows. To make the situation even worse, there are a number of other tables implemented in the agent, which are not defined as tables in the mib. As such, the Proteon mib is more or less useless. One of the requirements that DECmcc imposes on mibs is that they be conformant with RFC 1212 (Concise Mib Formats). Proteon's mib does not conform to RFC 1212, and hence is unusable by DECmcc. (I know we did ship it with our kit, but at that time we were under the impression that the Proteon agent did not implement any table objects). The only option is to obtain an RFC 1212 compliant mib from Proteon and load it into MCC. Rahul.
4080.6	response to .4 and .5	CX3PT1::SHOTO::W_MCGAW		`Fri Nov 20 1992 13:34`	9
	Hi Rahul, Thank's for the reply onthe mib problem. The graphing issue that was mentioned in an earlier note, is of an intermittent nature. The graph does start out properly but then stops graphing. I thought it was very similar to the SNMP alarm rule problem with the TGV multinet IP transport. Walt
4080.7	Stack Size?	RACER::dave	Ahh, but fortunately, I have the key to escape reality.	`Sat Nov 21 1992 16:12`	5
	One of The "Multinet" problems has been tracked to a lack of stack space in the am. Bump the stack size and you may find the problem will go away. The release notes I just saw said to double it from 100 to 200, but I would be willing to go out on a limb and say that sounds like overkill with no testing.
4080.8		YAHEY::BOSE		`Wed Nov 25 1992 11:58`	13
	Walt, I think we have found the solution to the alarms and graph hang problem. The fix will be in 1.3 (which is going to field test soon). As for the Proteon mib problem, we intend to work with Proteon regarding this and come up with a solution. Please convey this message to your customer so that he may rest easy. Rahul.
4080.9	Belated thank you	CX3PT2::SHOTO::W_MCGAW		`Fri Jan 22 1993 12:04`	9
	Hi, sorry I took so long to respond... As for reply .7, the stack size had been increased as the release notes point out but that didn't have any effect. As for .8, thanks Rahul! I will follow up with the customer on both counts. Walt