Conference azur::mcc

6257.0. "Enterprise spec traps, how MCC maps on MIB def??" by DECPRG::PAVLUP () Fri Mar 24 1995 16:55

Hello anyone experienced with SNMP traps, and especially with Enterprise 
specific ones. Please help and/or assist me with the following problem...

I've got a customer who is using MCC station (VMS, V1.3), and who has 
purchased UPS devices (Victron being the manufacturer) with SNMP modules
that allow to monitor the UPS, generate traps...

In a cooperation with the UPS distributor, we have tried to set up an 
environment on the customer's site in which the traps generated by the UPS'
SNMP box would be used to initiate actions from within MCC station. The first
step obviously was to make MCC distinguish among the various traps that the
SNMP box generated (they actually are 4, and from them 2 of a great 
importance). And here we encountered a problem: the traps were 
EnterpriseSpecific ones, and we have not be able up to now to make MCC 
distinguish them in the notification window.

I'd like to ask someone to help finding what might be wrong in the environment
we are using. I am a little confused, as I am trying to apply the same 
approach as in case of some other devices  (e.g. a DECagent 90 and the DEC
mib base, for which the Enterprise specific traps are perfectly distinguished).


The  MIB which is implemented by the UPS SNMP box is derived from RFC 1628. 
I got the MIB definition, and it compiled and loaded on MCC fine. When the
SNMP UPS box is registered by the MCC station, it registers O.K., and the
relevant MIB appears among the supported SNMP subclasses registered for the
entity.

The mib is defined as upsMIB, and positioned under the management tree
as {mib-2 33}, i.e. some ...6.1.2.1.33.

I will try to summarize below how the registration process goes between MCC
and the UPS (the MCC station has DEC and Cisco MIBs loaded, that's I assume
why the first two queries are on the appropriate enterprise subtrees, and also
the upsMIB and RMON - that are queried in the end)

         MCC					UPS
------------------------------------------------------------
1.	ping <ups-addr>		-->
				<--		response

2.	GetNext ...6.1.4.1.36.0 -->				(Digital)
				<--		No such name

3.	GetNext ...6.1.4.1.9.0	-->				(Cisco)
				<--		No such name

4.	GetNext ...6.1.3.27.0   -->				(exper. mib??)
				<-- GetResp ...6.1.2.1.33.1.1.1.0 =
						"(c) Victron b.v...."

5.	GetNext ...6.1.3.8.0    -->                             (exper. mib??)
                                <-- GetResp ...6.1.2.1.33.1.1.1.0 =
                                                "(c) Victron b.v...."

6.	GetNext ...6.1.2.1.10.15.0  -->                         (mib-2 ????)
                                <-- GetResp ...6.1.2.1.33.1.1.1.0 =
                                                "(c) Victron b.v...."

7.	GetNext ...6.1.2.1.33.0  -->                            (mib-2 upsMIB)
                                <-- GetResp ...6.1.2.1.33.1.1.1.0 =
                                                "(c) Victron b.v...."

8.	GetNext ...6.1.2.1.16.0  -->                            (mib-2 RMON)
                                <-- GetResp ...6.1.2.1.33.1.1.1.0 =
                                                "(c) Victron b.v...."


The above sequence results in a correct registration of the ups entity, 
including the upsMIB subclass (...6.1.2.1.33). 

If then notifications are created against "SNMP * upsMIB any event" or
"SNMP * upsMIB any configuration event", no enterprise specific traps are
captured. The traps generated by UPS are EnterpriseSpecific with the 
enterprise definition ...6.1.2.1.33.2 (i.e. { upsMIB 2 }). MCC is only able 
to capture them against "SNMP * any configuration event" (and hence it sees
them all "equivalent" as generic EnterpriseSpecific traps), i.e., 
it looks that the station does not do any mapping to the trap definition 
in the upsMIB.

The obvious question now is why, and/or what to do in order to make MCC map
the traps. In the dictionary, the 4 traps in question look correctly 
defined under "class SNMP subclass upsMIB".

Can anyone spend some time to explain, what is the important information that
makes MCC map the mib information onto the received traps?

If I compare the sequence of information exchange described above with 
an analogous one that's done in case of DECagent90, I see that the agent 
gives mainly the following responses that differ from the above sequence (the
queries remain the same):


