[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

1721.0. "Use of SNMP AM is not straightforward." by KETJE::PACCO (To manage you have to be a (manag..) skilled person!) Fri Oct 25 1991 11:13

    I have some concerns on how well SNMP managed objects integrate in
    DECmcc at this time.

    The SVP partners list is quite extensive, and you find e.g. CHIPCOM,

    My immediate problem relates his time to Chipcom.  I try to manage an ONline
    system which supports SNMP.  I was happy to find the CIPCOM MIB
    extension file in the distribution of the DECmcc TCPIP AM  V1.1.
    After all work to compile this MIB a chipcom entity appears as a child
    entity of the SNMP entity.  So far so good.

    When the real work of management starts i tried to compare what is
    possible via the console port of the ONline concentrator related to
    SNMP commands.

    Incredible, it's about impossible to make any relation.  More, when
    clicking to expand some tables, it takes a lot of time (to about a
    minute) to find out afterwards that most of the child attributes are
    not obtainable.

    If you compare the management of a CHIPCOM ONline concentrator by
    DECmcc, to CHIPCOM's small PC based management system, which is well
    oriented to a nice representation of their equipment, what would YOU
    choose?

    I can hardly accept that CHIPCOM was a STRATEGIG VENDOR, if the only
    thing we got from them is their publicly available concise MIB
    definitions. Why are all other vendors who have a SNMP concise MIB
    definition file for their equipment not also STRATEGIC VENDOR ?

    I would expect that:
    	1 - all attributes of CHIPCOM's private extensions would receive a
    	    meaningful name, instead of their "concise" symbolic notation.
    	2 - that reading their console language would direct me easily to
    	    their SNMP equivalents.
    	3 - All console commands have a counterpart through DECmcc.
    	4 - Ultimately nobody should any more use the "generic" SNMP access
    	    module, but instead each vendor should represent their
    	    equipment through a specialised access module (indirectly
    	    calling the SNMP access module), hiding the world
    	    of explosing number of private SNMP definitions, the tied
    	    relation to the communication protocol, the use of
    	    inappropriate MIB definitions, choice which is put in the hands
    	    of the operators when "generic" access modules are used.
    	    Instead a the functional management approach should be used,
    	    and i expect that at least a specialised access module would
    	    have been developed to better structure the obect information.

    Can somebody show experience in managing SNMP accessed objects, where
    customers are happy with the functionality which is provided through
    the TCPIP access module ?

    
    	Dominique PACCO.

T.R	Title	User	Personal Name	Date	Lines
1721.1	Welcome to the real world.	DANZO::CARR		`Fri Oct 25 1991 15:46`	85
	> When the real work of management starts i tried to compare what is > possible via the console port of the ONline concentrator related to > SNMP commands. Incredible, it's about impossible to make any relation. > If Chipcom chose to make the same level of functionality available via SNMP that they have available through their own proprietary console or PC based interface, then DECmcc or any other general purpose SNMP management station would be much more useful for managing their devices. I suspect that SNMP's lack of real security may have something to do with vendors not opening up more to remote management via SNMP. > More, when clicking to expand some tables, it takes a lot of time > (to about a minute) to find out afterwards that most of the child > attributes are not obtainable. If attributes are not obtainable, then either the agent you're querying dosen't support the Chipcom MIB completely, or the current configuration of the device is such that the requested info cannot be returned by the agent. In either case, this is an agent problem, not a management system problem. (Although I will admit, it does take a long time to expand large tables from the Iconic Map PM). > > If you compare the management of a CHIPCOM ONline concentrator by > DECmcc, to CHIPCOM's small PC based management system, which is well > oriented to a nice representation of their equipment, what would YOU > choose? If all I had to manage were Chipcom Online conecntrators then I'd probably choose Chipcom's PC based management system. If I had to manage Chipcom devices, Wellfleet devices, DECnet phase 4 nodes, DEC bridges, and various other vendor's equipment talking various other management protocols, I might be more inclined to choose DECmcc. > I can hardly accept that CHIPCOM was a STRATEGIG VENDOR, if the only > thing we got from them is their publicly available concise MIB > definitions. Why are all other vendors who have a SNMP concise MIB > definition file for their equipment not also STRATEGIC VENDOR ? If Chipcom hadn't been a STRATEGIC VENDOR I suspect their "publicly available concise MIB" wouldn't even translate cleanly, let alone accurately reflect their agent implementation. > I would expect that: > 1 - all attributes of CHIPCOM's private extensions would receive a > meaningful name, instead of their "concise" symbolic notation. The "concise" symbolic notation is meaningful. It easily and uniquely identifies the object and the SNMP community is very familiar with the conventions used to name objects. > 2 - that reading their console language would direct me easily to > their SNMP equivalents. > 3 - All console commands have a counterpart through DECmcc. Since Chipcom may not have provided SNMP equivalents in many cases, this is not possible. > 4 - Ultimately nobody should any more use the "generic" SNMP access > module, but instead each vendor should represent their > equipment through a specialised access module (indirectly > calling the SNMP access module), hiding the world > of explosing number of private SNMP definitions, the tied > relation to the communication protocol, the use of > inappropriate MIB definitions, choice which is put in the hands > of the operators when "generic" access modules are used. > Instead a the functional management approach should be used, > and i expect that at least a specialised access module would > have been developed to better structure the obect information. This sounds like you'd need alot more than a vendor specific access module. Sounds more like vendor specific Presentation and Function modules would provide what you're looking for. Might be cost prohibitive for DEC to consider this approach. > Can somebody show experience in managing SNMP accessed objects, where > customers are happy with the functionality which is provided through > the TCPIP access module ? Our V1.1 FT sites were very happy with the V1.1 product, including Martin Marietta in Oak Ridge Tennessee, 3M in Minnesota and NASA Goddard Research Center in Texas.
1721.2	Management can only become better.	KETJE::PACCO	To manage you have to be a (manag..) skilled person!	`Mon Oct 28 1991 14:57`	12
	About the "Attributes non gettable" I just realised that Cipcom's version of the EPROM was not at the right level. For the functionality, you are right in saying that a more specialised PM is required, or some specific presentation routines depending on the object to be managed. If I was a customer I really would hope that ultimately this will happen, but at this time I would still consider specific management stations because of their functionality. Or let's say it differently, I would use DECmcc, but in addition still use the original vendors management station. Dominique.