T.R | Title | User | Personal Name | Date | Lines |
---|
2126.1 | SNMP AM is part of the DECmcc V1.2 EFT kit | YAHEY::BOSE | | Thu Jan 16 1992 17:45 | 8 |
| >>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 error | TOOK::MINTZ | Erik Mintz, DECmcc Development | Thu Jan 16 1992 23:12 | 9 |
| 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.3 | SNMP AM Part of V1.2 EFT Kit | MAIL::CLAYTON | Merlin Clayton DTN 445-7217 | Fri Jan 17 1992 09:22 | 22 |
| 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.4 | Ask the agent developers | TOOK::MINTZ | Erik Mintz, DECmcc Development | Fri Jan 17 1992 09:33 | 10 |
| >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.5 | Probably Incompatible MIB II Definitions | MAIL::CLAYTON | Merlin Clayton DTN 445-7217 | Fri Jan 17 1992 12:52 | 11 |
| 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.6 | MIB repository? | ENUF::GASSMAN | | Tue Jan 21 1992 11:56 | 4 |
| Is there a MIB repository within Digital? If not, does anyone
volunteer to start one?
bill
|
2126.7 | MIB clearinghouse | HOO78C::TURHAN | | Tue Jan 28 1992 11:29 | 9 |
| 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.8 | great!!! | TOOK::CALLANDER | MCC = My Constant Companion | Fri Jan 31 1992 09:11 | 2 |
| sounds like a great idea!!!
|
2126.9 | New Proteon MIBs Still Not Working | MAIL::CLAYTON | Merlin Clayton DTN 445-7217 | Fri Jan 31 1992 10:00 | 31 |
| 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.10 | The directory exists all ready. | PA::E_HATEM | | Fri Jan 31 1992 15:55 | 21 |
|
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
|