| If the answer to #1 is that it is an SNMP manager that can compile a
MIB, then the _theoretical_ answer to the rest is that it _could_ be
done, but functions like backplane configuration are so complex even
with the MIB that I would never recommend that a customer try to do
them by hand.
Basic monitoring of the things you would want to put alarms on would be
pretty easy, though.
|
| The DEChub 900 modules implement a variety of MIBs. Some of these
are standard IETF MIBs; in this case they are RFC's and are
usually implemented by a large number of vendors on relevant
products. For example: MIB-II, Ethernet MIB, Repeater MIB,
Bridge MIB, FDDI MIB, etc. Some MIBs are Digital-specific
extensions, for situations when there is more information available
from the module than is specified in the standard MIBs. Finally
vendor MIBs are needed when there is no existing standard MIB - the
"Chassis MIB" used to manage the 900 Hub Manager is an example.
HUBwatch assimilates information from both standard and Digital
vendor MIBs, and presents key data to the user through a
user-friendly graphical interface. As a user, it makes life a
whole lot easier to have the vendor that made the product present
the interface.
Vendor-specific MIBs can be monitored by "generic SNMP managers".
It is possible to read and write variables that are specified
in the MIB. However, the customer now needs to read and understand
the MIBs. In the case of "LAN hopping", this is especially difficult
simply because of the complexity of the associated MIB.
Since a standard MIB is specified by the IETF committees and is
implemented across the industry, prominent NMS vendors (eg, HP)
will write applications on their platform that use information in
the MIB to monitor and manipulate all products that implement it.
Obviously, this can't be done for vendor MIB extensions since each
vendor has different extensions depending on their own value-add.
However, this makes it possible to manage a number of products
via a user-friendly interface with another vendor's manager - at
least the standard MIB part. The advantage is that key information from
different vendors' boxes for a specific function can be managed with
exactly the same interface without understanding the MIB. Also,
the user can depend on getting a minimum subset of information
from any vendor for a particular function. This is
the value of implementing standard RFC MIBs rather than only vendor
MIBs; it's what makes SNMP "open". Unfortunately a large number
of vendors will implement vendor MIBs only - in effect the use of
the SNMP protocol is defeated since they can't be managed easily
with another vendor's manager. Partly because of this, there is not
currently a large number of applications available for standard MIBs.
However with the growing adoption of standard MIBs, this can't be too
far away. (By the way, this is a strong selling point of the DEChub
900 modules; we implement standard MIBs wherever possible, where many
other vendors don't.)
Anil
|