| >I need to understand all the standards our implementation of SNMP on
>Digital UNIX supports i.e. MIB-V2 in detail for a customer requirment.
>More importantly, I need to know if there are any shortcomings we may
>have not put in based on V4.0b...i.e. are we definitively 100%?
To start with, read note 9854.
The SPD lists any limitations/conditions on any Internet Standard
MIBs we implement (the RFCs listed in the SPD, and in note 9854).
So your official answer must come from there.
Off the top of my head, I believe in 4.0b we are 100% compliant
w/ mib-2. We don't permit writes in the other MIBs. And we
don't implement the installed software group of Host MIB.
>Secondly, is there a list of all the traps we support available? I
>haven't seen it yet in the documentation, but I'll continue to search
>around this afternoon.
Traps are part of a MIB specification. Of the 4 RFCs referred to above,
only mib-2 RFC1213 (well, really RFC1157 SNMPv1) defines any traps.
Of those, we support (text taken from RFC1157):
4.1.6.1. The coldStart Trap
A coldStart(0) trap signifies that the sending protocol entity is
reinitializing itself such that the agent's configuration or the
protocol entity implementation may be altered.
4.1.6.3. The linkDown Trap
A linkDown(2) trap signifies that the sending protocol entity
recognizes a failure in one of the communication links represented in
the agent's configuration.
The Trap-PDU of type linkDown contains as the first element of its
variable-bindings, the name and value of the ifIndex instance for the
affected interface.
4.1.6.4. The linkUp Trap
A linkUp(3) trap signifies that the sending protocol entity
recognizes that one of the communication links represented in the
agent's configuration has come up.
The Trap-PDU of type linkUp contains as the first element of its
variable-bindings, the name and value of the ifIndex instance for the
affected interface.
4.1.6.5. The authenticationFailure Trap
An authenticationFailure(4) trap signifies that the sending protocol
entity is the addressee of a protocol message that is not properly
authenticated. While implementations of the SNMP must be capable of
generating this trap, they must also be capable of suppressing the
emission of such traps via an implementation-specific mechanism.
4.1.6.7. The enterpriseSpecific Trap
A enterpriseSpecific(6) trap signifies that the sending protocol
entity recognizes that some enterprise-specific event has occurred.
The specific-trap field identifies the particular trap which
occurred.
The last one is supported at the extensible agent's API, and would only
be generated if some enterprise specific MIB code (subagent) is configured
and raises the trap.
Hope this helps.
Mike
|