[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

2126.0. "Cann't Get SNMP MIB II Attributes" by MAIL::CLAYTON (Merlin Clayton DTN 445-7217) Thu Jan 16 1992 17:22

I'm trying to manage a Proteon p4100+ in our demo center using the MCC 
V1.2 EFT and the SNMP V1.1 AM, and I'm having mixed results.

I've compiled and loaded the Proteon private MIB II extensions without any
apparent difficulties.  However, it seems that I can only retrieve MIB I 
information from the p4100.  For example when I select the p4100 from the
iconic map and do "Show Status", it comes back with the ipReachability 
attribute properly reflecting the status of the unit (up or down).  

If I double click on the p4100 and select the proteon MIB extension from the
resulting list, I can look at a few of the p4100 class attributes (like
status), but cannot receive any other attribute data (like tokenr, ieth, etc).
The MCC message I get back for each attribute is "attribute no gettable".

I've tried variations of access control to insure that I have the community
name set up to "public", and have even defined another community on the p4100
to "PUBLIC" to insure that I'm not tripping over case sensitivity.  After I 
set access control, I get an MCC message that says "No response from entity".

I've tried the same sequence of events with a DECserver 300 running V2.1 and 
I have it defined as an SNMP entity.  Same results: withou Access control set
I get the MCC message "attribute no gettable"; with Access control set to 
"public", I get the MCC message "No response from entity".

As usual, I don't understand what's going on here.  Can someone please offer 
me some enlightenment?

Thanks.  

Merlin




T.RTitleUserPersonal
Name
DateLines
2126.1SNMP AM is part of the DECmcc V1.2 EFT kitYAHEY::BOSEThu Jan 16 1992 17:458
>>I'm trying to manage a Proteon p4100+ in our demo center using the MCC 
>>V1.2 EFT and the SNMP V1.1 AM, and I'm having mixed results.

	The SNMP AM is part of the MCC V1.2 EFT kit. So if you installed
	the MCC EFT kit and then installed SNMP AM V1.1, then the result
	could be highly unpredictable.

	Rahul.
2126.2"not gettable" suggests agent errorTOOK::MINTZErik Mintz, DECmcc DevelopmentThu Jan 16 1992 23:129
As Rahul points out, you will probably have to re-install the EFT kit,
since the SNMP AM is probably now corrupt.

Once you have done that, if you still get "Attribute not gettable",
you might suspect the agent on the target system, which might not
support the attribute that you are trying to query.

-- Erik

2126.3SNMP AM Part of V1.2 EFT KitMAIL::CLAYTONMerlin Clayton DTN 445-7217Fri Jan 17 1992 09:2222
I did not install the SNMP AM separately.  It was installed as part of the 
V1.2 EFT kit.  Sorry for the misleading information.  

Re -1:

>Once you have done that, if you still get "Attribute not gettable",
>you might suspect the agent on the target system, which might not
>support the attribute that you are trying to query.

How does one know what MIB variables and associated attributes are supported
by any given entity?

For instance, if I select the DECserver 300 and double click on it to 
expand the standard MIB I variable list, at the end of that list are the 
private MIB II variables for DEC, FDDI, and Proteon.  If I select the "DEC" 
MIB variables from the list, it's expanded to a long list of what I assume to
be private MIB II variables.  For the DECserver 300, I have not found any of 
MIB II variables to work, including "esysChar", "esysStatus", "esysCounters",
etc.

Merlin

2126.4Ask the agent developersTOOK::MINTZErik Mintz, DECmcc DevelopmentFri Jan 17 1992 09:3310
>How does one know what MIB variables and associated attributes are supported
>by any given entity?

You have to ask whoever supports the agent for the particular device.
Or you can try a query, and if it says "not gettable", then it
is probably not supported.

From the director side, we will allow you to issue a query for
any variable you like, and it is up to the agent to respond or not.

2126.5Probably Incompatible MIB II DefinitionsMAIL::CLAYTONMerlin Clayton DTN 445-7217Fri Jan 17 1992 12:5211
I just talked to Proteon, and compared their current MIB II extensions with
the version that I compiled into MCC.  It appears that the two are probably
out of sync since the version that I compiled is 3/6/91, and Proteon's 
version is 9/91.

They are sending me their current version.  When I get it integrated with MCC
I'll psot the results.

Merlin


2126.6MIB repository?ENUF::GASSMANTue Jan 21 1992 11:564
    Is there a MIB repository within Digital?  If not, does anyone
    volunteer to start one?
    
    bill
2126.7MIB clearinghouseHOO78C::TURHANTue Jan 28 1992 11:299
We are also suffering a lot about the resources we have to spend to find out the
right mib files.

If such a location does not exist yet, I can offer to start a mib clearinghouse, 
on best effort basis.

Regards,

Tankut
2126.8great!!!TOOK::CALLANDERMCC = My Constant CompanionFri Jan 31 1992 09:112
    sounds like a great idea!!!
    
2126.9New Proteon MIBs Still Not WorkingMAIL::CLAYTONMerlin Clayton DTN 445-7217Fri Jan 31 1992 10:0031
RE: .5

Well, I just got the latest and greatest private MIB extension from Proteon
(date Dec 12, 91) and compiled them into MCC V1.2.

The results were the same as my original note - for the most part, none of the 
private MIB extensions work for the Proteon 4100 router.  The response is 
almost always "Attribute not gettable".  

In situations like this, when we are dealing with third party private MIBs,
which by the way are probably very dynamic, how do we get the inconsistancies
successfully resolved?

I've talked to Proteon, and they say it works for them with their OPENview
manager system, must be MCC.  Earlier responses to this note suggest that the
private MIB extensions from the vendor (Proteon) are suspect.  Other notes
relative to other vendor's private MIBs suggest the same thing.  This 
unfortuneately reeks of finger-pointing from the customer perspective, which
is not well received.

So, how can one prove, with a high degree of confidence, that a specific 
vendor's MIB extension that has been compiled into MCC is not consistent with
the SNMP agent on the targeted devices?

And specifically, how can I resolve the situation with the Proteon router and
versions of the MIB that they just sent me?

Thanks.

Merlin

2126.10The directory exists all ready.PA::E_HATEMFri Jan 31 1992 15:5521
    
    
    Hi,
    
    My name is Elias Hatem, I am in the SVP group, I am working with
    the following SNMP vendors: Proteon, Chipcom, Synoptics, Wellfleet,
    and Cabletron. Also working with the MSU group to make sure
    we have the same mibs on both systems MSU AND MCC. I can use all the help
    I can get. Please send me all the mibs that you have to took::E_HATEM
    I will include them on the public directory repository described below.
    I do have a reposittory on my system, it's located on the following
    directory:
    
    PA::dkb100:[public]
    
    I have about a 30 plus mibs, howver please do not copy any of the
    mibs there before monday. I would like to update the mibs in that
    area first.
    
    regards...elias
                                                    0