Enterasys atx Verweisanleitung
Chapter 11: Traps
11-2
ATX MIB Reference Guide
•
egpNeighborLoss (5) – Not used by the unit.
•
enterpriseSpecific (6) – The unit is reporting some interesting information,
which is contained in the “variable-bindings” portion of the PDU. If the unit
has been configured to require acknowledgments to its Trap PDUs
(sysTrapAck), then the NMS must acknowledge the trap, generally by issuing
a GetRequest for the significant variables involved in generating the trap.
which is contained in the “variable-bindings” portion of the PDU. If the unit
has been configured to require acknowledgments to its Trap PDUs
(sysTrapAck), then the NMS must acknowledge the trap, generally by issuing
a GetRequest for the significant variables involved in generating the trap.
All enterpriseSpecific traps specify the value of sysObjectID.0 (i.e., the
object identifier sysID) as the “enterprise”, and zero as the “specific-trap”.
The “variable-bindings” may contain many pairs of variable names and their
values.
object identifier sysID) as the “enterprise”, and zero as the “specific-trap”.
The “variable-bindings” may contain many pairs of variable names and their
values.
The unit can generate enterpriseSpecific traps in either an Acknowledge or a
Non-Acknowledge mode. In the Non-Acknowledge mode, a single Trap
PDU will be sent to the NMS. This PDU will contain sufficient information
for the NMS to determine the cause of the Trap.
Non-Acknowledge mode. In the Non-Acknowledge mode, a single Trap
PDU will be sent to the NMS. This PDU will contain sufficient information
for the NMS to determine the cause of the Trap.
In Acknowledge mode, the unit will re-send the PDU occasionally (see
sysTrapTime and sysTrapRetry) until it receives an Acknowledgment from
the NMS. The Acknowledgment is defined to be a GetRequest for the
variables associated with the Trap’s cause. Note that Acknowledge mode is
only applicable for enterpriseSpecific traps; that is, only enterpriseSpecific
traps may be re-sent.
sysTrapTime and sysTrapRetry) until it receives an Acknowledgment from
the NMS. The Acknowledgment is defined to be a GetRequest for the
variables associated with the Trap’s cause. Note that Acknowledge mode is
only applicable for enterpriseSpecific traps; that is, only enterpriseSpecific
traps may be re-sent.
Many traps include additional variable bindings, besides the variable binding
which initiated the trap to be generated. The additional variable bindings are
not guaranteed to be present, and/or may be passed in separate Trap PDUs.
which initiated the trap to be generated. The additional variable bindings are
not guaranteed to be present, and/or may be passed in separate Trap PDUs.
The unit organizes its enterpriseSpecific Traps according to one of three
different priorities. The highest priority Traps are sent, and re-sent, until they
are acknowledged. After they are acknowledged (or immediately without
waiting for acknowledgments, if sysTrapAck is False), the next highest
priority Traps are sent, until they are acknowledged. Finally, the lowest
priority Traps are sent, until they are acknowledged. The priority groups are
described below.
different priorities. The highest priority Traps are sent, and re-sent, until they
are acknowledged. After they are acknowledged (or immediately without
waiting for acknowledgments, if sysTrapAck is False), the next highest
priority Traps are sent, until they are acknowledged. Finally, the lowest
priority Traps are sent, until they are acknowledged. The priority groups are
described below.
11.2
PRIORITY 0 TRAPS
Priority 0 Traps are the highest priority enterpriseSpecific Traps, and are only
sent if configAlarmDynamic is True. There is just a single element of this group,
which is the trap that indicates that the unit has booted. That trap always contains
configFatalErr, and is acknowledged by reading configFatalErr. In addition, that
trap may contain any of the following for the modules which were configured to
be used (refer to hwUseMod and rebootUseMod).
sent if configAlarmDynamic is True. There is just a single element of this group,
which is the trap that indicates that the unit has booted. That trap always contains
configFatalErr, and is acknowledged by reading configFatalErr. In addition, that
trap may contain any of the following for the modules which were configured to
be used (refer to hwUseMod and rebootUseMod).