| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4307.1 | Here's a start. I'll post details tomorrow. | NETCAD::GALLAGHER | | Wed Mar 26 1997 18:17 | 16 |
| DEChub900 Traps
---------------------------------------------------------------------------
Standard Traps Non-standard Traps
Module Cold Warm Link Link Auth RMON EnterpriseOther
Start Start Up Down Failure A&E
DENMA - DECagent90 Yes No Yes Yes Yes No Yes No
MAM - Hub Manager Yes No Yes Yes Yes Yes Yes No
Stack Director Yes No Yes Yes Yes Yes Yes No
DECrepeater900s Yes No Yes Yes Yes Yes No Yes
DECswitch900 EE/EF Yes No Yes Yes Yes Yes No No.
DECconcentrator900 Yes No Yes Yes Yes No Yes No
DECserver900TM Yes No Yes Yes Yes No tbd No.
---------------------------------------------------------------------------
|
| 4307.2 | | NSDP01::RV | | Thu Mar 27 1997 03:56 | 2 |
| Thanks Already
Robert
|
| 4307.3 | | NETCAD::GALLAGHER | | Thu Mar 27 1997 16:42 | 7 |
| The next two replies contain a collection of information about traps in
NPB products. The next reply contains the .txt file. Following that
is a .htm file. I recommend extracting the .htm file and opening it with
your web browser.
Comments welcome.
-Shawn
|
| 4307.4 | .txt file | NETCAD::GALLAGHER | | Thu Mar 27 1997 16:43 | 655 |
| [Image]
NPB Products - Traps
---------------------------------------------------------------------------
Standard Traps Non-standard Traps
Module Cold Warm Link Link Auth RMON EnterpriseOther
Start Start Up Down Failure A&E
DENMA - DECagent90 Yes No Yes Yes Yes No Yes No
MAM - Hub Manager Yes No Yes Yes Yes Yes Yes No
Stack Director Yes No Yes Yes Yes Yes Yes No
DECrepeater900s Yes No Yes Yes Yes Yes No Yes
DECswitch900 EE/EF Yes No Yes Yes Yes Yes No No
DECconcentrator900 Yes No Yes Yes Yes No Yes No
DECserver900TM Yes No Yes Yes Yes No tbd No
VNswitches Yes Yes Yes Yes Yes tbd tbd tbd
GigaSwitch/FDDI No Yes No No Yes No tbd Yes
GigaSwitch/ATM No Yes No No Yes No tbd tbd
RouteAbout Acc.
EW/EI Yes Yes Yes Yes Yes No Yes No
RouteAbout Central
EW Yes Yes Yes Yes Yes No Yes No
---------------------------------------------------------------------------
Trap Definitions
ColdStart
From RFC 1157:
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.
WarmStart Traps
From RFC 1157:
A warmStart(1) trap signifies that the sending protocol entity is
reinitializing itself such that neither the agent configuration
nor the protocol entity implementation is altered.
The definition of WarmStart traps is vague. Many DEChub900 module
implementors opted to issue ColdStart traps each time a module is
powered-up or reset.
LinkUp and LinkDown
From RFC 1157:
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.
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.
Note that there is a lot of confusion about what a "link" is. The following
are links:
* Switch ports.
* Repeater MACs.
* Serial channels.
* Ethernet management channels.
And the following are not considered links:
* Ethernet repeater ports.
* Token ring MAUs.
* FDDI concentrator ports.
EGP Neighbor Loss Traps
From RFC 1157:
An egpNeighborLoss(5) trap signifies that an EGP neighbor for
whom the sending protocol entity was an EGP peer has been marked
down and the peer relationship no longer obtains.
The Trap-PDU of type egpNeighborLoss contains as the first
element of its variable-bindings, the name and value of the
egpNeighAddr instance for the affected neighbor.
EGP Neighbor Loss traps are also among the "Standard Traps", however, they
are only for some routers: those that support the EGP.
AuthFailure
From RFC 1157:
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.
A typical cause of authentication failure is using the wrong SNMP
community, of using the read-only community when issuing a set.
Enterprise Specific Traps
From RFC 1157:
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.
Enterprise specific traps on Digital hub products include:
---------------------------------------------------------------------------
DENMA Enterprise Specific Traps
DENMA enterprise specific traps are defined in the DENMA's private MIB
Briefly, the following traps are supported:
* consolePasswordFailure
* nonVolatileRamError
* configurationExceeded
* populationChange
* moduleStatusChange
* rptrPortStatusChange
* srvrPortStatusChange
* brdgPortStatusChange
Definitions:
--
--
-- DECagent 90 Trap Definitions
--
-- The following SNMP generic traps are supported by the DECagent 90:
--
-- coldStart(0)
-- warmStart(1)
-- authenticationFailure(4)
--
-- The DECagent 90 also generates the enterpriseSpecific(6) traps defined
-- below.
--
consolePasswordFailure TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"There have been three consecutive failures to enter a correct password
when attempting to log into the DECagent 90 console port."
::= 1
nonVolatileRamError TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"An error in the non-volatile storage on the DECagent 90 has occurred.
Some configuration information may have been lost."
::= 2
configurationExceeded TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"An attempt was made to exceed the maximum configuration supported by
the DECagent 90. The request to create the additional community or to
add the additional module has been rejected."
::= 3
populationChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID }
DESCRIPTION
"A module has been added or discovered, or has been deleted or
undiscovered. The objects dh90PopulationChange and
dh90PopulationLastChange have been updated to reflect this change.
The community index, slot index, and module object id are included in
the trap PDU."
::= 4
moduleStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
dh90SlotProxyStatus }
DESCRIPTION
"A module has become reachable or unreachable. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id and
proxy status are included in the trap PDU."
::= 5
rptrPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
drpt90PortIndex, drpt90PortState }
DESCRIPTION
"The port status has changed on a repeater module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port state are included in the trap PDU."
::= 6
--
-- !! IMPORTANT NOTE FOR SOME MIB COMPILERS !!
--
-- The VARIABLES list has been commented out of the following two trap
-- definitions because some MIB compilers cannot compile trap definitions that
-- specify a VARIABLES list containing objects that are external to this MIB.
--
-- If your MIB compiler can properly compile trap definitions with a VARIABLES
-- list containing external objects, you should uncomment the VARIABLES list
-- for these two trap definitions. If you do so, you must also uncomment the
-- IMPORTS near the beginning of this MIB which import the required objects
-- from their respective RFC.
--
-- Note that regardless of how this MIB is compiled into your NMS application,
-- the trap PDU generated by the DECagent 90 for these traps will contain a
-- varbind list with the objects specified in the VARIABLES list along with
-- their values. It is up to the trap handler on the NMS to decide what to do
-- with this information.
--
srvrPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
-- VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
-- charPortIndex, charPortOperStatus }
DESCRIPTION
"The port status has changed on a terminal server module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port operational status are included in the trap PDU."
::= 7
brdgPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
-- VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
-- ifIndex, ifOperStatus }
DESCRIPTION
"The port status has changed on a bridge module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port operational status are included in the trap PDU."
::= 8
Refer to DENMA Traps for trap definitions. Refer to the DENMA's private MIB
for details.
---------------------------------------------------------------------------
Hub Manager and Stack Director RMON Event Traps
RMON risingEvent and falling event traps are defined in RFC1757. (Compiling
this standard MIB into Netview et.al. enables it to properly decode these
traps.)
-- These definitions use the TRAP-TYPE macro as
-- defined in RFC 1215 [10]
-- Remote Network Monitoring Traps
risingAlarm TRAP-TYPE
ENTERPRISE rmon
VARIABLES { alarmIndex, alarmVariable, alarmSampleType,
alarmValue, alarmRisingThreshold }
DESCRIPTION
"The SNMP trap that is generated when an alarm
entry crosses its rising threshold and generates
an event that is configured for sending SNMP
traps."
::= 1
fallingAlarm TRAP-TYPE
ENTERPRISE rmon
VARIABLES { alarmIndex, alarmVariable, alarmSampleType,
alarmValue, alarmFallingThreshold }
DESCRIPTION
"The SNMP trap that is generated when an alarm
entry crosses its falling threshold and generates
an event that is configured for sending SNMP
traps."
::= 2
The DEChub900's Hub Manager (MAM) and Stack Director support default alarms
and events which come preconfigured with the modules. These defaults are
documented in the product's Owners Manual. Hub Manager defaults include:
Message Which means...
"A network module was A network module (aka "line-card") was inserted
inserted or removed." or removed from the hub's chassis.
"An environmental change A network module's fan failed, or a network
occurred" module is overheating.
A power supply was inserted or removed from the
"A power supply was DEChub900. (Not supported on the Stack Director
inserted or removed." since each Stack 600 module has its own power
supply.
"The DEChub900 no longer Available power has decrease such that all
has N-Plus-1 power power supplies are needed to power the inserted
redundancy" network modules.
"The DEChub900 no longer Available power has increase such that one or
has N-Plus-1 power more power supplies may fail without adversely
redundancy"" affecting the inserted network modules.
The backplane LAN interconnect environment has
"A backplane connection changed. This can be caused through a
change has occurred." management operation via clearVISN, or by a
newly inserted module connection to the
backplane.
"Nonvolatile RAM cannot
accept any additional There is no more memory for additional
parameters." nonvolatile parameters.
"Nonvolatile RAM has A memory fault has been detected. Correct by
failed." resetting to factory defaults, or by replacing
the Hub Manager.
Stack Director defaults include:
Message Which means...
"A network module was A network module (aka "line-card") was inserted
inserted or removed." or removed from the stack.
"An environmental change A network module's fan failed, or a network
occurred" module is overheating.
The backplane LAN interconnect environment has
"A backplane connection changed. This can be caused through a
change has occurred." management operation via clearVISN, or by a
newly inserted module connection to the
backplane.
"Nonvolatile RAM cannot
accept any additional There is no more memory for additional
parameters." nonvolatile parameters.
"Nonvolatile RAM has A memory fault has been detected. Correct by
failed." resetting to factory defaults, or by replacing
the Stack Director.
---------------------------------------------------------------------------
Repeater 900 RMON Event Traps
RMON risingEvent and falling event traps are defined in RFC1757. (Compiling
this standard MIB into Netview et.al. enables it to properly decode these
traps.) All 900 form-factor repeaters with firmware version tbd or higher
support RMON Alarms and Events. Repeaters support default alarms and events
which come preconfigured with the modules. These defaults are documented in
the product's Owners Manual. Repeater defaults include traps for:
Message Which means...
The network module is overheating.
"An environmental change (Standalone only. When installed in a hub
occurred" the Hub Manager sends a trap similar to
this.)
"Nonvolatile RAM cannot
accept any additional There is no more memory for additional
parameters." nonvolatile parameters.
"Nonvolatile RAM has A memory fault has been detected. Correct by
failed." resetting to factory defaults, or by
replacing the Hub Manager.
The network module is overheating.
"An environmental change (Standalone only. When installed in a hub
occurred" the Hub Manager sends a trap similar to
this.)
TBD TBD
---------------------------------------------------------------------------
Hub Manager and Stack Director RMON-Like Event Traps
Version 5.0 and greater Hub Manager and 1.0 and greater Stack Director
modules support the "RMON-Like Alarm and Event Gateway" for 600 series
modules. Two traps are defined by the gateway:
* Enterprise Specific = 1 trap: risingEvent.
* Enterprise Specific = 2 trap: fallingEvent.
Unlike RMON, no default traps are configured for the RMON-like Gateway.
These traps are in the mam-private MIB and are described below:
--
-- RMON-Like Alarm and Event Gateway Traps
--
-- Two traps may be generated. Traps require:
--
-- - That a 'trap-sink' (destination IP address) be configured on
-- the Management Agent Module.
--
-- - That entries in hubEventTable be configured with hubEventType
-- set to either 'snmp-trap(3)' or 'log-and-trap(4)'.
--
-- hubRisingAlarm TRAP-TYPE
-- ENTERPRISE mamPrivate
-- VARIABLES { hubAlarmSlotNumber,
-- hubAlarmIndex,
-- hubAlarmVariable,
-- hubAlarmSampleType,
-- hubAlarmValue,
-- hubAlarmRisingThreshold }
-- DESCRIPTION
-- "The SNMP trap that is generated when an alarm entry crosses its
-- rising threshold and generates an event that is configured for
-- sending SNMP traps.
--
-- The enterprise Object Identifier for this trap is:
--
-- iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).
-- dec(36).ema(2).decMIBextension(18).decHub900(11).
-- mgmtAgent(1).mgmtAgentVersion2(2).mamPrivate(2)
-- "
-- ::= 1
--
-- hubFallingAlarm TRAP-TYPE
-- ENTERPRISE mamPrivate
-- VARIABLES { hubAlarmSlotNumber,
-- hubAlarmIndex,
-- hubAlarmVariable,
-- hubAlarmSampleType,
-- hubAlarmValue,
-- hubAlarmRisingThreshold }
-- DESCRIPTION
-- "The SNMP trap that is generated when an alarm entry crosses its
-- falling threshold and generates an event that is configured for
-- sending SNMP traps.
--
-- The enterprise Object Identifier for this trap is:
--
-- iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).
-- dec(36).ema(2).decMIBextension(18).decHub900(11).
-- mgmtAgent(1).mgmtAgentVersion2(2).mamPrivate(2)
-- "
-- ::= 2
---------------------------------------------------------------------------
DECswitch900 EE/EF RMON Traps
The DECswitch900 EE and EF version 1.7 and greater support RMON Alarms and
Events. Unlike other products, however, the bridge does not support any
default events.
---------------------------------------------------------------------------
Repeater MIB
The Repeater MIB (RFC1516) specifies three optional traps:
* rptrHealth
* rptrGroupChange
* rptrResetEvent
-- Traps for use by Repeaters
-- Traps are defined using the conventions in RFC 1215 [6].
rptrHealth TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrHealth trap conveys information related
to the operational status of the repeater. This
trap is sent either when the value of
rptrOperStatus changes, or upon completion of a
non-disruptive test.
The rptrHealth trap must contain the
rptrOperStatus object. The agent may optionally
include the rptrHealthText object in the varBind
list. See the rptrOperStatus and rptrHealthText
objects for descriptions of the information that
is sent.
The agent must throttle the generation of
consecutive rptrHealth traps so that there is at
least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
hubHealth notification."
::= 1
rptrGroupChange TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrGroupIndex }
DESCRIPTION
"This trap is sent when a change occurs in the
group structure of a repeater. This occurs only
when a group is logically or physically removed
from or added to a repeater. The varBind list
contains the identifier of the group that was
removed or added.
The agent must throttle the generation of
consecutive rptrGroupChange traps for the same
group so that there is at least a five-second gap
between traps of this type. When traps are
throttled, they are dropped, not queued for
sending at a future time. (Note that 'generating'
a trap means sending to all configured
recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
groupMapChange notification."
::= 2
rptrResetEvent TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrResetEvent trap conveys information
related to the operational status of the repeater.
This trap is sent on completion of a repeater
reset action. A repeater reset action is defined
as an a transition to the START state of Fig 9-2
in section 9 [IEEE 802.3 Std], when triggered by a
management command (e.g., an SNMP Set on the
rptrReset object).
The agent must throttle the generation of
consecutive rptrResetEvent traps so that there is
at least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)
The rptrResetEvent trap is not sent when the agent
restarts and sends an SNMP coldStart or warmStart
trap. However, it is recommended that a repeater
agent send the rptrOperStatus object as an
optional object with its coldStart and warmStart
trap PDUs.
The rptrOperStatus object must be included in the
varbind list sent with this trap. The agent may
optionally include the rptrHealthText object as
well."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset
notification."
::= 3
---------------------------------------------------------------------------
Bridge MIB Traps
Neither of the optional bridge MIB (RFC1493) traps are supported by the
DECswitch900 series modules. However, the GigaSwitch products do support
these traps.
Bridge MIB traps include "newRoot" and "topologyChange" - both of which are
described in detail in RFC1493.
-- Traps for use by Bridges
-- Traps for the Spanning Tree Protocol
newRoot TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"The newRoot trap indicates that the sending agent
has become the new root of the Spanning Tree; the
trap is sent by a bridge soon after its election
as the new root, e.g., upon expiration of the
Topology Change Timer immediately subsequent to
its election. Implementation of this trap is
optional."
::= 1
topologyChange TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"A topologyChange trap is sent by a bridge when
any of its configured ports transitions from the
Learning state to the Forwarding state, or from
the Forwarding state to the Blocking state. The
trap is not sent if a newRoot trap is sent for the
same transition. Implementation of this trap is
optional."
::= 2
---------------------------------------------------------------------------
FDDI MIB Traps
There are no traps defined in the FDDI MIB (RFC1512).
---------------------------------------------------------------------------
DECconcentrator 900 Enterprise Specific Port Traps
The DECconcentrator 900 series products support one enterprise specific
trap: the port trap. The port trap conveys information about the change of
an FDDI port's state. For example, a "disconnecting" port causes a port
trap to be sent. Another trap is sent when the port is "connecting". Other
state changes also cause port traps. The port traps is disabled by default.
It may be enabled by setting the esysFddiPortTrapSwitch.
Once enabled, port traps are sent whenever "fddimibPORTConnectState"
changes. "fddimibPORTConnectState" changes as port connections are created
and destroyed (per the SMT spec). Refer to the fddi mib for details about
fddimibPORTConnectState. Port traps are enterprise specific 1 traps
(generic- trap-type = 6, specific-trap-type = 1). Details about which port
was affected, and the new connect state are carried in the "interesting
information" field of the trap message.
The TRAP-TYPE definition went into the products release notes at one point.
decConcentratorPortTrap TRAP-TYPE
ENTERPRISE { elanext } -- This might be wrong!
VARIABLES { fddimibPORTConnectState }
DESCRIPTION
"The value of fddimibPortConnectState has changed.
This is usually caused by a station inserting
into the FDDI ring, or detatching from the ring."
::= 1
People often expect LinkUp and LinkDown traps to be sent when a
concentrator port is affected. This isn't done because of the distinction
between a 'link' and a 'port'. (Refer to Link Traps.).)
---------------------------------------------------------------------------
RouteAbout Access and Central
From COMMON_BROUTERS notes conference, note 160.3:
All comet routers can be configured to generate enterprise
specific traps. You can configure ELS (the event subsystem)
so that some or all ELS events also generate an enterprise
specific trap. For example, you can use the following command
to generate an ELS enterprise specific trap whenever an SNMP ELS
event occurs.
At MOS command prompt
*t 6
Gateway user configuration
Config>event
Event Logging System user configuration
ELS config>trap sub snmp all
ELS config>list all
...
Subsystem: SNMP
Disp levels: STANDARD
Trap levels: ALL
....
Then restart the router.
Refer to http://www-router.lkg.dec.com/~johnp/snmp/mibs/decvars-cc-v1.1.txt
for the Digital version of the Proteon enterprise MIB variables that
includes Proteon supplied definitions of the ELS trap types.
|
| 4307.5 | .htm file | NETCAD::GALLAGHER | | Thu Mar 27 1997 16:44 | 960 |
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html><head>
<title>NPB Products - Traps
</title></head><body>
<center><img src = "digital_logo.gif"></center>
<h1 align=center>NPB Products - Traps</h1>
<hr>
<center>
<table border>
<tr>
<td></td>
<td align=center colspan=5><b>Standard Traps</b></td>
<td align=center colspan=3><b>Non-standard Traps</b></td>
</tr>
<td align=center><b>Module</b></td>
<td align=center><b><a href="#cold">Cold Start</a></b></td>
<td align=center><b><a href="#warm">Warm Start</a></b></td>
<td align=center><b><a href="#link">Link Up</a></b></td>
<td align=center><b><a href="#link">Link Down</a></b></td>
<td align=center><b><a href="#auth">Auth Failure</a></b></td>
<td align=center><b>RMON A&E</b></td>
<td align=center><b><a href="#ent">Enterprise</a></b></td>
<td align=center><b>Other</b></td>
<tr>
<td align=left>DENMA - DECagent90</td>
<td align=center>Yes</td>
<td align=center>No</td>
<td align=center>Yes</td>
<td align=center>Yes</td>
<td align=center>Yes</td>
<td align=center>No</td>
<td align=center><a href="#denma">Yes</a></td>
<td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>MAM - Hub Manager</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#mamRmon">Yes</a></td>
<! Enter> <td align=center><a href="#mamRmonLike">Yes</a></td>
<! Other> <td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>Stack Director</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#stackRmon">Yes</a></td>
<! Enter> <td align=center><a href="#stackRmonLike">Yes</a></td>
<! Other> <td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>DECrepeater900s</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#repeaterRmon">Yes</a></td>
<! Enter> <td align=center>No</td>
<! Other> <td align=center><a href="#repeater">Yes</a></td>
</tr>
<tr>
<! Module> <td align=left>DECswitch900 EE/EF</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#switchRmon">Yes</a></td>
<! Enter> <td align=center>No</td>
<! Other> <td align=center><a href="#bridgeMIB">No</a></td>
</tr>
<tr>
<! Module> <td align=left>DECconcentrator900</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center><a href="#port">Yes</a></td>
<! Other> <td align=center><a href="#fddiMIB">No</a></td>
</tr>
<tr>
<! Module> <td align=left>DECserver900TM</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center>tbd</td>
<! Other> <td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>VNswitches</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>Yes</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>tbd</td>
<! Enter> <td align=center>tbd</td>
<! Other> <td align=center>tbd</td>
</tr>
<tr>
<! Module> <td align=left>GigaSwitch/FDDI</td>
<! Cold> <td align=center>No</td>
<! Warm> <td align=center>Yes</td>
<! LUp> <td align=center>No</td>
<! LDown> <td align=center>No</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center>tbd</td>
<! Other> <td align=center><a href="#bridgeMIB">Yes</a></td>
</tr>
<tr>
<! Module> <td align=left>GigaSwitch/ATM</td>
<! Cold> <td align=center>No</td>
<! Warm> <td align=center>Yes</td>
<! LUp> <td align=center>No</td>
<! LDown> <td align=center>No</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center>tbd</td>
<! Other> <td align=center>tbd</td>
</tr>
<tr>
<! Module> <td align=left>RouteAbout Acc. EW/EI</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>Yes</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center><a href="#rAbout">Yes</a></td>
<! Other> <td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>RouteAbout Central EW</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>Yes</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center><a href="#rAbout">Yes</a></td>
<! Other> <td align=center>No</td>
</tr>
</table></center>
<pre>
</pre>
<hr>
<h2>Trap Definitions</h2>
<a name="cold"><h3>ColdStart</h3></a>
From RFC 1157:
<blockquote>
<i>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.</i>
</blockquote>
<a name="warm"><h3>WarmStart Traps</h3></a>
From RFC 1157:
<blockquote>
<i>A warmStart(1) trap signifies that the sending protocol entity is
reinitializing itself such that neither the agent configuration nor
the protocol entity implementation is altered.</i>
</blockquote>
The definition of WarmStart traps is vague. Many DEChub900 module implementors
opted to issue ColdStart traps
each time a module is powered-up or reset.
<a name="link"><h3>LinkUp and LinkDown</h3></a>
From RFC 1157:
<blockquote>
<i>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.
<p>
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.
<p>
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.
<p>
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.</i>
</blockquote>
Note that there is a lot of confusion about what a "link" is. The following are
links:
<ul>
<li>Switch ports.
<li>Repeater MACs.
<li>Serial channels.
<li>Ethernet management channels.
</ul>
And the following are <b>not</b> considered links:
<ul>
<li>Ethernet repeater ports.
<li>Token ring MAUs.
<li>FDDI concentrator ports.
</ul>
<a name="egp"><h3>EGP Neighbor Loss Traps</h3></a>
From RFC 1157:
<blockquote>
<i>An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
the sending protocol entity was an EGP peer has been marked down and
the peer relationship no longer obtains.
<p>
The Trap-PDU of type egpNeighborLoss contains as the first element of
its variable-bindings, the name and value of the egpNeighAddr
instance for the affected neighbor.</i>
</blockquote>
EGP Neighbor Loss traps are also among the "Standard Traps", however, they
are only for some routers: those that support the EGP.
<a name="auth"><h3>AuthFailure</h3></a>
From RFC 1157:
<blockquote>
<i>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.</i>
</blockquote>
A typical cause of authentication failure is using the wrong SNMP community,
of using the read-only community when issuing a set.
<a name="ent"><h3>Enterprise Specific Traps</h3></a>
From RFC 1157:
<blockquote>
<i>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.</i>
</blockquote>
Enterprise specific traps on Digital hub products include:
<cneter><table>
<th>Enterprise</th>
<th>Specific</th>
<th>Description</th>
<th>More</th>
<tr>
<td>DECconcentrator 900</td>
<td>1</td>
<td>"Port" trap. Sent when stations attaches or detaches to/from a
concentrator port.</td>
<td><a href="">More</a></td>
<tr>
<tr>
<td>Hub Manager and Stack Director</td>
<td>1</td>
<td>RMON-Like Gateway rising event trap.</td>
<td><a href="">ore</a></td>
<tr>
<tr>
<td>Hub Manager and Stack Director</td>
<td>2</td>
<td>RMON-Like Gateway rising event trap.</td>
<td><a href="">More</a></td>
<tr>
<hr>
<a name="denma"><h2>DENMA Enterprise Specific Traps</h2></a>
DENMA enterprise specific traps are defined in the
<a href="http://npbwww.hpn.lkg.dec.com:80/dr/hubs/mibs/hub90v30.txt">
DENMA's private MIB</a>
Briefly, the following traps are supported:
<ul>
<li>consolePasswordFailure
<li>nonVolatileRamError
<li>configurationExceeded
<li>populationChange
<li>moduleStatusChange
<li>rptrPortStatusChange
<li>srvrPortStatusChange
<li>brdgPortStatusChange
</ul>
Definitions:
<pre>
--
--
-- DECagent 90 Trap Definitions
--
-- The following SNMP generic traps are supported by the DECagent 90:
--
-- coldStart(0)
-- warmStart(1)
-- authenticationFailure(4)
--
-- The DECagent 90 also generates the enterpriseSpecific(6) traps defined
-- below.
--
consolePasswordFailure TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"There have been three consecutive failures to enter a correct password
when attempting to log into the DECagent 90 console port."
::= 1
nonVolatileRamError TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"An error in the non-volatile storage on the DECagent 90 has occurred.
Some configuration information may have been lost."
::= 2
configurationExceeded TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"An attempt was made to exceed the maximum configuration supported by
the DECagent 90. The request to create the additional community or to
add the additional module has been rejected."
::= 3
populationChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID }
DESCRIPTION
"A module has been added or discovered, or has been deleted or
undiscovered. The objects dh90PopulationChange and
dh90PopulationLastChange have been updated to reflect this change.
The community index, slot index, and module object id are included in
the trap PDU."
::= 4
moduleStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
dh90SlotProxyStatus }
DESCRIPTION
"A module has become reachable or unreachable. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id and
proxy status are included in the trap PDU."
::= 5
rptrPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
drpt90PortIndex, drpt90PortState }
DESCRIPTION
"The port status has changed on a repeater module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port state are included in the trap PDU."
::= 6
--
-- !! IMPORTANT NOTE FOR SOME MIB COMPILERS !!
--
-- The VARIABLES list has been commented out of the following two trap
-- definitions because some MIB compilers cannot compile trap definitions that
-- specify a VARIABLES list containing objects that are external to this MIB.
--
-- If your MIB compiler can properly compile trap definitions with a VARIABLES
-- list containing external objects, you should uncomment the VARIABLES list
-- for these two trap definitions. If you do so, you must also uncomment the
-- IMPORTS near the beginning of this MIB which import the required objects
-- from their respective RFC.
--
-- Note that regardless of how this MIB is compiled into your NMS application,
-- the trap PDU generated by the DECagent 90 for these traps will contain a
-- varbind list with the objects specified in the VARIABLES list along with
-- their values. It is up to the trap handler on the NMS to decide what to do
-- with this information.
--
srvrPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
-- VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
-- charPortIndex, charPortOperStatus }
DESCRIPTION
"The port status has changed on a terminal server module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port operational status are included in the trap PDU."
::= 7
brdgPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
-- VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
-- ifIndex, ifOperStatus }
DESCRIPTION
"The port status has changed on a bridge module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port operational status are included in the trap PDU."
::= 8
</pre>
Refer to <a href="#denmaTraps"> DENMA Traps</a> for trap definitions.
Refer to the <a href="http://npbwww.hpn.lkg.dec.com:80/dr/hubs/mibs/hub90v30.txt">
DENMA's private MIB</a> for details.
<p>
<hr>
<a name="mamRmon"></a>
<a name="stackRmon"><h2>Hub Manager and Stack Director
RMON Event Traps</h2></a>
RMON risingEvent and falling event traps are defined in RFC1757.
(Compiling this standard MIB into Netview et.al. enables it to properly decode
these traps.)
<pre>
-- These definitions use the TRAP-TYPE macro as
-- defined in RFC 1215 [10]
-- Remote Network Monitoring Traps
risingAlarm TRAP-TYPE
ENTERPRISE rmon
VARIABLES { alarmIndex, alarmVariable, alarmSampleType,
alarmValue, alarmRisingThreshold }
DESCRIPTION
"The SNMP trap that is generated when an alarm
entry crosses its rising threshold and generates
an event that is configured for sending SNMP
traps."
::= 1
fallingAlarm TRAP-TYPE
ENTERPRISE rmon
VARIABLES { alarmIndex, alarmVariable, alarmSampleType,
alarmValue, alarmFallingThreshold }
DESCRIPTION
"The SNMP trap that is generated when an alarm
entry crosses its falling threshold and generates
an event that is configured for sending SNMP
traps."
::= 2
</pre>
The DEChub900's Hub Manager (MAM) and Stack Director support default
alarms and events which come preconfigured with the modules.
These defaults are documented in the product's Owners Manual.
Hub Manager defaults include:
<pre>
</pre>
<center><table border>
<th>Message</th>
<th>Which means...</th>
<tr>
<td>"A network module was inserted or removed."</td>
<td>A network module (aka "line-card") was inserted or removed
from the hub's chassis.</td>
</tr>
<tr>
<td>"An environmental change occurred"</td>
<td>A network module's fan failed, or a network module is overheating.</td>
</tr>
<tr>
<td>"A power supply was inserted or removed."</td>
<td>A power supply was inserted or removed from the DEChub900.
(Not supported on the Stack Director since each Stack 600 module has its
own power supply.</td>
</tr>
<tr>
<td>"The DEChub900 no longer has N-Plus-1 power redundancy"</td>
<td>Available power has decrease such that all power supplies are
needed to power the inserted network modules.</td>
</tr>
<tr>
<td>"The DEChub900 no longer has N-Plus-1 power redundancy""</td>
<td>Available power has increase such that one or more power supplies
may fail without adversely affecting the inserted network modules.</td>
</tr>
<tr>
<td>"A backplane connection change has occurred."</td>
<td>The backplane LAN interconnect environment has changed. This can be caused
through a management operation via clearVISN, or by a newly inserted
module connection to the backplane.</td>
</tr>
<tr>
<td>"Nonvolatile RAM cannot accept any additional parameters."</td>
<td>There is no more memory for additional nonvolatile parameters.</td>
</tr>
<tr>
<td>"Nonvolatile RAM has failed."</td>
<td>A memory fault has been detected. Correct by resetting to factory
defaults, or by replacing the Hub Manager.</td>
</tr>
</center></table>
<pre>
</pre>
Stack Director defaults include:
<pre>
</pre>
<center><table border>
<th>Message</th>
<th>Which means...</th>
<tr>
<td>"A network module was inserted or removed."</td>
<td>A network module (aka "line-card") was inserted or removed
from the stack.</td>
</tr>
<tr>
<td>"An environmental change occurred"</td>
<td>A network module's fan failed, or a network module is overheating.</td>
</tr>
<tr>
<td>"A backplane connection change has occurred."</td>
<td>The backplane LAN interconnect environment has changed. This can be caused
through a management operation via clearVISN, or by a newly inserted
module connection to the backplane.</td>
</tr>
<tr>
<td>"Nonvolatile RAM cannot accept any additional parameters."</td>
<td>There is no more memory for additional nonvolatile parameters.</td>
</tr>
<tr>
<td>"Nonvolatile RAM has failed."</td>
<td>A memory fault has been detected. Correct by resetting to factory
defaults, or by replacing the Stack Director.</td>
</tr>
</center></table>
<hr>
<a name="repeaterRmon"><h2>Repeater 900 RMON Event Traps</h2></a>
RMON risingEvent and falling event traps are defined in RFC1757.
(Compiling this standard MIB into Netview et.al. enables it to properly decode
these traps.)
All 900 form-factor repeaters with firmware version tbd or higher support RMON
Alarms and Events.
Repeaters support default alarms and events which come preconfigured with the modules.
These defaults are documented in the product's Owners Manual.
Repeater defaults include traps for:
<pre>
</pre>
<center><table border>
<th>Message</th>
<th>Which means...</th>
<tr>
<td>"An environmental change occurred"</td>
<td>The network module is overheating. (Standalone only. When installed
in a hub the Hub Manager sends a trap similar to this.)</td>
</tr>
<tr>
<td>"Nonvolatile RAM cannot accept any additional parameters."</td>
<td>There is no more memory for additional nonvolatile parameters.</td>
</tr>
<tr>
<td>"Nonvolatile RAM has failed."</td>
<td>A memory fault has been detected. Correct by resetting to factory
defaults, or by replacing the Hub Manager.</td>
</tr>
<tr>
<td>"An environmental change occurred"</td>
<td>The network module is overheating. (Standalone only. When installed
in a hub the Hub Manager sends a trap similar to this.)</td>
</tr>
<tr>
<td><b>TBD</b></td>
<td><b>TBD</b></td>
</tr>
</center></table>
<hr>
<a name="mamRmonLike"></a>
<a name="stackRmonLike"><h2>Hub Manager and Stack Director
RMON-Like Event Traps</h2></a>
Version 5.0 and greater Hub Manager and 1.0 and greater Stack Director modules
support the "RMON-Like Alarm and Event Gateway" for 600 series modules.
Two traps are defined by the gateway:
<ul>
<li>Enterprise Specific = 1 trap: risingEvent.
<li>Enterprise Specific = 2 trap: fallingEvent.
</ul>
Unlike RMON, no default traps are configured for the RMON-like Gateway.
These traps are in the mam-private MIB and are described below:
<pre>
--
-- RMON-Like Alarm and Event Gateway Traps
--
-- Two traps may be generated. Traps require:
--
-- - That a 'trap-sink' (destination IP address) be configured on
-- the Management Agent Module.
--
-- - That entries in hubEventTable be configured with hubEventType
-- set to either 'snmp-trap(3)' or 'log-and-trap(4)'.
--
-- hubRisingAlarm TRAP-TYPE
-- ENTERPRISE mamPrivate
-- VARIABLES { hubAlarmSlotNumber,
-- hubAlarmIndex,
-- hubAlarmVariable,
-- hubAlarmSampleType,
-- hubAlarmValue,
-- hubAlarmRisingThreshold }
-- DESCRIPTION
-- "The SNMP trap that is generated when an alarm entry crosses its
-- rising threshold and generates an event that is configured for
-- sending SNMP traps.
--
-- The enterprise Object Identifier for this trap is:
--
-- iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).
-- dec(36).ema(2).decMIBextension(18).decHub900(11).
-- mgmtAgent(1).mgmtAgentVersion2(2).mamPrivate(2)
-- "
-- ::= 1
--
-- hubFallingAlarm TRAP-TYPE
-- ENTERPRISE mamPrivate
-- VARIABLES { hubAlarmSlotNumber,
-- hubAlarmIndex,
-- hubAlarmVariable,
-- hubAlarmSampleType,
-- hubAlarmValue,
-- hubAlarmRisingThreshold }
-- DESCRIPTION
-- "The SNMP trap that is generated when an alarm entry crosses its
-- falling threshold and generates an event that is configured for
-- sending SNMP traps.
--
-- The enterprise Object Identifier for this trap is:
--
-- iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).
-- dec(36).ema(2).decMIBextension(18).decHub900(11).
-- mgmtAgent(1).mgmtAgentVersion2(2).mamPrivate(2)
-- "
-- ::= 2
</pre>
<hr>
<a name="switchRmon"><h2>DECswitch900 EE/EF RMON Traps</h2></a>
The DECswitch900 EE and EF version 1.7 and greater support RMON Alarms and Events.
Unlike other products, however, the bridge does not support any default events.
<hr>
<a name="repeater"><h2>Repeater MIB</h2></a>
The Repeater MIB (RFC1516) specifies three <b>optional</b> traps:
<ul>
<li>rptrHealth
<li>rptrGroupChange
<li>rptrResetEvent
</ul>
<pre>
-- Traps for use by Repeaters
-- Traps are defined using the conventions in RFC 1215 [6].
rptrHealth TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrHealth trap conveys information related
to the operational status of the repeater. This
trap is sent either when the value of
rptrOperStatus changes, or upon completion of a
non-disruptive test.
The rptrHealth trap must contain the
rptrOperStatus object. The agent may optionally
include the rptrHealthText object in the varBind
list. See the rptrOperStatus and rptrHealthText
objects for descriptions of the information that
is sent.
The agent must throttle the generation of
consecutive rptrHealth traps so that there is at
least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
hubHealth notification."
::= 1
rptrGroupChange TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrGroupIndex }
DESCRIPTION
"This trap is sent when a change occurs in the
group structure of a repeater. This occurs only
when a group is logically or physically removed
from or added to a repeater. The varBind list
contains the identifier of the group that was
removed or added.
The agent must throttle the generation of
consecutive rptrGroupChange traps for the same
group so that there is at least a five-second gap
between traps of this type. When traps are
throttled, they are dropped, not queued for
sending at a future time. (Note that 'generating'
a trap means sending to all configured
recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
groupMapChange notification."
::= 2
rptrResetEvent TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrResetEvent trap conveys information
related to the operational status of the repeater.
This trap is sent on completion of a repeater
reset action. A repeater reset action is defined
as an a transition to the START state of Fig 9-2
in section 9 [IEEE 802.3 Std], when triggered by a
management command (e.g., an SNMP Set on the
rptrReset object).
The agent must throttle the generation of
consecutive rptrResetEvent traps so that there is
at least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)
The rptrResetEvent trap is not sent when the agent
restarts and sends an SNMP coldStart or warmStart
trap. However, it is recommended that a repeater
agent send the rptrOperStatus object as an
optional object with its coldStart and warmStart
trap PDUs.
The rptrOperStatus object must be included in the
varbind list sent with this trap. The agent may
optionally include the rptrHealthText object as
well."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset
notification."
::= 3
</pre>
<hr>
<a name="bridgeMIB"><h2>Bridge MIB Traps</h2></a>
Neither of the <b>optional</b> bridge MIB (RFC1493) traps are supported
by the DECswitch900 series modules. However, the GigaSwitch products do support
these traps.
<p>
Bridge MIB traps include "newRoot" and "topologyChange" - both of which
are described in detail in RFC1493.
<pre>
-- Traps for use by Bridges
-- Traps for the Spanning Tree Protocol
newRoot TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"The newRoot trap indicates that the sending agent
has become the new root of the Spanning Tree; the
trap is sent by a bridge soon after its election
as the new root, e.g., upon expiration of the
Topology Change Timer immediately subsequent to
its election. Implementation of this trap is
optional."
::= 1
topologyChange TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"A topologyChange trap is sent by a bridge when
any of its configured ports transitions from the
Learning state to the Forwarding state, or from
the Forwarding state to the Blocking state. The
trap is not sent if a newRoot trap is sent for the
same transition. Implementation of this trap is
optional."
::= 2
</pre>
<hr>
<a name="fddiMIB"><h2>FDDI MIB Traps</h2></a>
There are no traps defined in the FDDI MIB (RFC1512).
<hr>
<a name="port"><h2>DECconcentrator 900 Enterprise Specific Port Traps</h2></a>
The DECconcentrator 900 series products support one enterprise specific trap:
the port trap.
The port trap conveys information about the change of an FDDI
port's state. For example, a "disconnecting" port causes a
port trap to be sent. Another trap is sent when the port is
"connecting". Other state changes also cause port traps.
The port traps is disabled by default. It may be enabled by
setting the esysFddiPortTrapSwitch.
<p>
Once enabled, port traps are sent whenever "fddimibPORTConnectState"
changes. "fddimibPORTConnectState" changes as port connections are created and
destroyed (per the SMT spec). Refer to the fddi mib for details about
fddimibPORTConnectState. Port traps are enterprise specific 1 traps (generic-
trap-type = 6, specific-trap-type = 1). Details about which port was
affected, and the new connect state are carried in the "interesting
information" field of the trap message.
<p>
The TRAP-TYPE definition went into the products release notes at one
point.
<pre>
decConcentratorPortTrap TRAP-TYPE
ENTERPRISE { elanext } -- This might be wrong!
VARIABLES { fddimibPORTConnectState }
DESCRIPTION
"The value of fddimibPortConnectState has changed.
This is usually caused by a station inserting
into the FDDI ring, or detatching from the ring."
::= 1
</pre>
People often expect LinkUp and LinkDown traps to be sent when a concentrator
port is affected. This isn't done because of the distinction between a
'link' and a 'port'.
(Refer to <a href="#link"> Link Traps.)</a>.)
<p>
<hr>
<a name="rAbout"><h2>RouteAbout Access and Central</h2></a>
From COMMON_BROUTERS notes conference, note 160.3:
<pre>
All comet routers can be configured to generate enterprise
specific traps. You can configure ELS (the event subsystem)
so that some or all ELS events also generate an enterprise
specific trap. For example, you can use the following command
to generate an ELS enterprise specific trap whenever an SNMP ELS
event occurs.
At MOS command prompt
*t 6
Gateway user configuration
Config>event
Event Logging System user configuration
ELS config>trap sub snmp all
ELS config>list all
...
Subsystem: SNMP
Disp levels: STANDARD
Trap levels: ALL
....
Then restart the router.
</pre>
Refer to <a href="http://www-router.lkg.dec.com/~johnp/snmp/mibs/decvars-cc-v1.1.txt">
http://www-router.lkg.dec.com/~johnp/snmp/mibs/decvars-cc-v1.1.txt</a>
for the Digital version of the Proteon enterprise MIB variables that
includes Proteon supplied definitions of the ELS trap types.
</body>
</html>
|
| 4307.6 | GIGAswitch/ATM update | NPSS::NEWTON | Thomas Newton | Fri Mar 28 1997 02:02 | 15 |
|
The information in .4 concerning the GIGAswitch/ATM is not correct. Today,
we implement the traps shown on the first line below. When the Version 2.5
firmware comes out, it will add support for RMON alarms and events.
---------------------------------------------------------------------------
Standard Traps Non-standard Traps
Module Cold Warm Link Link Auth RMON EnterpriseOther
Start Start Up Down Failure A&E
---------------------------------------------------------------------------
GS/ATM - current Yes No Yes Yes Yes No No ILMI*
GS/ATM - FW V2.5 Yes No Yes Yes Yes Yes tbd ILMI*
---------------------------------------------------------------------------
*ILMI traps are sent to peer ATM nodes, rather than to a management station
|
| 4307.7 | updated .txt file | NETCAD::GALLAGHER | | Wed Apr 02 1997 18:18 | 944 |
| [Image]
NPB Products - Traps
---------------------------------------------------------------------------
Standard Traps Non-standard Traps
Module Cold Warm Link Link Auth RMON EnterpriseOther
Start Start Up Down Failure A&E
DENMA - DECagent90 Yes No Yes Yes Yes No Yes No
MAM - Hub Manager Yes No Yes Yes Yes Yes Yes No
Stack Director Yes No Yes Yes Yes Yes Yes No
PORTswitch900s(list) Yes No Yes Yes Yes Yes No Yes
DECrepeater900s(list) Yes No Yes Yes Yes Yes No Yes
DECswitch900 EE/EF/FO Yes No Yes Yes Yes Yes No No
PEswitch 900TX Yes No Yes Yes Yes Yes No No
DECbridge 900MX Yes No Yes Yes Yes Yes No No
DECconcentrator900s
(list) Yes No Yes Yes Yes No Yes No
DECserver900TM Yes No Yes Yes Yes No tbd No
VNswitches (list) Yes Yes Yes Yes Yes tbd tbd tbd
GigaSwitch/FDDI No Yes No No Yes No tbd Yes
GigaSwitch/ATM <2.5 Yes No Yes Yes Yes No No ILMI
GigaSwitch/ATM >=2.5 Yes No Yes Yes Yes Yes No ILMI
RouteAbout Acc. EW/EI Yes Yes Yes Yes Yes No Yes No
RouteAbout Central EW Yes Yes Yes Yes Yes No Yes No
---------------------------------------------------------------------------
Trap Definitions
ColdStart
From RFC 1157:
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.
WarmStart Traps
From RFC 1157:
A warmStart(1) trap signifies that the sending protocol entity is
reinitializing itself such that neither the agent configuration
nor the protocol entity implementation is altered.
The definition of WarmStart traps is vague. Many DEChub900 module
implementors opted to issue ColdStart traps each time a module is
powered-up or reset.
LinkUp and LinkDown
From RFC 1157:
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.
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.
Note that there is a lot of confusion about what a "link" is. The following
are links:
* Switch ports.
* Repeater MACs.
* Serial channels.
* Ethernet management channels.
And the following are not considered links:
* Ethernet repeater ports.
* Token ring MAUs.
* FDDI concentrator ports.
EGP Neighbor Loss Traps
From RFC 1157:
An egpNeighborLoss(5) trap signifies that an EGP neighbor for
whom the sending protocol entity was an EGP peer has been marked
down and the peer relationship no longer obtains.
The Trap-PDU of type egpNeighborLoss contains as the first
element of its variable-bindings, the name and value of the
egpNeighAddr instance for the affected neighbor.
EGP Neighbor Loss traps are also amoung the "Standard Traps", however, they
are only for some routers: those that support the EGP.
AuthFailure
From RFC 1157:
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.
A typical cause of authentication failure is using the wrong SNMP
community, of using the read-only community when issuing a set.
Enterprise Specific Traps
From RFC 1157:
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.
Enterprise specific traps on Digital hub products include:
---------------------------------------------------------------------------
DENMA Enterprise Specific Traps
DENMA enterprise specific traps are defined in the DENMA's private MIB
Breifly, the following traps are supported:
* consolePasswordFailure
* nonVolatileRamError
* configurationExceeded
* populationChange
* moduleStatusChange
* rptrPortStatusChange
* srvrPortStatusChange
* brdgPortStatusChange
Definitions:
--
--
-- DECagent 90 Trap Definitions
--
-- The following SNMP generic traps are supported by the DECagent 90:
--
-- coldStart(0)
-- warmStart(1)
-- authenticationFailure(4)
--
-- The DECagent 90 also generates the enterpriseSpecific(6) traps defined
-- below.
--
consolePasswordFailure TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"There have been three consecutive failures to enter a correct password
when attempting to log into the DECagent 90 console port."
::= 1
nonVolatileRamError TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"An error in the non-volatile storage on the DECagent 90 has occurred.
Some configuration information may have been lost."
::= 2
configurationExceeded TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"An attempt was made to exceed the maximum configuration supported by
the DECagent 90. The request to create the additional community or to
add the additional module has been rejected."
::= 3
populationChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID }
DESCRIPTION
"A module has been added or discovered, or has been deleted or
undiscovered. The objects dh90PopulationChange and
dh90PopulationLastChange have been updated to reflect this change.
The community index, slot index, and module object id are included in
the trap PDU."
::= 4
moduleStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
dh90SlotProxyStatus }
DESCRIPTION
"A module has become reachable or unreachable. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id and
proxy status are included in the trap PDU."
::= 5
rptrPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
drpt90PortIndex, drpt90PortState }
DESCRIPTION
"The port status has changed on a repeater module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port state are included in the trap PDU."
::= 6
--
-- !! IMPORTANT NOTE FOR SOME MIB COMPILERS !!
--
-- The VARIABLES list has been commented out of the following two trap
-- definitions because some MIB compilers cannot compile trap definitions that
-- specify a VARIABLES list containing objects that are external to this MIB.
--
-- If your MIB compiler can properly compile trap definitions with a VARIABLES
-- list containing external objects, you should uncomment the VARIABLES list
-- for these two trap definitions. If you do so, you must also uncomment the
-- IMPORTS near the beginning of this MIB which import the required objects
-- from their respective RFC.
--
-- Note that regardless of how this MIB is compiled into your NMS application,
-- the trap PDU generated by the DECagent 90 for these traps will contain a
-- varbind list with the objects specified in the VARIABLES list along with
-- their values. It is up to the trap handler on the NMS to decide what to do
-- with this information.
--
srvrPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
-- VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
-- charPortIndex, charPortOperStatus }
DESCRIPTION
"The port status has changed on a terminal server module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port operational status are included in the trap PDU."
::= 7
brdgPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
-- VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
-- ifIndex, ifOperStatus }
DESCRIPTION
"The port status has changed on a bridge module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port operational status are included in the trap PDU."
::= 8
Refer to DENMA Traps for trap definitions. Refer to the DENMA's private MIB
for details.
---------------------------------------------------------------------------
Hub Manager and Stack Director RMON Event Traps
RMON risingEvent and falling event traps are defined in RFC1757. (Compiling
this standard MIB into Netview et.al. enables it to properly decode these
traps.)
-- These definitions use the TRAP-TYPE macro as
-- defined in RFC 1215 [10]
-- Remote Network Monitoring Traps
risingAlarm TRAP-TYPE
ENTERPRISE rmon
VARIABLES { alarmIndex, alarmVariable, alarmSampleType,
alarmValue, alarmRisingThreshold }
DESCRIPTION
"The SNMP trap that is generated when an alarm
entry crosses its rising threshold and generates
an event that is configured for sending SNMP
traps."
::= 1
fallingAlarm TRAP-TYPE
ENTERPRISE rmon
VARIABLES { alarmIndex, alarmVariable, alarmSampleType,
alarmValue, alarmFallingThreshold }
DESCRIPTION
"The SNMP trap that is generated when an alarm
entry crosses its falling threshold and generates
an event that is configured for sending SNMP
traps."
::= 2
The DEChub900's Hub Manager (MAM) and Stack Director support default alarms
and events which come preconfigured with the modules. These defaults are
documented in the product's Owners Manual. Hub Manager defaults include:
Message Which means...
"A network module was A network module (aka "line-card") was inserted
inserted or removed." or removed from the hub's chassis.
"An environmental change A network module's fan failed, or a network
occured" module is overheating.
A power supply was inserted or removed from the
"A power supply was DEChub900. (Not supported on the Stack Director
inserted or removed." since each Stack 600 module has its own power
supply.
"The DEChub900 no longer Available power has decrease such that all
has N-Plus-1 power power supplies are needed to power the inserted
redundancy" network modules.
"The DEChub900 no longer Available power has increase such that one or
has N-Plus-1 power more power supplies may fail without adversely
redundancy"" affecting the inserted network modules.
The backplane LAN interconnect environment has
"A backplane connection changed. This can be caused through a
change has occurred." management operation via clearVISN, or by a
newly inserted module connection to the
backplane.
"Nonvolatile RAM cannot
accept any additional There is no more memory for additional
parameters." nonvolatile parameters.
"Nonvolatile memory has A memory fault has been detected. Correct by
failed." resetting to factory defaults, or by replacing
the Hub Manager.
Stack Director defaults include:
Message Which means...
"A network module was A network module (aka "line-card") was inserted
inserted or removed." or removed from the stack.
"An environmental change A network module's fan failed, or a network
occured" module is overheating.
The backplane LAN interconnect environment has
"A backplane connection changed. This can be caused through a
change has occurred." management operation via clearVISN, or by a
newly inserted module connection to the
backplane.
"Nonvolatile RAM connot
accept any additional There is no more memory for additional
parameters." nonvolatile parameters.
"Nonvolatile memory has A memory fault has been detected. Correct by
failed." resetting to factory defaults, or by replacing
the Stack Director.
---------------------------------------------------------------------------
Repeater 900 RMON Event Traps
RMON risingEvent and falling event traps are defined in RFC1757. (Compiling
this standard MIB into Netview et.al. enables it to properly decode these
traps.) All 900 form-factor repeaters and PORTswitches listed below support
RMON Alarms and Events.
RMON Support on Repeaters and PORTswitches
Product Name FW Ver Product Description
The DECrepeater 900TM is an 802.3 10BaseT
(twisted-pair) 32-port repeater for use with either
100-ohm shielded or unshielded twisted-pair wire. The
DECrepeater DECrepeater 900TM can be used in the DEChub 900
900 TM v2.0 MultiSwitch or as a standalone repeater in the DEChub
(DETMM) ONE single-slot hub. In the DEChub 900MS, the
DECrepeater 900TM can sit on either the ThinWire or
IMB backplane, or both, and makes full use of the IRB
capabilities of the hub count as one repeater hop
when configuring per the 802.3 Repeater Rules.
The DECrepeater 900GM is a full-height, 24-port,
10BaseT, Ethernet repeater containing 24 10BaseT
DECrepeater ports on two 50-pin Telco connectors, an external
900 GM v2.0 attachment unit interface (AUI) port, and module and
(DETTM) network status LEDs. The module can be configured in
the DEChub 900 MultiSwitch and can be configured
standalone in the DEChub ONE.
The PORTswitch 900CP (DECPM) is a 16 port (BNC)
PORTswitch thinwire repeater. It has all the functionality
900 CP v2.1.1 currently provided by the DECMR with the addition of
(DECPM) per-port switching. This module also has a built in
management agent and port level security.
The PORTswitch 900FP is a 12-port, 10BaseFL,
fiber-optic, Ethernet repeater that can be configured
into a DEChub 900 MultiSwitch. One or more PORTswitch
900FP modules (up to eight) can be installed into the
DEChub 900. The module can also serve as a standalone
PORTswitch unit when configured with a DEChub ONE docking
900 FP v2.1.1 station.
(DEFMM)
The front panel of the PORTswitch 900FP provides 12
fiber-optic ports that can operate as (up to) 6
separate port pairs. The port pairs can be assigned
independently to any of six backplane LANs. In
addition, using HUBwatch, you can assign the port
pairs as redundant links to other devices.
The PORTswitch 900TP (DETPJ) is a 32 port RJ45
PORTswitch twisted pair repeater. It has the same functionality
900 TP v2.1.1 as the the DECrepeater 900TM with the addition of
(DETPJ) per-port switching. The module will have a built in
management agent and security.
Repeaters support default alarms and events which come preconfigured with
the modules. These defaults are documented in the product's Owners Manual.
Repeater defaults include traps for:
Message Which means...
"Nonvolatile RAM
cannot accept any There is no more memory for additional nonvolatile
additional parameters.
parameters."
Once a port is auto-partitioned, traffic received
from other ports is transmitted out of the
auto-partitioned port; however, traffic transmitted
into the auto-partitioned port by an attached
station is not repeated to all other repeater
ports. Most repeaters allow one of two
autopartition algorithms to be selected: Standard
or Enhanced.
The Standard setting causes the repeater to
implement the IEEE 802.3 standard auto-partitioning
algorithm. Standard mode causes a port to be placed
in the partition state when any of the following
conditions occur at that port:
* Excessive length collision--Generally, a
collision that is between 10,000 and 30,000
nanoseconds long is considered excessive. A
bit time is equal to 100 nanoseconds. For
example, for the DECrepeater 900TM, collision
One or more ports lengths of between 1,024 and 2,048 bit times
have autopartitioned. are considered excessive.
* Excessive number of consecutive
collisions--Consecutive collisions that exceed
30 are considered excessive. For example, for
the DECrepeater 900TM, 32 consecutive
collisions is considered excessive.
Selecting Enhanced causes the repeater to implement
Digital's auto-partitioning algorithm. Enhanced
mode causes a port to be placed in the partition
state when any of the following conditions occur at
that port:
* Excessive length collision
* Excessive number of consecutive collisions
* No Receive Input message during transmission
(no loopback)
* Excessive length Input message (jabber)
* Transmit carrier drop (one or more lapses in
the Input message during a single Output
message without a collision)
* Internal detectable port failures
This indicates that a formerly autopartitioned port
is no longer partitioned. Most Digital repeater
allow one of two forms of reconnection algorithms:
Standard or On Successful Transmit.
'Standard' causes the repeater to implement the
IEEE 802.3 standard auto-partitioned reconnection
One or more algorithm. In Standard mode, an auto-partitioned
autopartitioned ports port is reconnected after a valid packet is
are now operational. transmitted or received by the port without a
collision.
'On Successful Transmit' causes the repeater to
implement a more stringent, alternative
auto-partition reconnection algorithm. In this
mode, an auto-partitioned port is reconnected only
after a valid packet is transmitted by the port
without a collision.
This indicates a something interesting happened to
The repeater's the repeater. It can be redundant information, like
'rptrHealthText' has an autopartition or media becoming available. It
changed. can also indicate that a port was disabled or
enabled via management.
The total number of
times a port has
become This event is redundant and will be removed from
not-operational, future repeater firmware releases.
autopartitioned, or
unavailable.
This alarm is generated when one or more of the
following errors are detected on one of the
repeater's ports:
The total number of * FCS Errors
errors for this * Alignment Errors
repeater. * Frame Too Longs
* Short Events
* Late Events
* Very Long Events
* Data Rate Mismatches
Indicates that a port configured for Dual Port
Redundancy has changed state. This state change can
be caused be management reconfiguration, or when a
redundant link fails over.
A Dual Port
Redundancy state A dual-redundant link provides a fault-tolerant
change occurred. network connection which automatically switches
traffic from an active link to a backup/standby
link when a fault is detected on the active link.
Refer to the repeater reference manual for a more
detailed explanation.
Indicates that a port security violation has been
detected.
Security can be set on repeater ports for both
outgoing and incoming packet traffic. You can apply
the security functions you select to a single port
or to all front panel ports. Restricting outgoing
packets is refered to as Eavesdrop Protection.
Restricting incoming packets in refered to as
Intrusion Protection.
Intrusion detection/protection prevents a station
from transmitting data to any other station from a
repeater port it is not authorized to use. To
enforce intrusion protection, the repeater compares
the source addresses of packets received from a
given port with the address(es) in that port's
authorized address list. If the addresses do not
match, the intrusion is logged in the Security
Violations Log Table and appropriate action is
taken. Depending upon the intrusion security mode
selected, the repeater may take one of the
A repeater security following actions:
violation occurred.
* Automatically disable the port that detected
the violation, thereby preventing any further
violations. A port disabled due to a security
violation must be manually re-enabled.
* Garble the offending packet before repeating
it to any other port.
Eavesdrop prevention prevents a station authorized
to use a given repeater port from receiving data
packets addressed to any station other than itself.
To enforce eavesdrop prevention, the repeater
compares the unicast destination address of a
packet being transmitted out a given repeater port
with the address(es) in that port's authorized
address list. If the addresses do not match, a
garbled version of the packet is transmitted.
Otherwise, the packet is transmitted unaltered.
Packets with multicast or broadcast destination
addresses are never subject to eavesdrop
prevention.
Refer to the repeater owner's manual for a more
detailed explanation.
This usually indicates that a cable was unplugged,
but can indicate a fault in the physical media
connected to the repeater port. Repeater media is
said to be unavailable under the following
conditions:
* If the MAU is link-type (FOIRL, 10BASE-T,
One or more media has 10BASE-F) then this object is equivalent to
become unavailable the link test fail state/low light function.
* For an AUI or a coax MAU this indicates
whether or not loopback is detected.
* For MAUs of type 10BASE-FB this indicates that
either a fault has been etected at the remote
end of the link or that an invalid signal has
been received from the other end of the link.
One or more formerly This usualy indicates that a cable was plugged into
unavailable media are a repeater port, but can indicate that a fault in
now available. the physical media connected to port has been
corrected.
---------------------------------------------------------------------------
Hub Manager and Stack Director RMON-Like Event Traps
Version 5.0 and greater Hub Manager and 1.0 and greater Stack Director
modules support the "RMON-Like Alarm and Event Gateway" for 600 series
modules. Two traps are defined by the gateway:
* Enterprise Specific = 1 trap: risingEvent.
* Enterprise Specific = 2 trap: fallingEvent.
Unlike RMON, no default traps are configured for the RMON-like Gateway.
These traps are in the mam-private MIB and are described below:
--
-- RMON-Like Alarm and Event Gateway Traps
--
-- Two traps may be generated. Traps require:
--
-- - That a 'trap-sink' (destination IP address) be configured on
-- the Management Agent Module.
--
-- - That entries in hubEventTable be configured with hubEventType
-- set to either 'snmp-trap(3)' or 'log-and-trap(4)'.
--
-- hubRisingAlarm TRAP-TYPE
-- ENTERPRISE mamPrivate
-- VARIABLES { hubAlarmSlotNumber,
-- hubAlarmIndex,
-- hubAlarmVariable,
-- hubAlarmSampleType,
-- hubAlarmValue,
-- hubAlarmRisingThreshold }
-- DESCRIPTION
-- "The SNMP trap that is generated when an alarm entry crosses its
-- rising threshold and generates an event that is configured for
-- sending SNMP traps.
--
-- The enterprise Object Identifier for this trap is:
--
-- iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).
-- dec(36).ema(2).decMIBextension(18).decHub900(11).
-- mgmtAgent(1).mgmtAgentVersion2(2).mamPrivate(2)
-- "
-- ::= 1
--
-- hubFallingAlarm TRAP-TYPE
-- ENTERPRISE mamPrivate
-- VARIABLES { hubAlarmSlotNumber,
-- hubAlarmIndex,
-- hubAlarmVariable,
-- hubAlarmSampleType,
-- hubAlarmValue,
-- hubAlarmRisingThreshold }
-- DESCRIPTION
-- "The SNMP trap that is generated when an alarm entry crosses its
-- falling threshold and generates an event that is configured for
-- sending SNMP traps.
--
-- The enterprise Object Identifier for this trap is:
--
-- iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).
-- dec(36).ema(2).decMIBextension(18).decHub900(11).
-- mgmtAgent(1).mgmtAgentVersion2(2).mamPrivate(2)
-- "
-- ::= 2
---------------------------------------------------------------------------
Switch RMON Traps
The switches listed below with firmware version 1.7 and greater support
RMON Alarms and Events. Unlike other products, however, the bridge does not
support any default events.
Switch
Product Product Description
High-Performance, six-port Ethernet-to-FDDI switch. The
DECswitch 900FO 6-port Ethernet to FDDI level 2 switch
provides high-performance switching between Ethernet and FDDI
DECswitch networks. The DECswitch 900FO has six front panel fiber optic
900FO ST ports and one FDDI logical rear backplane port. Each of the
six Ethernet ports is individually software configurable using
clearVISN Multichassis Manager to connect through one of the
front panel ST fiber optic ports or to one of the DEChub
900MultiSwitch (MS) chassis backplane LAN segments.
Cost-effective, six-port Ethernet-to-Ethernet switch. The
DECswitch 900EE is a six-port "line speed" Ethernet switch
that provides full-speed 802.1D bridging among each of the six
Ethernet segments. It has six Ethernets on the front panel
DECswitch (two AUI and four 10BaseT). Each of these ports is
900EE configurable, via software, to connect to the front panel
connector or alternatively to one of six internal DEChub 900
MultiSwitch LAN segments. This feature offers - maximum
configuration . Flexibility -- whether you use the switch in a
standalone single-slot rack-and-stack hub configuration, or
install it in a DEChub 900 MultiSwitch hub chassis.
Six port Ethernet-to-FDDI backbone switch. The DECswitch 900EF
is a Ethernet-to-FDDI switch for the backbone. It has six
Ethernet switched ports and one FDDI switched port, and
provides full 802.1D bridging capability among each of six
DECswitch Ethernet and FDDI LANs. The DECswitch 900EF has six Ethernet
900EF ports on the front panel (two AUI and four 10BaseT) and a DAS
FDDI port. Using HUBwatch software, you can configure any FDDI
or Ethernet port to connect through the front panel or,
through the backplane of a DEChub 900 MultiSwitch. The
DECswitch 900EF may also be configured standalone by utilizing
the DEHUA or DEF1H single-slot hub chassis.
Digital's PEswitch 900TX device gives your users dedicated 10
Mb/s per station switching between Ethernet and FDDI. It
combines full store-and-forward switching technology for data
PEswitch integrity with high speed switching performance at a very
900TX affordable price -- making it the switching product of choice
for your desktop requirements. The PEswitch 900TX unit is an
ideal solution for connecting high-speed workgroups to the
FDDI servers or backbones, while eliminating user disruptions,
changes to cabling, or adapter replacement costs.
DECbridge Same as the DECswitch 900 EF - but shipped before we could
900MX change the name.
---------------------------------------------------------------------------
Repeater MIB
The Repeater MIB (RFC1516) specifies three optional traps:
* rptrHealth
* rptrGroupChange
* rptrResetEvent
-- Traps for use by Repeaters
-- Traps are defined using the conventions in RFC 1215 [6].
rptrHealth TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrHealth trap conveys information related
to the operational status of the repeater. This
trap is sent either when the value of
rptrOperStatus changes, or upon completion of a
non-disruptive test.
The rptrHealth trap must contain the
rptrOperStatus object. The agent may optionally
include the rptrHealthText object in the varBind
list. See the rptrOperStatus and rptrHealthText
objects for descriptions of the information that
is sent.
The agent must throttle the generation of
consecutive rptrHealth traps so that there is at
least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
hubHealth notification."
::= 1
rptrGroupChange TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrGroupIndex }
DESCRIPTION
"This trap is sent when a change occurs in the
group structure of a repeater. This occurs only
when a group is logically or physically removed
from or added to a repeater. The varBind list
contains the identifier of the group that was
removed or added.
The agent must throttle the generation of
consecutive rptrGroupChange traps for the same
group so that there is at least a five-second gap
between traps of this type. When traps are
throttled, they are dropped, not queued for
sending at a future time. (Note that 'generating'
a trap means sending to all configured
recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
groupMapChange notification."
::= 2
rptrResetEvent TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrResetEvent trap conveys information
related to the operational status of the repeater.
This trap is sent on completion of a repeater
reset action. A repeater reset action is defined
as an a transition to the START state of Fig 9-2
in section 9 [IEEE 802.3 Std], when triggered by a
management command (e.g., an SNMP Set on the
rptrReset object).
The agent must throttle the generation of
consecutive rptrResetEvent traps so that there is
at least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)
The rptrResetEvent trap is not sent when the agent
restarts and sends an SNMP coldStart or warmStart
trap. However, it is recommended that a repeater
agent send the rptrOperStatus object as an
optional object with its coldStart and warmStart
trap PDUs.
The rptrOperStatus object must be included in the
varbind list sent with this trap. The agent may
optionally include the rptrHealthText object as
well."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset
notification."
::= 3
---------------------------------------------------------------------------
Bridge MIB Traps
Neither of the optional bridge MIB (RFC1493) traps are supported by the
DECswitch900 series modules. However, the GigaSwitch products do support
these traps.
Bridge MIB traps include "newRoot" and "topologyChange" - both of which are
described in detail in RFC1493.
-- Traps for use by Bridges
-- Traps for the Spanning Tree Protocol
newRoot TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"The newRoot trap indicates that the sending agent
has become the new root of the Spanning Tree; the
trap is sent by a bridge soon after its election
as the new root, e.g., upon expiration of the
Topology Change Timer immediately subsequent to
its election. Implementation of this trap is
optional."
::= 1
topologyChange TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"A topologyChange trap is sent by a bridge when
any of its configured ports transitions from the
Learning state to the Forwarding state, or from
the Forwarding state to the Blocking state. The
trap is not sent if a newRoot trap is sent for the
same transition. Implementation of this trap is
optional."
::= 2
---------------------------------------------------------------------------
FDDI MIB Traps
There are no traps defined in the FDDI MIB (RFC1512).
---------------------------------------------------------------------------
DECconcentrator 900 Enterprise Specific Port Traps
The DECconcentrator 900 series products, listed below, support one
enterprise specific trap: the port trap.
List of DECconcentrator Products
Product Name Product Description
he DECconcentrator 900TH offers maximum configuration
denisity with sixteen total ports; (fourteen front
panel, two backplane) - four are software configurable
as FDDI, A, B, M, or S ports. It also gives you flexible
DECconcentrator media options - two front panel ports support the
900TH modular physical media dependent (PMD) design allowing
single-mode fiber, multimode fiber, and unshielded
twisted-pair. The DEChub ONE-MX single slot hub offers
two more additional modular physical media dependent
slots.
The DECconcentrator 900FH offers the lowcost connections
to FDDI using multimode fiber media via SC connectors.
Maximum connection denisity is also available with
sixteen total ports; (fourteen front panel, two
DECconcentrator backplane) - four are software configurable as FDDI, A,
900FH B, M, or S ports. It also gives you flexible media
options - two front panel ports support the modular
physical media dependent (PMD) design allowing
single-mode fiber, multimode fiber, and unshielded
twisted-pair.
The DECconcentrator 900MX offers maximum configuration
flexibility with eight total ports; (six front panel,
DECconcentrator two backplane) - four are software configurable as FDDI,
900MX A, B, M, or S ports. It also gives you flexible media
options - the modular physical media dependent (PMD)
design supports single-mode fiber, multimode fiber, and
unshielded twisted-pair, on a per-port basis.
The port trap conveys information about the change of an FDDI port's state.
For example, a "disconnecting" port causes a port trap to be sent. Another
trap is sent when the port is "connecting". Other state changes also cause
port traps. The port traps is disabled by default. It may be enabled by
setting the esysFddiPortTrapSwitch.
Once enabled, port traps are sent whenever "fddimibPORTConnectState"
changes. "fddimibPORTConnectState" changes as port connections are created
and destroyed (per the SMT spec). Refer to the fddi mib for details about
fddimibPORTConnectState. Port traps are enterprise specific 1 traps
(generic- trap-type = 6, specific-trap-type = 1). Details about which port
was affected, and the new connect state are carried in the "interesting
information" field of the trap message.
The TRAP-TYPE definition went into the products release notes at one point.
decConcentratorPortTrap TRAP-TYPE
ENTERPRISE { elanext } -- This might be wrong!
VARIABLES { fddimibPORTConnectState }
DESCRIPTION
"The value of fddimibPortConnectState has changed.
This is usually caused by a station inserting
into the FDDI ring, or detatching from the ring."
::= 1
People often expect LinkUp and LinkDown traps to be sent when a
concentrator port is affected. This isn't done because of the distinction
between a 'link' and a 'port'. (Refer to Link Traps.).)
---------------------------------------------------------------------------
RouteAbout Acesss and Central
From COMMON_BROUTERS notes conference, note 160.3:
All comet routers can be configured to generate enterprise
specific traps. You can configure ELS (the event subsystem)
so that some or all ELS events also generate an enterprise
specific trap. For example, you can use the following command
to generate an ELS enterprise specific trap whenever an SNMP ELS
event occurs.
At MOS command prompt
*t 6
Gateway user configuration
Config>event
Event Logging System user configuration
ELS config>trap sub snmp all
ELS config>list all
...
Subsystem: SNMP
Disp levels: STANDARD
Trap levels: ALL
....
Then restart the router.
Refer to http://www-router.lkg.dec.com/~johnp/snmp/mibs/decvars-cc-v1.1.txt
for the Digital version of the Proteon enterprise MIB variables that
includes Proteon supplied definitions of the ELS trap types.
---------------------------------------------------------------------------
VNswitch Product Descriptions
VNswitch Product Descriptions
Product Name Product Description
VNswitch 900EX12 switched Ethernet ports and two Fast Ethernet ports.
VNswitch 900EA12 switched Ethernet ports and one ATM port.
VNswitch 900EF12 switched Ethernet ports and one FDDI port pair.
VNswitch 900EE24 switched Ethernet ports.
|
| 4307.8 | updated .htm | NETCAD::GALLAGHER | | Wed Apr 02 1997 18:18 | 1379 |
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html><head>
<title>NPB Products - Traps
</title></head><body>
<center><img src = "digital_logo.gif"></center>
<h1 align=center>NPB Products - Traps</h1>
<hr>
<center>
<table border>
<tr>
<td></td>
<td align=center colspan=5><b>Standard Traps</b></td>
<td align=center colspan=3><b>Non-standard Traps</b></td>
</tr>
<td align=center><b>Module</b></td>
<td align=center><b><a href="#cold">Cold Start</a></b></td>
<td align=center><b><a href="#warm">Warm Start</a></b></td>
<td align=center><b><a href="#link">Link Up</a></b></td>
<td align=center><b><a href="#link">Link Down</a></b></td>
<td align=center><b><a href="#auth">Auth Failure</a></b></td>
<td align=center><b>RMON A&E</b></td>
<td align=center><b><a href="#ent">Enterprise</a></b></td>
<td align=center><b>Other</b></td>
<tr>
<td align=left>DENMA - DECagent90</td>
<td align=center>Yes</td>
<td align=center>No</td>
<td align=center>Yes</td>
<td align=center>Yes</td>
<td align=center>Yes</td>
<td align=center>No</td>
<td align=center><a href="#denma">Yes</a></td>
<td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>MAM - Hub Manager</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#mamRmon">Yes</a></td>
<! Enter> <td align=center><a href="#mamRmonLike">Yes</a></td>
<! Other> <td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>Stack Director</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#stackRmon">Yes</a></td>
<! Enter> <td align=center><a href="#stackRmonLike">Yes</a></td>
<! Other> <td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>PORTswitch900s<a href="#listOfRepeaters">(list)</a></td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#repeaterRmon">Yes</a></td>
<! Enter> <td align=center>No</td>
<! Other> <td align=center><a href="#repeater">Yes</a></td>
</tr>
<tr>
<! Module> <td align=left>DECrepeater900s<a href="#listOfRepeaters">(list)</a></td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#repeaterRmon">Yes</a></td>
<! Enter> <td align=center>No</td>
<! Other> <td align=center><a href="#repeater">Yes</a></td>
</tr>
<tr>
<! Module> <td align=left>DECswitch900 EE/EF/FO</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#switchRmon">Yes</a></td>
<! Enter> <td align=center>No</td>
<! Other> <td align=center><a href="#bridgeMIB">No</a></td>
</tr>
<tr>
<! Module> <td align=left>PEswitch 900TX</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#switchRmon">Yes</a></td>
<! Enter> <td align=center>No</td>
<! Other> <td align=center><a href="#bridgeMIB">No</a></td>
</tr>
<tr>
<! Module> <td align=left>DECbridge 900MX</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center><a href="#switchRmon">Yes</a></td>
<! Enter> <td align=center>No</td>
<! Other> <td align=center><a href="#bridgeMIB">No</a></td>
</tr>
<tr>
<! Module> <td align=left>DECconcentrator900s <a href="#listOfConcentrators">(list)</a></td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center><a href="#port">Yes</a></td>
<! Other> <td align=center><a href="#fddiMIB">No</a></td>
</tr>
<tr>
<! Module> <td align=left>DECserver900TM</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center>tbd</td>
<! Other> <td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>VNswitches <a href="#listOfVNs">(list)</a></td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>Yes</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>tbd</td>
<! Enter> <td align=center>tbd</td>
<! Other> <td align=center>tbd</td>
</tr>
<tr>
<! Module> <td align=left>GigaSwitch/FDDI</td>
<! Cold> <td align=center>No</td>
<! Warm> <td align=center>Yes</td>
<! LUp> <td align=center>No</td>
<! LDown> <td align=center>No</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center>tbd</td>
<! Other> <td align=center><a href="#bridgeMIB">Yes</a></td>
</tr>
<tr>
<! Module> <td align=left>GigaSwitch/ATM <2.5</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center>No</td>
<! Other> <td align=center>ILMI</td>
</tr>
<tr>
<! Module> <td align=left>GigaSwitch/ATM >=2.5</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>No</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>Yes</td>
<! Enter> <td align=center>No</td>
<! Other> <td align=center>ILMI</td>
</tr>
<tr>
<! Module> <td align=left>RouteAbout Acc. EW/EI</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>Yes</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center><a href="#rAbout">Yes</a></td>
<! Other> <td align=center>No</td>
</tr>
<tr>
<! Module> <td align=left>RouteAbout Central EW</td>
<! Cold> <td align=center>Yes</td>
<! Warm> <td align=center>Yes</td>
<! LUp> <td align=center>Yes</td>
<! LDown> <td align=center>Yes</td>
<! Auth> <td align=center>Yes</td>
<! RMON> <td align=center>No</td>
<! Enter> <td align=center><a href="#rAbout">Yes</a></td>
<! Other> <td align=center>No</td>
</tr>
</table></center>
<pre>
</pre>
<hr>
<h2>Trap Definitions</h2>
<a name="cold"><h3>ColdStart</h3></a>
From RFC 1157:
<blockquote>
<i>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.</i>
</blockquote>
<a name="warm"><h3>WarmStart Traps</h3></a>
From RFC 1157:
<blockquote>
<i>A warmStart(1) trap signifies that the sending protocol entity is
reinitializing itself such that neither the agent configuration nor
the protocol entity implementation is altered.</i>
</blockquote>
The definition of WarmStart traps is vague. Many DEChub900 module implementors
opted to issue ColdStart traps
each time a module is powered-up or reset.
<a name="link"><h3>LinkUp and LinkDown</h3></a>
From RFC 1157:
<blockquote>
<i>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.
<p>
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.
<p>
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.
<p>
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.</i>
</blockquote>
Note that there is a lot of confusion about what a "link" is. The following are
links:
<ul>
<li>Switch ports.
<li>Repeater MACs.
<li>Serial channels.
<li>Ethernet management channels.
</ul>
And the following are <b>not</b> considered links:
<ul>
<li>Ethernet repeater ports.
<li>Token ring MAUs.
<li>FDDI concentrator ports.
</ul>
<a name="egp"><h3>EGP Neighbor Loss Traps</h3></a>
From RFC 1157:
<blockquote>
<i>An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
the sending protocol entity was an EGP peer has been marked down and
the peer relationship no longer obtains.
<p>
The Trap-PDU of type egpNeighborLoss contains as the first element of
its variable-bindings, the name and value of the egpNeighAddr
instance for the affected neighbor.</i>
</blockquote>
EGP Neighbor Loss traps are also amoung the "Standard Traps", however, they
are only for some routers: those that support the EGP.
<a name="auth"><h3>AuthFailure</h3></a>
From RFC 1157:
<blockquote>
<i>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.</i>
</blockquote>
A typical cause of authentication failure is using the wrong SNMP community,
of using the read-only community when issuing a set.
<a name="ent"><h3>Enterprise Specific Traps</h3></a>
From RFC 1157:
<blockquote>
<i>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.</i>
</blockquote>
Enterprise specific traps on Digital hub products include:
<cneter><table>
<th>Enterprise</th>
<th>Specific</th>
<th>Description</th>
<th>More</th>
<tr>
<td>DECconcentrator 900</td>
<td>1</td>
<td>"Port" trap. Sent when stations attaches or deattaches to/from a
concentrator port.</td>
<td><a href="">More</a></td>
<tr>
<tr>
<td>Hub Manager and Stack Director</td>
<td>1</td>
<td>RMON-Like Gateway rising event trap.</td>
<td><a href="">ore</a></td>
<tr>
<tr>
<td>Hub Manager and Stack Director</td>
<td>2</td>
<td>RMON-Like Gateway rising event trap.</td>
<td><a href="">More</a></td>
<tr>
<hr>
<a name="denma"><h2>DENMA Enterprise Specific Traps</h2></a>
DENMA enterprise specific traps are defined in the
<a href="http://npbwww.hpn.lkg.dec.com:80/dr/hubs/mibs/hub90v30.txt">
DENMA's private MIB</a>
Breifly, the following traps are supported:
<ul>
<li>consolePasswordFailure
<li>nonVolatileRamError
<li>configurationExceeded
<li>populationChange
<li>moduleStatusChange
<li>rptrPortStatusChange
<li>srvrPortStatusChange
<li>brdgPortStatusChange
</ul>
Definitions:
<pre>
--
--
-- DECagent 90 Trap Definitions
--
-- The following SNMP generic traps are supported by the DECagent 90:
--
-- coldStart(0)
-- warmStart(1)
-- authenticationFailure(4)
--
-- The DECagent 90 also generates the enterpriseSpecific(6) traps defined
-- below.
--
consolePasswordFailure TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"There have been three consecutive failures to enter a correct password
when attempting to log into the DECagent 90 console port."
::= 1
nonVolatileRamError TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"An error in the non-volatile storage on the DECagent 90 has occurred.
Some configuration information may have been lost."
::= 2
configurationExceeded TRAP-TYPE
ENTERPRISE decagent90v1
DESCRIPTION
"An attempt was made to exceed the maximum configuration supported by
the DECagent 90. The request to create the additional community or to
add the additional module has been rejected."
::= 3
populationChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID }
DESCRIPTION
"A module has been added or discovered, or has been deleted or
undiscovered. The objects dh90PopulationChange and
dh90PopulationLastChange have been updated to reflect this change.
The community index, slot index, and module object id are included in
the trap PDU."
::= 4
moduleStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
dh90SlotProxyStatus }
DESCRIPTION
"A module has become reachable or unreachable. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id and
proxy status are included in the trap PDU."
::= 5
rptrPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
drpt90PortIndex, drpt90PortState }
DESCRIPTION
"The port status has changed on a repeater module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port state are included in the trap PDU."
::= 6
--
-- !! IMPORTANT NOTE FOR SOME MIB COMPILERS !!
--
-- The VARIABLES list has been commented out of the following two trap
-- definitions because some MIB compilers cannot compile trap definitions that
-- specify a VARIABLES list containing objects that are external to this MIB.
--
-- If your MIB compiler can properly compile trap definitions with a VARIABLES
-- list containing external objects, you should uncomment the VARIABLES list
-- for these two trap definitions. If you do so, you must also uncomment the
-- IMPORTS near the beginning of this MIB which import the required objects
-- from their respective RFC.
--
-- Note that regardless of how this MIB is compiled into your NMS application,
-- the trap PDU generated by the DECagent 90 for these traps will contain a
-- varbind list with the objects specified in the VARIABLES list along with
-- their values. It is up to the trap handler on the NMS to decide what to do
-- with this information.
--
srvrPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
-- VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
-- charPortIndex, charPortOperStatus }
DESCRIPTION
"The port status has changed on a terminal server module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port operational status are included in the trap PDU."
::= 7
brdgPortStatusChange TRAP-TYPE
ENTERPRISE decagent90v1
-- VARIABLES { da90CommunityIndex, dh90SlotIndex, dh90SlotObjectID,
-- ifIndex, ifOperStatus }
DESCRIPTION
"The port status has changed on a bridge module. The objects
dh90StatusChange and dh90StatusLastChange have been updated to reflect
this change. The community index, slot index, module object id, port
index and port operational status are included in the trap PDU."
::= 8
</pre>
Refer to <a href="#denmaTraps"> DENMA Traps</a> for trap definitions.
Refer to the <a href="http://npbwww.hpn.lkg.dec.com:80/dr/hubs/mibs/hub90v30.txt">
DENMA's private MIB</a> for details.
<p>
<hr>
<a name="mamRmon"></a>
<a name="stackRmon"><h2>Hub Manager and Stack Director
RMON Event Traps</h2></a>
RMON risingEvent and falling event traps are defined in RFC1757.
(Compiling this standard MIB into Netview et.al. enables it to properly decode
these traps.)
<pre>
-- These definitions use the TRAP-TYPE macro as
-- defined in RFC 1215 [10]
-- Remote Network Monitoring Traps
risingAlarm TRAP-TYPE
ENTERPRISE rmon
VARIABLES { alarmIndex, alarmVariable, alarmSampleType,
alarmValue, alarmRisingThreshold }
DESCRIPTION
"The SNMP trap that is generated when an alarm
entry crosses its rising threshold and generates
an event that is configured for sending SNMP
traps."
::= 1
fallingAlarm TRAP-TYPE
ENTERPRISE rmon
VARIABLES { alarmIndex, alarmVariable, alarmSampleType,
alarmValue, alarmFallingThreshold }
DESCRIPTION
"The SNMP trap that is generated when an alarm
entry crosses its falling threshold and generates
an event that is configured for sending SNMP
traps."
::= 2
</pre>
The DEChub900's Hub Manager (MAM) and Stack Director support default
alarms and events which come preconfigured with the modules.
These defaults are documented in the product's Owners Manual.
Hub Manager defaults include:
<pre>
</pre>
<center><table border>
<th>Message</th>
<th>Which means...</th>
<tr>
<td>"A network module was inserted or removed."</td>
<td>A network module (aka "line-card") was inserted or removed
from the hub's chassis.</td>
</tr>
<tr>
<td>"An environmental change occured"</td>
<td>A network module's fan failed, or a network module is overheating.</td>
</tr>
<tr>
<td>"A power supply was inserted or removed."</td>
<td>A power supply was inserted or removed from the DEChub900.
(Not supported on the Stack Director since each Stack 600 module has its
own power supply.</td>
</tr>
<tr>
<td>"The DEChub900 no longer has N-Plus-1 power redundancy"</td>
<td>Available power has decrease such that all power supplies are
needed to power the inserted network modules.</td>
</tr>
<tr>
<td>"The DEChub900 no longer has N-Plus-1 power redundancy""</td>
<td>Available power has increase such that one or more power supplies
may fail without adversely affecting the inserted network modules.</td>
</tr>
<tr>
<td>"A backplane connection change has occurred."</td>
<td>The backplane LAN interconnect environment has changed. This can be caused
through a management operation via clearVISN, or by a newly inserted
module connection to the backplane.</td>
</tr>
<tr>
<td>"Nonvolatile RAM cannot accept any additional parameters."</td>
<td>There is no more memory for additional nonvolatile parameters.</td>
</tr>
<tr>
<td>"Nonvolatile memory has failed."</td>
<td>A memory fault has been detected. Correct by resetting to factory
defaults, or by replacing the Hub Manager.</td>
</tr>
</center></table>
<pre>
</pre>
Stack Director defaults include:
<pre>
</pre>
<center><table border>
<th>Message</th>
<th>Which means...</th>
<tr>
<td>"A network module was inserted or removed."</td>
<td>A network module (aka "line-card") was inserted or removed
from the stack.</td>
</tr>
<tr>
<td>"An environmental change occured"</td>
<td>A network module's fan failed, or a network module is overheating.</td>
</tr>
<tr>
<td>"A backplane connection change has occurred."</td>
<td>The backplane LAN interconnect environment has changed. This can be caused
through a management operation via clearVISN, or by a newly inserted
module connection to the backplane.</td>
</tr>
<tr>
<td>"Nonvolatile RAM connot accept any additional parameters."</td>
<td>There is no more memory for additional nonvolatile parameters.</td>
</tr>
<tr>
<td>"Nonvolatile memory has failed."</td>
<td>A memory fault has been detected. Correct by resetting to factory
defaults, or by replacing the Stack Director.</td>
</tr>
</center></table>
<hr>
<a name="repeaterRmon"><h2>Repeater 900 RMON Event Traps</h2></a>
RMON risingEvent and falling event traps are defined in RFC1757.
(Compiling this standard MIB into Netview et.al. enables it to properly decode
these traps.)
All 900 form-factor repeaters and PORTswitches listed below support RMON
Alarms and Events.
<p>
<center><table border>
<a name="listOfRepeaters"></a>
<caption><b>RMON Support on Repeaters and PORTswitches</b></caption>
<th>Product Name</th>
<th>FW Ver</th>
<th>Product Description</th>
<tr>
<td>DECrepeater 900 TM (DETMM)</td>
<td>v2.0</td>
<td>The DECrepeater 900TM is an 802.3 10BaseT (twisted-pair) 32-port
repeater for use with either 100-ohm shielded or unshielded
twisted-pair wire. The DECrepeater 900TM can be used in the
DEChub 900 MultiSwitch or as a standalone repeater in the DEChub
ONE single-slot hub. In the DEChub 900MS, the DECrepeater 900TM
can sit on either the ThinWire or IMB backplane, or both, and
makes full use of the IRB capabilities of the hub count as one
repeater hop when configuring per the 802.3 Repeater Rules.</td>
</tr>
<tr>
<td>DECrepeater 900 GM (DETTM)</td>
<td>v2.0</td>
<td>The DECrepeater 900GM is a full-height, 24-port, 10BaseT, Ethernet
repeater containing 24 10BaseT ports on two 50-pin Telco
connectors, an external attachment unit interface (AUI) port, and
module and network status LEDs. The module can be configured in
the DEChub 900 MultiSwitch and can be configured standalone in the
DEChub ONE.</td>
</tr>
<tr>
<td>PORTswitch 900 CP (DECPM)</td>
<td>v2.1.1</td>
<td>The PORTswitch 900CP (DECPM) is a 16 port (BNC) thinwire repeater.
It has all the functionality currently provided by the DECMR with
the addition of per-port switching. This module also has a built
in management agent and port level security.</td>
</tr>
<tr>
<td>PORTswitch 900 FP (DEFMM)</td>
<td>v2.1.1</td>
<td>The PORTswitch 900FP is a 12-port, 10BaseFL, fiber-optic, Ethernet
repeater that can be configured into a DEChub 900 MultiSwitch.
One or more PORTswitch 900FP modules (up to eight) can be
installed into the DEChub 900. The module can also serve as a
standalone unit when configured with a DEChub ONE docking station.
<p>
The front panel of the PORTswitch 900FP provides 12 fiber-optic
ports that can operate as (up to) 6 separate port pairs. The port
pairs can be assigned independently to any of six backplane LANs.
In addition, using HUBwatch, you can assign the port pairs as
redundant links to other devices.</td>
</tr>
<tr>
<td>PORTswitch 900 TP (DETPJ)</td>
<td>v2.1.1</td>
<td>The PORTswitch 900TP (DETPJ) is a 32 port RJ45 twisted pair
repeater. It has the same functionality as the the DECrepeater
900TM with the addition of per-port switching. The module will
have a built in management agent and security.</td>
</tr>
</table></center>
<pre>
</pre>
Repeaters support default alarms and events which come preconfigured with the modules.
These defaults are documented in the product's Owners Manual.
Repeater defaults include traps for:
<pre>
</pre>
<center><table border>
<th>Message</th>
<th>Which means...</th>
<tr>
<td>"Nonvolatile RAM cannot accept any additional parameters."</td>
<td>There is no more memory for additional nonvolatile parameters.</td>
</tr>
<tr>
<td>One or more ports have autopartitioned.</td>
<td>Once a port is auto-partitioned, traffic received from other ports is
transmitted out of the auto-partitioned port; however, traffic transmitted
into the auto-partitioned port by an attached station is not repeated to all
other repeater ports.
Most repeaters allow one of two autopartition algorithms to be selected:
Standard or Enhanced.
<p>
The Standard setting causes the repeater to implement the IEEE 802.3 standard
auto-partitioning algorithm. Standard mode causes a port to be placed in the
partition state when any of the following conditions occur at that port:
<ul>
<li>Excessive length collision--Generally, a collision that is between
10,000 and 30,000 nanoseconds long is considered excessive. A bit
time is equal to 100 nanoseconds. For example, for the DECrepeater
900TM, collision lengths of between 1,024 and 2,048 bit times are
considered excessive.
<li>Excessive number of consecutive collisions--Consecutive collisions
that exceed 30 are considered excessive. For example, for the
DECrepeater 900TM, 32 consecutive collisions is considered excessive.
</ul>
Selecting Enhanced causes the repeater to implement Digital's auto-partitioning
algorithm. Enhanced mode causes a port to be placed in the partition state when
any of the following conditions occur at that port:
<ul>
<li>Excessive length collision
<li>Excessive number of consecutive collisions
<li>No Receive Input message during transmission (no loopback)
<li>Excessive length Input message (jabber)
<li>Transmit carrier drop (one or more lapses in the Input message during
a single Output message without a collision)
<li>Internal detectable port failures</td>
</ul>
</tr>
<tr>
<td>One or more autopartitioned ports are now operational.</td>
<td>This indicates that a formerly autopartitioned port is no longer partitioned.
Most Digital repeater allow one of two forms of reconnection algorithms:
Standard or On Successful Transmit.
<p>
'Standard' causes the repeater to implement the IEEE 802.3 standard
auto-partitioned reconnection algorithm. In Standard mode, an auto-partitioned
port is reconnected after a valid packet is transmitted or received by the
port without a collision.
<p>
'On Successful Transmit' causes the repeater to implement a more stringent,
alternative auto-partition reconnection algorithm. In this mode, an
auto-partitioned port is reconnected only after a valid packet is transmitted
by the port without a collision.</td>
</tr>
<tr>
<td>The repeater's 'rptrHealthText' has changed.</td>
<td>This indicates a something interesting happened to the repeater.
It can be redundant information, like an autopartition or media becoming
available. It can also indicate that a port was disabled or enabled
via management.</td>
</tr>
<tr>
<td>The total number of times a port has become not-operational,
autopartitioned, or unavailable.</td>
<td>This event is redundant and will be removed from future repeater firmware
releases.</td>
</tr>
<tr>
<td>The total number of errors for this repeater.</td>
<td>This alarm is generated when one or more of the following errors are
detected on one of the repeater's ports:
<ul>
<li>FCS Errors
<li>Alignment Errors
<li>Frame Too Longs
<li>Short Events
<li>Late Events
<li>Very Long Events
<li>Data Rate Mismatches
</ul>
</td>
</tr>
<tr>
<td>A Dual Port Redundancy state change occurred.</td>
<td>Indicates that a port configured for Dual Port Redundancy has changed state.
This state change can be caused be management reconfiguration, or when a
redundant link fails over.
<p>
A dual-redundant link provides a fault-tolerant network connection
which automatically switches traffic from an active link to a
backup/standby link when a fault is detected on the active link.
Refer to the repeater reference manual for a more detailed explanation.
</td>
</tr>
<tr>
<td>A repeater security violation occurred.</td>
<td>Indicates that a port security violation has been detected.
<p>
Security can be set on repeater ports for both outgoing and incoming
packet traffic. You can apply the security functions you select to a single
port or to all front panel ports. Restricting outgoing packets is refered to
as Eavesdrop Protection. Restricting incoming packets in refered to as
Intrusion Protection.
<p>
Intrusion detection/protection prevents a station from transmitting
data to any other station from a repeater port it is not authorized to
use. To enforce intrusion protection, the repeater compares the source
addresses of packets received from a given port with the address(es) in
that port's authorized address list. If the addresses do not match, the
intrusion is logged in the Security Violations Log Table and
appropriate action is taken. Depending upon the intrusion security mode
selected, the repeater may take one of the following actions:
<ul>
<li>Automatically disable the port that detected the violation,
thereby preventing any further violations. A port disabled due
to a security violation must be manually re-enabled.
<li>Garble the offending packet before repeating it to any other
port.
</ul>
Eavesdrop prevention prevents a station authorized to use a given
repeater port from receiving data packets addressed to any station
other than itself. To enforce eavesdrop prevention, the repeater
compares the unicast destination address of a packet being transmitted
out a given repeater port with the address(es) in that port's
authorized address list. If the addresses do not match, a garbled
version of the packet is transmitted. Otherwise, the packet is
transmitted unaltered. Packets with multicast or broadcast destination
addresses are never subject to eavesdrop prevention.
<p>
Refer to the repeater owner's manual for a more detailed
explanation.
</td>
</tr>
<tr>
<td>One or more media has become unavailable</td>
<td>This usually indicates that a cable was unplugged, but can indicate a
fault in the physical media connected to the repeater port.
Repeater media is said to be unavailable under the following conditions:
<ul>
<li>If the MAU is link-type (FOIRL, 10BASE-T, 10BASE-F) then this
object is equivalent to the link test fail state/low light
function.
<li>For an AUI or a coax MAU this indicates whether or
not loopback is detected.
<li>For MAUs of type 10BASE-FB this indicates that either a fault has been
etected at the remote end of the link or that an invalid signal has been
received from the other end of the link.
</ul>
</td>
</tr>
<tr>
<td>One or more formerly unavailable media are now available.</td>
<td>This usualy indicates that a cable was plugged into a repeater port,
but can indicate that a fault in the physical media connected to port
has been corrected.</td>
</tr>
</center></table>
<hr>
<a name="mamRmonLike"></a>
<a name="stackRmonLike"><h2>Hub Manager and Stack Director
RMON-Like Event Traps</h2></a>
Version 5.0 and greater Hub Manager and 1.0 and greater Stack Director modules
support the "RMON-Like Alarm and Event Gateway" for 600 series modules.
Two traps are defined by the gateway:
<ul>
<li>Enterprise Specific = 1 trap: risingEvent.
<li>Enterprise Specific = 2 trap: fallingEvent.
</ul>
Unlike RMON, no default traps are configured for the RMON-like Gateway.
These traps are in the mam-private MIB and are described below:
<pre>
--
-- RMON-Like Alarm and Event Gateway Traps
--
-- Two traps may be generated. Traps require:
--
-- - That a 'trap-sink' (destination IP address) be configured on
-- the Management Agent Module.
--
-- - That entries in hubEventTable be configured with hubEventType
-- set to either 'snmp-trap(3)' or 'log-and-trap(4)'.
--
-- hubRisingAlarm TRAP-TYPE
-- ENTERPRISE mamPrivate
-- VARIABLES { hubAlarmSlotNumber,
-- hubAlarmIndex,
-- hubAlarmVariable,
-- hubAlarmSampleType,
-- hubAlarmValue,
-- hubAlarmRisingThreshold }
-- DESCRIPTION
-- "The SNMP trap that is generated when an alarm entry crosses its
-- rising threshold and generates an event that is configured for
-- sending SNMP traps.
--
-- The enterprise Object Identifier for this trap is:
--
-- iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).
-- dec(36).ema(2).decMIBextension(18).decHub900(11).
-- mgmtAgent(1).mgmtAgentVersion2(2).mamPrivate(2)
-- "
-- ::= 1
--
-- hubFallingAlarm TRAP-TYPE
-- ENTERPRISE mamPrivate
-- VARIABLES { hubAlarmSlotNumber,
-- hubAlarmIndex,
-- hubAlarmVariable,
-- hubAlarmSampleType,
-- hubAlarmValue,
-- hubAlarmRisingThreshold }
-- DESCRIPTION
-- "The SNMP trap that is generated when an alarm entry crosses its
-- falling threshold and generates an event that is configured for
-- sending SNMP traps.
--
-- The enterprise Object Identifier for this trap is:
--
-- iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).
-- dec(36).ema(2).decMIBextension(18).decHub900(11).
-- mgmtAgent(1).mgmtAgentVersion2(2).mamPrivate(2)
-- "
-- ::= 2
</pre>
<hr>
<a name="switchRmon"><h2>Switch RMON Traps</h2></a>
The switches listed below with firmware version 1.7 and greater support RMON Alarms
and Events. Unlike other products, however, the bridge does not support any default events.
<p>
<center><table border>
<th>Switch Product</th>
<th>Product Description</th>
<tr>
<td>DECswitch 900FO </td>
<td> High-Performance, six-port Ethernet-to-FDDI switch.
The DECswitch 900FO 6-port Ethernet to FDDI level 2 switch
provides high-performance switching between Ethernet and FDDI
networks. The DECswitch 900FO has six front panel fiber optic ST
ports and one FDDI logical rear backplane port. Each of the six
Ethernet ports is individually software configurable using
clearVISN Multichassis Manager to connect through one of the front
panel ST fiber optic ports or to one of the DEChub 900MultiSwitch
(MS) chassis backplane LAN segments.</td>
</tr>
<tr>
<td> DECswitch 900EE</td>
<td> Cost-effective, six-port Ethernet-to-Ethernet switch.
The DECswitch 900EE is a six-port "line speed" Ethernet switch
that provides full-speed 802.1D bridging among each of the six
Ethernet segments. It has six Ethernets on the front panel (two
AUI and four 10BaseT). Each of these ports is configurable, via
software, to connect to the front panel connector or alternatively
to one of six internal DEChub 900 MultiSwitch LAN segments. This
feature offers - maximum configuration . Flexibility -- whether
you use the switch in a standalone single-slot rack-and-stack hub
configuration, or install it in a DEChub 900 MultiSwitch hub
chassis.</td>
</tr>
<tr>
<td>DECswitch 900EF </td>
<td> Six port Ethernet-to-FDDI backbone switch.
The DECswitch 900EF is a Ethernet-to-FDDI switch for
the backbone. It has six Ethernet switched ports and one FDDI
switched port, and provides full 802.1D bridging capability among
each of six Ethernet and FDDI LANs. The DECswitch 900EF has six
Ethernet ports on the front panel (two AUI and four 10BaseT) and a
DAS FDDI port. Using HUBwatch software, you can configure any
FDDI or Ethernet port to connect through the front panel or,
through the backplane of a DEChub 900 MultiSwitch. The DECswitch
900EF may also be configured standalone by utilizing the DEHUA or
DEF1H single-slot hub chassis.
</td>
</tr>
<tr>
<td> PEswitch 900TX</td>
<td> Digital's PEswitch 900TX device gives your users dedicated 10 Mb/s
per station switching between Ethernet and FDDI. It combines full
store-and-forward switching technology for data integrity with
high speed switching performance at a very affordable price --
making it the switching product of choice for your desktop
requirements. The PEswitch 900TX unit is an ideal solution for
connecting high-speed workgroups to the FDDI servers or backbones,
while eliminating user disruptions, changes to cabling, or adapter
replacement costs.</td>
</tr>
<tr>
<td> DECbridge 900MX</td>
<td> Same as the DECswitch 900 EF - but shipped before we could
change the name.</td>
</tr>
</table></center>
<hr>
<a name="repeater"><h2>Repeater MIB</h2></a>
The Repeater MIB (RFC1516) specifies three <b>optional</b> traps:
<ul>
<li>rptrHealth
<li>rptrGroupChange
<li>rptrResetEvent
</ul>
<pre>
-- Traps for use by Repeaters
-- Traps are defined using the conventions in RFC 1215 [6].
rptrHealth TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrHealth trap conveys information related
to the operational status of the repeater. This
trap is sent either when the value of
rptrOperStatus changes, or upon completion of a
non-disruptive test.
The rptrHealth trap must contain the
rptrOperStatus object. The agent may optionally
include the rptrHealthText object in the varBind
list. See the rptrOperStatus and rptrHealthText
objects for descriptions of the information that
is sent.
The agent must throttle the generation of
consecutive rptrHealth traps so that there is at
least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
hubHealth notification."
::= 1
rptrGroupChange TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrGroupIndex }
DESCRIPTION
"This trap is sent when a change occurs in the
group structure of a repeater. This occurs only
when a group is logically or physically removed
from or added to a repeater. The varBind list
contains the identifier of the group that was
removed or added.
The agent must throttle the generation of
consecutive rptrGroupChange traps for the same
group so that there is at least a five-second gap
between traps of this type. When traps are
throttled, they are dropped, not queued for
sending at a future time. (Note that 'generating'
a trap means sending to all configured
recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
groupMapChange notification."
::= 2
rptrResetEvent TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrResetEvent trap conveys information
related to the operational status of the repeater.
This trap is sent on completion of a repeater
reset action. A repeater reset action is defined
as an a transition to the START state of Fig 9-2
in section 9 [IEEE 802.3 Std], when triggered by a
management command (e.g., an SNMP Set on the
rptrReset object).
The agent must throttle the generation of
consecutive rptrResetEvent traps so that there is
at least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)
The rptrResetEvent trap is not sent when the agent
restarts and sends an SNMP coldStart or warmStart
trap. However, it is recommended that a repeater
agent send the rptrOperStatus object as an
optional object with its coldStart and warmStart
trap PDUs.
The rptrOperStatus object must be included in the
varbind list sent with this trap. The agent may
optionally include the rptrHealthText object as
well."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset
notification."
::= 3
</pre>
<hr>
<a name="bridgeMIB"><h2>Bridge MIB Traps</h2></a>
Neither of the <b>optional</b> bridge MIB (RFC1493) traps are supported
by the DECswitch900 series modules. However, the GigaSwitch products do support
these traps.
<p>
Bridge MIB traps include "newRoot" and "topologyChange" - both of which
are described in detail in RFC1493.
<pre>
-- Traps for use by Bridges
-- Traps for the Spanning Tree Protocol
newRoot TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"The newRoot trap indicates that the sending agent
has become the new root of the Spanning Tree; the
trap is sent by a bridge soon after its election
as the new root, e.g., upon expiration of the
Topology Change Timer immediately subsequent to
its election. Implementation of this trap is
optional."
::= 1
topologyChange TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"A topologyChange trap is sent by a bridge when
any of its configured ports transitions from the
Learning state to the Forwarding state, or from
the Forwarding state to the Blocking state. The
trap is not sent if a newRoot trap is sent for the
same transition. Implementation of this trap is
optional."
::= 2
</pre>
<hr>
<a name="fddiMIB"><h2>FDDI MIB Traps</h2></a>
There are no traps defined in the FDDI MIB (RFC1512).
<hr>
<a name="port"><h2>DECconcentrator 900 Enterprise Specific Port Traps</h2></a>
The DECconcentrator 900 series products, listed below, support one enterprise specific trap:
the port trap.
<p>
<center><table border>
<a name="listOfConcentrators"></a>
<caption><b>List of DECconcentrator Products</b></caption>
<th>Product Name</th>
<th>Product Description</th>
<tr>
<td>DECconcentrator 900TH</td>
<td>he DECconcentrator 900TH offers maximum configuration denisity
with sixteen total ports; (fourteen front panel, two backplane)
- four are software configurable as FDDI, A, B, M, or S ports.
It also gives you flexible media options - two front panel ports
support the modular physical media dependent (PMD) design
allowing single-mode fiber, multimode fiber, and unshielded
twisted-pair. The DEChub ONE-MX single slot hub offers two more
additional modular physical media dependent slots.</td>
</tr>
<tr>
<td>DECconcentrator 900FH</td>
<td>The DECconcentrator 900FH offers the lowcost connections to FDDI
using multimode fiber media via SC connectors. Maximum connection
denisity is also available with sixteen total ports; (fourteen
front panel, two backplane) - four are software configurable as
FDDI, A, B, M, or S ports. It also gives you flexible media
options - two front panel ports support the modular physical
media dependent (PMD) design allowing single-mode fiber, multimode
fiber, and unshielded twisted-pair.</td>
</tr>
<tr>
<td>DECconcentrator 900MX</td>
<td>The DECconcentrator 900MX offers maximum configuration flexibility
with eight total ports; (six front panel, two backplane) - four
are software configurable as FDDI, A, B, M, or S ports. It also
gives you flexible media options - the modular physical media
dependent (PMD) design supports single-mode fiber, multimode
fiber, and unshielded twisted-pair, on a per-port basis.</td>
</tr>
<tr>
<td></td>
<td></td>
</tr>
</center></table>
<pre>
</pre>
The port trap conveys information about the change of an FDDI
port's state. For example, a "disconnecting" port causes a
port trap to be sent. Another trap is sent when the port is
"connecting". Other state changes also cause port traps.
The port traps is disabled by default. It may be enabled by
setting the esysFddiPortTrapSwitch.
<p>
Once enabled, port traps are sent whenever "fddimibPORTConnectState"
changes. "fddimibPORTConnectState" changes as port connections are created and
destroyed (per the SMT spec). Refer to the fddi mib for details about
fddimibPORTConnectState. Port traps are enterprise specific 1 traps (generic-
trap-type = 6, specific-trap-type = 1). Details about which port was
affected, and the new connect state are carried in the "interesting
information" field of the trap message.
<p>
The TRAP-TYPE definition went into the products release notes at one
point.
<pre>
decConcentratorPortTrap TRAP-TYPE
ENTERPRISE { elanext } -- This might be wrong!
VARIABLES { fddimibPORTConnectState }
DESCRIPTION
"The value of fddimibPortConnectState has changed.
This is usually caused by a station inserting
into the FDDI ring, or detatching from the ring."
::= 1
</pre>
People often expect LinkUp and LinkDown traps to be sent when a concentrator
port is affected. This isn't done because of the distinction between a
'link' and a 'port'.
(Refer to <a href="#link"> Link Traps.)</a>.)
<p>
<hr>
<a name="rAbout"><h2>RouteAbout Acesss and Central</h2></a>
From COMMON_BROUTERS notes conference, note 160.3:
<pre>
All comet routers can be configured to generate enterprise
specific traps. You can configure ELS (the event subsystem)
so that some or all ELS events also generate an enterprise
specific trap. For example, you can use the following command
to generate an ELS enterprise specific trap whenever an SNMP ELS
event occurs.
At MOS command prompt
*t 6
Gateway user configuration
Config>event
Event Logging System user configuration
ELS config>trap sub snmp all
ELS config>list all
...
Subsystem: SNMP
Disp levels: STANDARD
Trap levels: ALL
....
Then restart the router.
</pre>
Refer to <a href="http://www-router.lkg.dec.com/~johnp/snmp/mibs/decvars-cc-v1.1.txt">
http://www-router.lkg.dec.com/~johnp/snmp/mibs/decvars-cc-v1.1.txt</a>
for the Digital version of the Proteon enterprise MIB variables that
includes Proteon supplied definitions of the ELS trap types.
<hr>
<h2><a name="listOfVNs">VNswitch Product Descriptions</a></h2>
<center><table border>
<caption><b>VNswitch Product Descriptions</b></caption>
<th>Product Name</th>
<th>Product Description</th>
<tr>
<td>VNswitch 900EX</td>
<td>12 switched Ethernet ports and two Fast Ethernet ports.</td>
</tr>
<tr>
<td>VNswitch 900EA</td>
<td>12 switched Ethernet ports and one ATM port.</td>
</tr>
<tr>
<td>VNswitch 900EF</td>
<td>12 switched Ethernet ports and one FDDI port pair.</td>
</tr>
<tr>
<td>VNswitch 900EE</td>
<td>24 switched Ethernet ports. </td>
</tr>
</table></center>
</body>
</html>
|
| 4307.9 | | NSDP01::RV | | Wed Apr 30 1997 06:37 | 6 |
| Shawn,
Sorry to be so late but I just had a view of the summary you have made.
This is very nice and complete
Many thanks.
Robert Vandenberghe
|
| 4307.10 | is this publicy available oin the www? | UNITED::thornd.olo.dec.com::WorkBenchUser | | Wed May 28 1997 07:45 | 12 |
| Shawn
this is great information...
is it already on the www somewhere?
if not can you possibly please post it for all our customers to see?
many thanks
dave
|
| 4307.11 | Not there yet. | NETCAD::GALLAGHER | | Wed May 28 1997 10:13 | 6 |
| Hi Dave,
It's not on the web yet. I'll try to find a place for in our internal
and external pages.
-Shawn
|