|
GUIDE TO USING RMON IN DECHUB900 PRODUCTS
V0.1
Author : Denise Brugnoli
Date : July 20, 1995
Group : HUB Products
Contents :
RMON TRAPS
- Overview
- Trap Operation
- Order of creation
- Turning off existing events
- Creating a new event
- Modifying an existing event
- Turning off existing alarms
- Creating a new alarm
- Modifying an existing alarm
- Examples
- Modules implementing RMON and supported alarms
OVERVIEW:
---------
Many of the DEChub 900 family of products implement the alarm group and the
event group of the rmon mib. The alarm group consists of the alarmTable and
requires the implementation of the event group. The event group consists
of the eventTable and the logTable. The alarm table is where configuration
entries that each define a variable, polling period, and threshold parameters
are stored. If an entry is found that has crossed the threshold value, an
event is generated which is processed as specified by the network manager's
entries in the event table. The event table controls the generation and
notification of events from the device.
This document gives the user a walk thru of how to set up:
- a condition to be monitored, and
- an event to be generated once that condition has occured.
For a more complete understanding of the alarmTable and eventTable see rfc1517.
RMON alarm and event functionality is in the DEChub900 Management Agent Module
(MAM) and several repeaters. Default alarms and events are documented in the
product owner's manual of the devices which support this functionality.
You can create a condition to be monitored (alarm) and an event to be sent
once that condition has been reached using an snmp network manager.
The following procedure for setup can be used for all modules that
support the RMON MIB. See Product definition.
Alarm table entries can only be created for variables that resolve to an
ASN.1 primitive type of INTEGER (INTEGER, Counter, Gauge, or TimeTicks).
An alarm table entry consists of the following fields:
alarmIndex - An index that uniquely identifies an entry. *
alarmInterval - The interval, in seconds, over which the data is
sampled and compared with the rising and falling
threshold.
alarmVariable - The object identifier of the particular variable
to be sampled.
alarmSampleType - The method of sampling the selected variable and
calculating the value to be compared against the
thresholds.
alarmValue - The value of the statistic during the last sampling
period. *
alarmStartupAlarm
- The alarm that may be sent when this entry is first
set to valid.
alarmRisingThreshold
- A threshold for the sampled statistic.
alarmFallingThreshold
- A threshold for the sampled statistic.
alarmRisingEventIndex
- The index of the eventEntry that is used when a
rising threshold is crossed.
alarmFallingEventIndex
- The index of the eventEntry that is used when a
falling threshold is crossed.
alarmOwner - The person that configured this entry and is
therefore using the resources assigned to it.
alarmStatus - The status of this alarm entry.
* These fields are not set by the user. The alarmIndex is implicitly
specified when the entry is created. The alarmValue is made available
after the current sampling period.
An event table entry consists of the following fields:
eventIndex - An index that uniquely identifies an entry. *
eventDescription- A comment describing this event.
eventType - The type of notification that will occur upon
the threshold being reached.
eventCommunity - If an SNMP trap is to be sent, it will be sent to
the SNMP community specified.
eventLastTimeSent
- The value of sysUpTime at the time this event entry
last generated an event. *
eventOwner - The entity that configured this entry and is
therefore using the resources assigned to it.
eventStatus - The status of this event entry.
* These fields are not set by the user. The eventIndex is implicitly
specified when the entry is created. The eventLastTimeSent is made
available after the current sampling period.
The Remote Monitor (RMON) Alarms and Events MIB objects, alarmOwner,
eventCommunity and eventOwner, support up to 32 characters. MIB object
eventDescription supports up to 80 characters. The size of the alarmTable
and eventTable is product specific (see Product definition).
TRAP OPERATION:
---------------
SNMP managed devices send trap messages to Network Management Stations (NMS).
Users configure the IP addresses of NMS "trap sinks" which are to
receive the RMON trap messages.
Trap sinks can be configured on all DEChub 900 modules through the devices'
set-up port. With the exception of the DECserver900 products, trap sinks can
also be added via SNMP set-requests to the device's private MIB
(pcomSnmpAuthTrapAddressTable).
Users can specify that when an alarm condition has been reached that a trap
be generated and sent to the trap sinks specified. (see rfc1517 eventType
for more information on how to specify trap generation)
ORDER OF CREATION:
------------------
In order to successfully create a condition to be monitored, you must
first create the events to be executed upon the condition being reached.
A new alarm entry cannot be made valid until the Rising and Falling event
entries (specified by alarmRisingEventIndex and alarmFallingEventIndex)
are valid. If an alarm only has a Rising event then the FallingEventIndex
would be 0 indicating that there is no event. If an alarm only has a
Falling event then the RisingEventIndex would be 0 indicating that there
is no event.
The following describes the procedures a user must follow to manipulate
RMON for a module. Note that the user must follow the syntax of the
NMS he or she is using.
If the user is adding events and alarms to a module in a hub the
community specified would be public-<slot #>. For example if you were to
add an alarm to the module in slot 7 you would specify the community as
public-7.
If the user is adding events and alarms to the Management Agent Module
(MAM) the community string could be public, or whatever community string
has been assigned for the MAM.
To setup a new condition to be monitored the following steps should be
followed: create a rising event (if applicable), create a falling event
(if applicable), and create the condition to be monitored. It is not
necessary for a condition to have both a rising and falling event.
TURNING OFF EXISTING EVENTS:
----------------------------
To invalidate an existing entry the user would set the eventStatus to
invalid(4).
set -com <community> eventStatus[x] 4
This will remove an entry from the module's event table.
If the event being removed is one of the default events provided at
module startup, then this default event will become valid again if the
module is factory reset.
CREATING A NEW EVENT:
---------------------
To create a new event you must first issue a createRequest(2). The
user would issue a createRequest by setting the eventStatus to 2.
set -com <community> eventStatus[x] 2
When the user has finished configuring the entry, he/she makes the
entry valid(1) by setting the eventStatus to 1.
set -com <community> eventDescription[x] "threshold x has been reached"
eventCommunity[x] "public"
eventType[x] 4
eventOwner[x] "John Smith"
eventStatus[x] 1
These 2 set commands will result in a new event being added to the
module's eventTable.
When you create a new RMON event, Digital recommends setting all rows
(objects) in one command.
MODIFYING AN EXISTING EVENT:
----------------------------
While an event's eventStatus is set to valid(1), the following event
mib objects can be modified if necessary: eventDescription,
eventCommunity, eventType and eventOwner.
set -com <community> eventDescription[x] "sample"
set -com <community> eventCommunity[x] "private"
set -com <community> eventType[x] 3
set -com <community> eventOwner[x] "NetManager"
TURNING OFF EXISTING ALARMS:
----------------------------
To invalidate an existing entry the user would set the alarmStatus to
invalid(4).
set -com <community> alarmStatus[x] 4
This will remove an entry from the module's alarm table.
If the alarm being removed is one of the default alarms provided at
module startup, then this alarm will become valid again if the module
is factory reset.
CREATING A NEW ALARM:
---------------------
To create a new alarm you must first issue a createRequest(2). The
user would issue a createRequest by setting the alarmStatus to 2.
set -com <community> alarmStatus[x] 2
When the user has finished configuring the entry, he/she makes the
entry valid(1) by setting the alarmStatus to 1.
set -com <community> alarmInterval[x] 5
alarmSampleType[x] 2
alarmStartupAlarm[x] 1
alarmRisingThreshold[x] 1
alarmFallingThreshold[x] 0
alarmRisingEventIndex[x] 6
alarmFallingEventIndex[x] 0
alarmOwner[x] "John Smith"
alarmVariable[x] 1.3.6.1.4.1.36.2.18.11.5.1.1.1.1.5.0
alarmStatus[x] 1
These 2 set commands will result in a new alarm being added to the
module's alarmTable.
MODIFYING AN EXISTING ALARM:
----------------------------
While an alarm's alarmStatus is set to valid(1), the only alarm mib
object that can be changed is the alarmOwner. All other objects can
not be changed while the alarmStatus is valid(1).
set -com <community> alarmOwner[x] "NetManager"
EXAMPLES:
---------
Example 1: The following is an example of creating an alarm for
erptrTotalRptrErrors and the corresponding event entry. This
example shows how to create a condition that triggers only on
a rising event.
In this example the alarm and event are being added to a repeater in
slot 8 using an snmp tool called NMS.
This first command is a createRequest for an event 7.
nms> set -com public-8 eventStatus[7] 2
This command is used to assign and validate the data which makes up event 7.
The eventType assigned by the user is log-and-trap(4), which means log the
event to a logTable (see rfc1517) and to send the trap to the "trap-sink".
nms> set -com public-8 eventDescription[7] "The total repeater errors."
eventType[7] 4
eventCommunity[7] "public"
eventOwner[7] "John Smith"
eventStatus[7] 1
At this point the event entry is created. We must now set up the condition
to alarm on.
This first command is a createRequest for an alarm 6.
nms> set -com public-8 alarmStatus[6] 2
This command is used to assign and validate the data which makes up alarm
6. The alarmVariable specified is the object identifier for
erptrTotalRptrErrors, the alarmSampleType is a deltaValue(2), the
alarmInterval will be every 2 seconds and the alarmStartupAlarm is a
risingAlarm(1). This alarm will only specify 1 event entry because
the object being monitored will only increase in total not decrease.
(See rfc1517 for more information about deltaValues and risingAlarms.)
nms> set -com public-8 alarmInterval[6] 2
alarmVariable[6] 1.3.6.1.4.1.36.2.18.11.5.1.1.1.1.6.0
alarmSampleType[6] 2
alarmStartupAlarm[6] 1
alarmRisingThreshold[6] 1
alarmFallingThreshold[6] 0
alarmRisingEventIndex[6] 7
alarmFallingEventIndex[6] 0
alarmOwner[6] "John Smith"
alarmStatus[6] 1
EXAMPLES:
---------
Example 2: The following is an example of creating an alarm for
erptrMauTotalMediaUnavailable and the corresponding event entries.
This example shows how to create a condition that triggers either
on a rising or falling event.
In this example the alarm and events are being added to a repeater in
slot 8 using an snmp tool called NMS.
These commands are createRequests for an event 9 and 10.
nms> set -com public-8 eventStatus[9] 2
nms> set -com public-8 eventStatus[10] 2
This command is used to assign and validate the data which makes up event 9.
The eventType assigned by the user is log-and-trap(4), which means log the
event to a logTable (see rfc1517) and to send the trap to the "trap-sink".
nms> set -com public-8 eventDescription[9] "One or more media has become
unavailable."
eventType[9] 4
eventCommunity[9] "public"
eventOwner[9] "John Smith"
eventStatus[9] 1
This command is used to assign and validate the data which makes up event
10. The eventType assigned by the user is log-and-trap(4), which means log
the event to a logTable (see rfc1517) and to send the trap to the
"trap-sink".
nms> set -com public-8 eventDescription[10] "One or more formerly
unavailable media are now
available."
eventType[10] 4
eventCommunity[10] "public"
eventOwner[10] "John Smith"
eventStatus[10] 1
At this point the event entries are created. We must now set up the
condition to alarm on.
This first command is a createRequest for an alarm 8.
nms> set -com public-8 alarmStatus[8] 2
This command is used to assign and validate the data which makes up alarm
8. The alarmVariable specified is the object identifier for
erptrMauTotalMediaUnavailable, the alarmSampleType is a deltaValue(2), the
alarmInterval will be every 2 seconds and the alarmStartupAlarm is a
risingOrFallingAlarm(3). (See rfc1517 for more information about
deltaValues and risingOrFallingAlarms.)
nms> set -com public-8 alarmInterval[8] 2
alarmVariable[8] 1.3.6.1.4.1.36.2.18.11.5.1.1.5.1.1.0
alarmSampleType[8] 2
alarmStartupAlarm[8] 3
alarmRisingThreshold[8] 1
alarmFallingThreshold[8] 1
alarmRisingEventIndex[8] 9
alarmFallingEventIndex[8] 10
alarmOwner[8] "John Smith"
alarmStatus[8] 1
Products implementing RMON are:
Module # of Alarms # Events # log entries
----------------------------------------------------------------------
DEChub 900 (MAM) 20 32 64
Repeater/PORTswitch 20 32 64
MANAGEMENT AGENT MODULE (MAM):
DEFAULT ALARMS (NAME & OBJECTID) TRIGGER OF EVENT
-------------------------------- -----------------
1: chasNumSlotsOccupied The total number of slots occupied
1.3.6.1.4.1.36.2.18.11.1.1.1.1.2.0 has changed.
2: chasEnvironChanges The total number of environmental
1.3.6.1.4.1.36.2.18.11.1.1.1.10.1.0 changes, includes all temperature-
yellows, temperature-reds, and any
time a temperature warning returns
to temperature-normal.
3: chasPowerConfigNumSupplies The total number of power supplies
1.3.6.1.4.1.36.2.18.11.1.1.1.7.2.0 has changed.
4: chasPowerConfigRedundancyState Power supply N-plus-1 power
1.3.6.1.4.1.36.2.18.11.1.1.1.7.4.0 redundancy state has changed.
5: chasConnChanges The total number of backplane
1.3.6.1.4.1.36.2.18.11.1.1.1.5.2.0 connections has changed.
6: pcomEsysNVRAMavailableOctets There is no more memory for
1.3.6.1.4.1.36.2.18.11.2.7.6.0 nonvolatile parameters.
7: pcomEsysNVRAMfailedFlag The nonvolatile memory has failed.
1.3.6.1.4.1.36.2.18.11.2.7.4.0
REPEATER/PORTswitch (see Matrix below):
DEFAULT ALARMS (NAME & OBJECTID) TRIGGER OF EVENT
-------------------------------- -----------------
1: icomEnvironTotalFailures The module has a fan failure or
0.1.7.2.0 overheating condition.
2: pcomEsysNVRAMavailableOctets There is no more memory for
1.3.6.1.4.1.36.2.18.11.2.7.6.0 nonvolatile parameters.
3: rptrTotalPartitionedPorts One or more ports has been
1.3.6.1.2.1.22.1.1.6.0 autopartitioned, or a port that
was previously autopartitioned
is now operational.
4: erptrHealthTextChanges The module's operational state
1.3.6.1.4.1.36.2.18.11.5.1.1.1.1.4.0 has changed.
5: erptrTotalPortEvents The total number of times a port
1.3.6.1.4.1.36.2.18.11.5.1.1.1.1.5.0 has become nonoperational,
autopartitioned, or unavailable.
6: erptrTotalRptrErrors The total number of errors for
1.3.6.1.4.1.36.2.18.11.5.1.1.1.1.6.0 this module.
7: erptrDprTotalStateChange The module's link state change has
1.3.6.1.4.1.36.2.18.11.5.1.1.3.1.1.0 occurred while using redundant-link
configuration.
8: erptrSecurityRptrSecurityViolation A security violation has occurred
1.3.6.1.4.1.36.2.18.11.5.1.1.4.1.1.0 on one or more ports.
9: erptrMauTotalMediaUnavailable One or more media have become
1.3.6.1.4.1.36.2.18.11.5.1.1.5.1.1.0 available or unavailable.
* indicates the module supports the alarm
+-------------------+-----------------------------------+
| REPEATER NAME | Alarms supported by number |
| +-----------------------------------+
| | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
+-------------------+---+---+---+---+---+---+---+---+---+
| DECrepeater900TM | * | * | * | * | * | * | | * | * |
+-------------------+---+---+---+---+---+---+---+---+---+
| DECrepeater900GM | * | * | * | * | * | * | | * | * |
+-------------------+---+---+---+---+---+---+---+---+---+
| PORTswitch900CP | * | * | * | * | * | * | | * | * |
+-------------------+---+---+---+---+---+---+---+---+---+
| PORTswitch900FP | * | * | * | * | * | * | * | * | * |
+-------------------+---+---+---+---+---+---+---+---+---+
| PORTswitch900TP | * | * | * | * | * | * | * | * | * |
+-------------------+---+---+---+---+---+---+---+---+---+
|