In step 2., it gives the following value (assume an ID as Digital's box):

2.      GetNext ...6.1.4.1.36.0 -->                             (Digital)
                                <-- GetResp ...6.1.4.1.36.2.18.10.1.1.0 = 3

In step 6., it gives the following (it is particularly interesting, if
anyone can tell me what the response means):

6.      GetNext ...6.1.2.1.10.15.0  -->                         (mib-2 ????)
                                <-- GetResp ...6.1.2.1.10.33.1.0 = 0
                                            
And in step 8., it gives the following:

8.      GetNext ...6.1.2.1.16.0  -->                            (mib-2 RMON)
                                <-- GetResp ...6.1.2.1.19.1.0 = 0




I'd appreciate any information that could enlighten this situation to me.
Particularly how the mapping is done internally in MCC, which enables the
particular EnterpriseSpecific traps to map onto their names from mib
dictionary. Is the difference in some of the responses that the ups box
does not do correctly? Or is it because of the ups MIB is under management
subtree while the others (like Cisco, DEC) under the private enterprise
subtree? Or is there any specific reason bound to the way MCC implements this?

It is important for me to know, as there is a possibility that the 
implementation of ups SNMP agent can be modified to comply with the 
procedure.

Thanks for hints and responses.

Regards Petr.

	I'm not an SNMP expert but by reading your note and rfc 1628, I can
	answer to some of your questions.

     1/ UPS mib is registered with the prefix 1.3.6.1.2... because it's not
	a private mib but an extension to the standard mib ( mib-II, rfc 1213 ).
	A private mib should be registered with the prefix 1.3.6.1.4.1...
	( iso.org.dod.internet.private.entreprise...) followed by the private
	enterprise's code : dec = 36, cisco = 9, ...
	Other extension examples : fddi ( rfc 1512 ), bridge ( rfc 1493 ).
	All of them have a prefix of 1.3.6.1.2...

     2/ The registration process into DECmc is as follows :
	- if no mibs is compiled into the dictionary, DECmcc send requests 
	  using standard attributes : sysDescr, sysUpTime et sysObjectID.
	- if some mibs are added to the dictionary, DECmcc try to check which
	  one are supported by the remote snmp agent.
	By reading your registration process, I can tell that the following
	mibs are compiled into your dictionary :
		Private :
                - DEC ( 1.3.6.1.4.1.36 )
                - Cisco ( 1.3.6.1.4.1.9 )
                Experimental :
                - RMON Experimental ( 1.3.6.1.3.27 )
                - FDDI Experimental ( 1.3.6.1.3.8 )
                standard :
                - FDDI = rfc 1512 ( 1.3.6.1.2.1.10.15 )
                - UPS = rfc 1628 ( 1.3.6.1.2.1.33 )
                - RMON = rfc 1271 ( 1.3.6.1.2.1.16 )

	Let's take an example with the DEC private mib.
		GetNext 1.3.6.1.4.1.36.0
	means :
		"send me back the ID and value of the first attribute in your
		 table following attribute 1.3.6.1.4.1.36 in lexicographical 
		 order"
	If the remote agent doesn't support the DEC mib. the answer is :
		"no such name"
	If it supports it, the agent send back with a value, for example :
		1.3.6.1.4.1.36.2.18.10.1.1.0 = 3

	Neither the name of the variable (1.3.6.1.4.1.36.2.18.10.1.1) nor the 
	value (3) have any importance : the main information is that the
	prefix in the answer ( 1.3.6.1.4.1.36 ) matches the one in the request,
	meaning that THIS mib is supported by the remote agent.

	Another example :
		GetNext ...6.1.2.1.10.15.0 ( do you support mib FDDI ? ) ---->

		<----- GetResp ...6.1.2.1.33.1.1.1.0
		The prefix in the answer ( ...6.1.2.1.33 ) is different from
		the one in the request ( ...6.1.2.1.10.15 ) so this mib is not
		supported.

     3/	rfc 1628 mentions definitions inported from mib SNMPv2. DECmcc is a
	manager SNMPv1. To be more specific, all the traps are defined in 
	UPS mib by using keyword NOTIFICATION-TYPE. Traps defined in SNMPv1
	context ( following rules defined in rfc 1215 ) use the keyword
	TRAP-TYPE. I don't know what can be the side effects of such a
	situation.

     4/ I would recommend to keep a trace of a trap sent by the remote agent
	with a network analyzer, just to be sure of the identification used
	in the trap. You'll then be able to check if the identification is 
	the same as expected by DECmcc.

	A SNMPv1 trap-PDU looks like :
      +------+------------+----------+---------+----------+-------+----------+
      |	PDU  | enterprise |   agent  | generic | specific | time  | variable |
      |	type |		  |  address |	trap   |  trap    | stamp | bindings |
      +------+------------+----------+---------+----------+-------+----------+

	A *correct* private trap identifies itself with the field "generic
	trap" = 6 and its own code in the field "specific trap". This code
	is then checked with the corresponding event defined into the
	dictionary.
	Again, the syntax used in UPS mib is really different from the SNMPv1
	definition ( does not mean that the trap-pdu itself is not the same.
	I really don't know ). And I'm afraid you're right by assuming that 
	the rules used to map the trap are no longer adequate. Somebody else 
	owning the code can confirm or deny this.


	Hope this help,
	Guy.

    Hi Guy,
    
    thanks for your answer and for eleborating the information I've posted.
    Your comments confirm my perception of the process.
    
    By the way, the UPS MIB I compiled into MCC was in the SNMPv1 syntax,
    i.e. with traps defined by TRAP-TYPE keywords. Hence all registers O.K.
    
    But as you say, there still may be a mismatch of what's sent and what's
    expected. I mean - if the UPS MIB is defined originally as SNMPv2, the
    implementation (i.e. the traps too) may be in SNMPv2. But there is
    something I don't know: what's the difference (if any) between v1 and
    v2 trap implementation (I mean on the side of managed device). I'd only
    be happy if someone pointed me to a right source (if not spending the
    time explaining briefly) of this information (I've got the v1 RFCs as
    1215, 1155, 1156, 1157).
    
    As you suggest, I'l try to check what's exactly sent by the UPS agent
    over the network. However, knowing the (potential) differences would be
    an advantage.
    
    Anyway thank you for the comments. 
    
    Best regards Petr.
    
    
    Apropos, could anyone add some comments on what troubles the SNMPv2 may 
    bring to an MCC environment, and what's exactly the way MCC makes
    mapping between trap definitions in MIB (and their names) and numbers
    of specific traps received in run-time...?
    
    I'd appreciate this kind of education very much. Thanks in advance.