Conference netcad::hub_mgnt

    I'm not too familiar with RMON in gereal, but I'd like to learn,
    specially because the customers want to know...
    
    1) The basenote indicates that the new functionality will apply only to
       900-type repeaters. In earlier notes I was led to believe that it
       was something that would apply to both 90 and 900 modules. 
    
       Will 90 type modules eventually follow?
    
    2) Am I correct in asuming that an RMON module is not required anymore 
       if a repeater with the new firmware is used? Previously, an RMON
       module at the backbone side of a repeater enabled us to monitor that 
       particular ethernet segment, without really enabling managment of the 
       output ports of that repeater. Correct?
    
    Thanks
    
    Rolf 

    >      Will 90 type modules eventually follow?
    
    The DECrepeater 90TS and 90FS should eventually get RMON alarms and
    events support. This will not happen at the V4.1 HUBwatch/consolidated 
    firmware kit wave. Priority was given to putting in stackable
    management code to manage in a MultiStack System.
    
    >    2) Am I correct in asuming that an RMON module is not required 
    >	 anymore if a repeater with the new firmware is used? 
    
    It depends on what you want to monitor. First of all, all repeaters are 
    not created equal. Some repeaters will get only Alarms and Events,
    others, such as PORTswitches and some new ones on the drawing board, 
    will have Alarms, Events, Statistics, and History. The Statistics and 
    History monitoring will only occur on the backplane segment
    connections, not on every port.
    
    If you want to have monitoring and analysis equivalent to a
    DECpacketprobe, you will still have to buy a DECpacketprobe.

    Many thanks!
    
    Rolf

    
    So, do we now have RMON support as described in the base note .0, with
    the current firmware that has been released?

    Yes,  as I understand it, RMON A&E is supported in the latest available
    firmware for high-end repeaters and MAM. Its not yet in the switches or
    90 repeaters.
    
    -Mike

    It was brought to my attention today that I have listed the rfc
    incorrectly.  The correct rfc is 1757 Titled: "Remote Network
    Monitoring Management Information Base".  Sorry for any confusion 
    this may have caused.
    
    -Denise

               GUIDE TO USING RMON IN DECHUB900 PRODUCTS
                               V0.2


Author   : Denise Brugnoli
Date     : November 8, 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 rfc1757.
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 rfc1757 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 rfc1757) 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 rfc1757 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 rfc1757) 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 rfc1757) 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 rfc1757 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   | * | * | * | * | * | * | * | * | * |
  +-------------------+---+---+---+---+---+---+---+---+---+

    Is RFC 1757 the same as "RMON II"?
    
    Are we planning to support RMON II in our repeaters and switches, and
    what does it provide in addition to RMON?
    
    Thank you
    Jeannie

>    Is RFC 1757 the same as "RMON II"?

No.  It's very different.  RMON is still relevant even after RMON-II 
comes out.

>    Are we planning to support RMON II in our repeaters and switches, and
>    what does it provide in addition to RMON?

No, no plans yet.

In broad strokes, RMON-II provides more advanced features like protocol 
monitoring.  RMON allows datalink layer monitoring (stuff like frames 
received, runts, etc) for Ethernet, Token ring and FDDI (not a standard 
yet though).  RMON-II will let you monitor what types of protocol packets
are going from station to station.  For example, you can monitor IP,
IPX, or AppleTalk traffic.

Are you received customers requests for RMON-II?
							-Shawn

    > Are you received customers requests for RMON-II?
    
    Hi Shawn
    
    A commitment to RMON II is stipulated in a current tender.  I think
    it will be appearing more in the future.
    
    Thanks very much for your quick response and Merry Xmas
    Jeannie