| First of all, SNMP is an open, mult-vendor network management
framework. ELMS is based on the DEC proprietary RBMS, and is
being phased out. With SNMP, customers can use equipment
already available to them with our products.
I think you would benefit from reading the SNMP Configuration Guide,
to get a pointer to the .ps file, try "dir/title=config".
> The questions are the follows :
>
> - What are the differences in terms of attributs we may get/set compare
> with our FDDI, BRIDGE, CONCENTRATOR AMs if any ?
Everything available from ELMS is available from SNMP.
>
> - If differences, what are the consequences of these differences on the
> manageability of these equipements. It's important to know explicitly
> what are going to be mainly impact if we choose SNMP to manage Concentrator
> or Bridge instead our private protocols.
>
> . My experience is : I have augmented the SNMP AM with :
> BRIDGE_STD_MIBDEF.TXT
> DEC_ELAN20_MIBDEF.TXT
> FDDI_STD_MIBDEF.TXT
>
> . Now looking into our private extension (DEC-EMA-fddi...) for
> a wiring concentrator or LanBridge600 seems very different of what we may
> see using our own private management protocol on a FDDI station.
There are a large number of SNMP nms's out there, all compliant
to the protocol, but each with a different user interface. They
have their own mechanism for diplaying a MIB, which is a
collection of variables pertaining to a given functionality. In
order to fully represent management variables for an FDDI bridge,
we had to implement the Bridge MIB, the FDDI MIB, MIB-II, and
the DEC ELAN-MIB. Each management station will display these
MIBs in their own manner, there's no standard specifying the
user interface. We controlled the protocol as well as user
interface for ELMS. Hence you will not see a correspondence
between the screens of ELMS and SNMP.
> . My understanding of the SNMP FDDI sub-entity was for FDDI MIB RFC 1285.
> When I try to get infos, all I receive is 'attribut is not gettable'
Ths is because we have not implemented RFC-1285. We have implemented
an earlier draft version of the MIB, which was all that was available
at the time of development. I believe this is the file
FDDI_STD_MIBDEF.TXT that you referto above. In any case, you can
get this particular MIB version from a location specified in
the config guide.
Our next release for bothe Bridge and Concentrator will support
the standard RFC MIBs.
> . Therefore what are the differences between our FDDI_STD_MIBDEF
> and the FDDI definition we find in DEC_ELAN20_MIBDEF.TXT ?
Don't confuse these two. FDDI_STD_MIBDEF is what has been defined
by the IETF standards body, applicable across all vendors FDDI
implementation. Over and above this, our products have value-added
features which it is is necessary to be able to manage. This is
what DEC_ELAN20_MIBDEF does - it is the collection of variables
("objects" in SNMP terminology) applicable to Digital products
over and above the standard MIBs.
> . When I query a LanBridge600 using BRIDGE MIB RFC 1286 none of the
> attribut is gettable. Don't we support these RFCs into our equipments ?
> What am I doing wrong ?
Again, we had implemented an earlier draft of the IETF Bridge MIB.
Our next release will implement the RFC version.
>
> - Would it be possible to comment for each equipement what extension file
> we have to use ? What is possible to manage compare with our ELM AMs
You can fully manage the bridge with MIB-II, Bridge MIB, DEC-ELAN MIB,
and FDDI MIB (the last is applicable only to bridges with an FDDI port)
>
> - For example what are the differences between :
> BRIDGE_STD_MIBDEF.TXT and DEC_ELAN20_MIBDEF.TXT
> FDDI_STD_MIBDEF.TXT and DEC_ELAN20_MIBDEF.TXT
> in terms of functions/manageability
See above. DEC-ELAN instruments the additionals features in Digital
products. The two are mutually exclusive.
>
> - Why are they so many differences between our FDDI extension and the one
> specify by the RFC 1285. It seems that there are much more definitions in
> the IEFT definitions than in our private efddi extension.
See above!
>
> - Can we really manage our FDDI equipment using SNMP protocol ?
YES!
>
> - I would like also to share a comment that I have some times heard : why
> do we have a different user interface to manage the same entity depending
> the management protocol we choose ? Is it something unreasonnable to
> expect a common user interface whatever management protocol we use.
> (compare ELM and SNMP).
I've explained why you can't have a common user interface between
two different protocols. Unless, of course, you write a special
application to mimic ELMS with SNMP. But believe me there is
nothing special about the way ELMS displays variables. Besides
we are trying to get away from ELMS.
You will find more and more that vendors all over the industry
will write applications based on MIBs which will do stuff like
draw pictures, graphs, bar charts, and other user-friendly
graphics based on standard MIBs. This is possible because of
the widespread acceptance of SNMP, and standard MIBs. So if we
write applications, you can expect them to be a lot better than
drab screen dumps of data!
Hope this helped.
Anil
|
| > What releases of firmware will support the RFC versions of the MIBs ?
As far as I know, 3.0, which is currently in fieldtest.
> Once you go to that firmware rev do you have to use the RFC MIB
> or is it backwards compatible to the experimental MIB ?
It's compatible in the sense that most of the objects are the same.
However since the MIB has moved out from under the 'experimental'
branch of the MIB tree to under the standard MIB-II, the OID's
have changed; thus an NMS would need to load the new version before
querying it.
Anil
|