| >> I also feel it is unacceptable to have to deregister all SNMP entities
>> and re-register them, just in the hopes that the mib extentions MIGHT
>> be picked up. This is a serious problem.
I agree adamantly with this last point!
The automatic MIB filter is worthless if it requires deregistering and
reregistering every SNMP device to make it take effect. If given the choice
of the automatic MIB filter which requires the above, and no MIB filtering at
all, then I would opt for no filtering at all.
Merlin
|
|
RE .0
>> After racking what little brain I have left, remembered a note about
>> this, but I could not find it. I dug a little more gray matter out and
>> recalled that there was now some sort of filter that only allowed the
>> Vendor specific extentions to be picked up when the entity was
>> registered. SO as a test I deregistered an entity, a vitalink, and the
>> re-registered it. Well the vitalink mib showed up.
If only people would read the release notes. :-)
Page 2-16 of the MCCBMS013.RELEASE_NOTES details a way of automatically
reregistering the SNMP and NODE entities when you upgrade from V1.2 to
V1.3. (You can actually let it run overnight). I quote from the document.
*********************************
The instructions for updating instance repository are below:
On VMS:
$ define MCC_REGISTRATION_FM_LOG 01000000
$ mana/ent
MCC> register snmp *
MCC> register node *
MCC> exit
$ deassign MCC_REGISTRATION_FM_LOG
On ULTRIX:
% setenv MCC_REGISTRATION_FM_LOG 0x01000000
% manage
MCC> register snmp *
MCC> register node *
MCC> exit
% unsetenv MCC_REGISTRATION_FM_LOG
**********************************************
>> I also feel it is unacceptable to have to deregister all SNMP entities
>> and re-register them, just in the hopes that the mib extentions MIGHT
>> be picked up. This is a serious problem.
The SNMP entities need to be re-registered only when you upgrade
to V1.3. Also, if the agent strictly adhered to the SNMP protocol
then all supported mibs (which have been loaded in the dictionary)
will show up. If a mib does not show up you can always bring up
the tool box and add (register) the mib extension child entity
to the iconic map. (This is after you have double-clicked into the
global entity).
RE .1
>>The automatic MIB filter is worthless if it requires deregistering and
>>reregistering every SNMP device to make it take effect. If given the choice
>>of the automatic MIB filter which requires the above, and no MIB filtering at
>>all, then I would opt for no filtering at all.
As I said, once you have registered an SNMP entity with V1.3 you should
not have to re-register that entity again. MIB filtering can be
a useful feature if you have a large number of mibs loaded in your
dictionary. It is desirable to have only the supported ones to
show up on the iconic map, instead of having to sift through the
list and figuring out which ones are supported. True, if all the
supported mibs showed up correctly on the map then this would be
a really useful feature. Unfortunately, due to quirks in the agent,
all the mibs may not show up correctly, in which case the user can
register the mib child entities by hand. The good thing about this
approach is that it needs to be done only once, and your list
of supported mibs is always there.
RE .2
>>Will this also mean that every time a vendor comes out with a new rev which
>>includes a new mib that all of this vendor's entities must be
>>de/re/registered??? This won't make 'em happy to say the least if true.
No. Only if a vendor starts supporting a brand new mib will you
have to reregister the entity. eg. If Chipcom adds a new branch to
their private mib you will not have to reregister the entity.
However if the chipcom agent starts supporting the RMON mib then
you will have to reregister. Or you may choose to register the
RMON child entity under the global entity by hand.
Rahul.
|