Guest

Cisco IOS Software Releases 12.1 T

Event MIB Support

Downloads

Table Of Contents

Event MIB Support

Feature Overview

Benefits

Restrictions

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites

Understanding the Event MIB

Configuration Tasks

Monitoring and Maintaining the Event MIB

Configuration Examples

Setting The Trigger in the Trigger Table

Creating an Event in the Event Table

Setting The Trigger Threshold in the Trigger Table

Activating the Trigger

Command Reference

show management event

debug management event

Glossary

Appendix: Draft of Disman-Event-MIB


Event MIB Support


This feature module describes the addition of Event MIB Support for Simple Network Management Protocol (SNMP) in Cisco IOS Release 12.1(3)T and Cisco IOS Release 12.0(12)S. It includes information on the benefits of the new feature, supported platforms, supported standards, and new Cisco IOS commands that can be used to monitor Event MIB activity.

Release
Modification

12.1(3)T, 12.0(12)S

This feature was introduced.

12.2 (4)T

Event MIB Persistence was introduced.

The Event MIB was made compliant with RFC 2981

12.2 (4)T3

Support for this feature was added for the Cisco 7500 series


Feature History for Event MIB Support

This document includes the following sections:

Feature Overview

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites

Understanding the Event MIB

Monitoring and Maintaining the Event MIB

Configuration Examples

Command Reference

Glossary

Appendix: Draft of Disman-Event-MIB

Feature Overview

The Event MIB provides the ability to monitor Management Information Base (MIB) objects on a local or remote system using SNMP and initiate simple actions whenever a trigger condition is met (for example, an SNMP trap can be generated when an object is modified). When notifications are triggered by events, the Network Management System (NMS) does not need to constantly poll managed devices to find out if something has changed.

When combined with the Expression MIB support introduced in Cisco IOS Release 12.0(5)T, Event MIB support in Cisco IOS software provides a flexible and efficient way to monitor complex conditions on network devices.


Note The implementation of the Event MIB for Cisco IOS Release 12.1(3)T and 12.0(12)S is based on a Draft version of the MIB. For implementation details of this draft, see draft-ietf-disman-event-mib-10.txt file in the "Appendix: Draft of Disman-Event-MIB" section of this document.


Benefits

By allowing SNMP notifications to take place only when a specified condition is met, Event MIB support reduces the load on affected devices, significantly improving the scalability of network management solutions.

Restrictions

The Event MIB can be made to monitor any MIB object. However, the type of sampling dictates the types of objects that can be monitored.

Event MIB configuration is done with applications external to Cisco IOS software. One method for performing network monitoring of Event MIB conditions is to use a workstation to perform SNMP Gets and Sets on the SNMP agent running on the routing device. Another method is to use the functionality built in to a network management application (typically a GUI-based program running on a dedicated computer) which is compatible with Cisco IOS software.

Related Features and Technologies

SNMP

Internet-Draft Distributed Management (Disman) Expression MIB [draft-ietf-disman-event-mib-10.txt]

Related Documents

For SNMP configuration information using Cisco IOS software, see the "Configuring SNMP Support"  chapter of the Release 12.1 Cisco IOS Configuration Fundamentals Configuration Guide and the "SNMP Commands" chapter of the Release 12.1 Cisco IOS Configuration Fundamentals Command Reference.

For information on utilizing SNMP MIB features, see the appropriate documentation for your network management system.

For updates on the implementation of MIBs, see the Cisco.com MIB website at

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

Supported Platforms

The Event MIB is supported on the following platforms in Cisco IOS release 12.1(3)T:

Cisco 2500 series (Cisco 2501-2525)

Cisco 3600 series (Cisco 3620, 3640, 3660)

Cisco MC3810 Multiservice Concentrator

Cisco 4000 series (Cisco 4500-m, 4700, 4700-m)

Cisco AS5200 series

Cisco AS5300 series

Cisco AS5400 series

Cisco AS5800 series

Cisco 7100 series

Cisco 7200 series

Cisco RSP7000/7500 series

Cisco Route Processor Module (RPM) platforms (Cisco MGX 8850)

The Event MIB is supported on the following platforms in Cisco IOS release 12.0(12)S:

Cisco 7200 series

Cisco RSP 7000/7500 series

Cisco 12000 GSR series

Supported Standards, MIBs, and RFCs

Standards

No new or modiried standards are supported by this feature.

MIBs

This feature introduces the Event MIB.

The EVENT-MIB.my file can be downloaded from the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

RFCs

At the time of the release of Cisco IOS Version 12.1(3)T (July 2000), the "Event MIB" is an "Internet Draft" and has not yet been given an RFC classification by the Internet Engineering Task Force (IETF).

Prerequisites

Use of the Event MIB as described in this feature module assumes that you have configured SNMP on your routing devices and are using the SNMP features of an external network management tool (such as the UNIX-based SNMP ultility) or NMS (such as CiscoWorks2000).

Understanding the Event MIB

The Event MIB allows a user or NMS to watch over specified objects and set event triggers based on existence, threshold and boolean tests. An event occurs when a trigger is fired; this means that a specified test on an object returns a value of "true". To create a trigger, a user or NMS configures a trigger entry in the mteTriggerTable of the Event MIB. This trigger entry specifies the object identifier (OID) of the object to be watched. For each trigger entry type (existence, theshold, and boolean triggers), corresponding tables (existence, threshold, and boolean tables) are populated with the information required for carrying out the test. The MIB can be configured so that when triggers are activated (fired), either an SNMP Set is performed, a notification is sent out to the interested host, or both.

Wildcarding is a powerful functionality provided by the Event MIB which allows you to monitor multiple instances of an object. You can specify a single OID for monitoring, or use wildcarding to specify a group of OIDs.

There are nine tables in the Event MIB. They are:

mteTriggerTable

mteTriggerDeltaTable

mteTriggerExistenceTable

mteTriggerBooleanTable

mteTriggerThresholdTable

mteObjectsTable

mteEventTable

mteEventNotificationTable

mteEventSetTable

The trigger entry is set in the trigger table. Each trigger is configured to watch a single object or a group of objects specified by a wildcard (*). The object-type can be any one of the types given below:

INTEGER_TYPE

OCTET_PRIM_TYPE

NULL_TYPE

OBJECT_ID_TYPE

SEQUENCE_TYPE

INTEGER_32_TYPE

IP_ADDR_PRIM_TYPE

COUNTER_TYPE

GAUGE_TYPE

TIME_TICKS_TYPE

OPAQUE_PRIM_TYPE

COUNTER_32_TYPE

GAUGE_32_TYPE

UNSIGNED32_TYPE

COUNTER_64_TYPE

The Event MIB process checks the state of this watched object at predefined intervals. The interval can be configured through the mteTriggerFrequency object. The type of sampling that can be done on an object is of two types:

Absolute

Delta

The test that can be done on the watched object is one or a combination of the following:

Existence

Boolean

Threshold

For each of the above tests the mteTrigger<Exist/Bool/Threshold>Startup can be true or false to indicate whether the trigger should be fired as soon as it is activated or not.

The Existence Test can be one or a combination of the following:

Absent

Present

Changed

The Boolean test can be one of the following:

Unequal

Equal

Less

LessOrEqual

Greater

GreaterOrEqual

The Threshold test can be one of the following:

Rising

Falling

Rising or Falling

The Event Table has an entry for what type of action to take for the event. This could one or both of the following:

Notifications (Traps/Informs)

Sets

The Notification Table contains a list of objects corresponding to an entry in the Event Table. This list of objects is added to the notification sent out when the trigger fires.

The Set Table may contain an object for each event defined in the Event Table. When the trigger fires this object is set to the value specified in the table.

Configuration Tasks

There are no Cisco IOS software configuration tasks associated with the Event MIB. The "Configuration Examples" section gives a sample configuration session using a network management application on an external device. See the "Related Documents" section for information on configuring SNMP on your Cisco routing device.

Monitoring and Maintaining the Event MIB

Use the following commands to monitor Event MIB activity from the Cisco IOS command-line interface:

Command
Purpose

Router# debug management event

Prints messages to the screen whenever a the Event MIB evaluates a specified trigger. These messages are are given in real-time, and are intended to be used by technical support engineers for troubleshooting purposes.

Router# show management event

Displays the SNMP Event values that have been configured on your routing device through the use of the Event MIB.


Configuration Examples

All configuration of Event MIB functionality must be performed though applications using SNMP. The following example provides a step-by-step Event MIB configuration using SNMP research tools available for Sun workstations. The "Setany" commands given below are executed using the SNMP application. Note that these commands are not Cisco IOS CLI commands. This example assumes that SNMP has been configured on your routing device.

In this example, the objective is to monitor ifInOctets for all interfaces. The Event MIB is configured to monitor the delta values of ifInOctets for all interfaces once per minute. If any of the samples exceed the specified threshold of 30, a Trap notification will be sent.

There are four parts to the following example:

Setting The Trigger in the Trigger Table

Creating an Event in the Event Table

Setting The Trigger Threshold in the Trigger Table

Activating the Trigger

Setting The Trigger in the Trigger Table

 
Command
Purpose

Step 1 

setany -v2c $ADDRESS private mteTriggerEntryStatus.4.106.111.104.110.1 -i 5

Creates a trigger row in the table with "john" as the mteOwner and "1" as the trigger name. The index is given in decimal representation of the ASCII value of "john.1".

Step 2 

setany -v2c $ADDRESS private mteTriggerValueID.4.106.111.104.110.1 -d

1.3.6.1.2.1.2.2.1.10

Sets the mteTriggerValueID to the OID to be watched. In this example, the OID to be monitored is ifInOctets.

Step 3 

setany -v2c $ADDRESS private

mteTriggerValueIDWildcard.4.106.111.104.110.1 -i 1

Sets the mteTriggerValueIDWildcard to TRUE to denote a object referenced through wildcarding.

Step 4 

setany -v2c $ADDRESS private mteTriggerTest.4.106.111.104.110.1 -o '20'

Sets the mteTriggerTest to "Threshold".

Step 5 

setany -v2c $ADDRESS private mteTriggerFrequency.4.106.111.104.110.1 -g 60

Sets the mteTriggerFrequency to 60. This means that ifInOctets are monitored once every sixty seconds.

Step 6 

setany -v2c $ADDRESS private mteTriggerSampleType.4.106.111.104.110.1 -i 2

Sets the sample type to "Delta".

Step 7 

setany -v2c $ADDRESS private mteTriggerEnabled.4.106.111.104.110.1 -i 1

Enables the trigger.

Creating an Event in the Event Table

 
Command
Purpose

Step 1 

setany -v2c $ADDRESS private mteEventEntryStatus.4.106.111.104.110.101.118.101.110.11 6 -i 5

Create a row in the Event Table. The mteOwner here is again "john" and mteEventName is "event". The default action is to send out a notification.

Step 2 

setany -v2c $ADDRESS private mteEventEnabled.4.106.111.104.110.101.118.101.110.116 -i 1

Enables the Event.

Step 3 

setany -v2c $ADDRESS private mteEventEntryStatus.4.106.111.104.110.101.118.101.110.11 6 -i 1

Makes the EventRow active.

Setting The Trigger Threshold in the Trigger Table

 
Command
Purpose

Step 1 

setany -v2c $ADDRESS private mteTriggerThresholdRising.4.106.111.104.110.1 -i 30

Sets the Rising Threshold value to 30. Note that a row would already exist for "john.1" in the Trigger Threshold Table.

Step 2 

setany -v2c $ADDRESS private mteTriggerThresholdRisingEventOwner.4.106.111.104.110.1 -D "john"

setany -v2c $ADDRESS private mteTriggerThresholdRisingEvent.4.106.111.104.110.1 -D "event"

Points to the entry in the Event Table that specifies the action that is to be performed.

Activating the Trigger

 
Command
Purpose

Step 1 

setany -v2c $ADDRESS private mteTriggerEntryStatus.4.106.111.104.110.1 -i 1

Makes the trigger active.

To confirm the above configuration is working, ensure that at least one of the interfaces gets more than 30 packets in a minute. This should cause a trap to be sent out after one minute.

Command Reference

This section documents new commands. All other Cisco IOS commands used with this feature are documented in the Release 12.1 Cisco IOS Configuration Fundamentals Command Reference publication. The following commands are documented:

show management event

debug management event

show management event

To display the SNMP Event values that have been configured on your routing device through the use of the Event MIB, use the show management event command in privileged EXEC mode.

show management event

Syntax Description

This command has no arguments or keywords.

Defaults

No default behavior or values.

Command Modes

Privileged EXEC

Command History

Release
Modification

12.1(3)T

This command was introduced.


Usage Guidelines

For information on Event MIB functionality, read the EVENT-MIB.my file on your routing device, or download the file from the Cisco MIB website on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml .

Examples

The following example shows sample output of the show management event command:

Router# show management event
Mgmt Triggers:
 (1): Owner: aseem
   (1): 01, Comment: TestEvent, Sample: Abs, Freq: 120
         Test: Existence Threshold Boolean
         ObjectOwner: aseem, Object: sethi
         OID: ifEntry.10.3, Enabled 1, Row Status 1
      Existence Entry: , Absent, Changed
      StartUp:  Present, Absent
         ObjOwn: , Obj: , EveOwn: aseem, Eve: 09 
      Boolean Entry:
         Value: 10, Cmp: 1, Start: 1
         ObjOwn: , Obj: , EveOwn: aseem, Eve: 09 
      Threshold Entry:
         Rising: 50000, Falling: 20000
         ObjOwn: ase, Obj: 01 RisEveOwn: ase, RisEve: 09 , FallEveOwn: ase, FallEve: 09 

      Delta Value Table:
   (0): Thresh: Rising, Exis: 1, Read: 0, OID: ifEntry.10.3 , val: 69356097
 Mgmt Events:
 (1): Owner: aseem
   (1)Name: 09 , Comment: , Action: Set, Notify, Enabled: 1 Status: 1
      Notification Entry:
         ObjOwn: , Obj: , OID: ifEntry.10.1
      Set:
         OID: ciscoSyslogMIB.1.2.1.0, SetValue: 199, Wildcard: 2 TAG: , ContextName: 

 Object Table:
 (1): Owner: aseem
   (1)Name: sethi, Index: 1, OID: ifEntry.10.1, Wild: 1, Status: 1

debug management event

To monitor the activities of the Event MIB in real time on your routing device, use the debug management event command in privileged EXEC mode. To stop output of debug messages to your screen, use the no form of this command.

debug management event

no debug management event

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging output is disabled by default.

Command Modes

Privileged EXEC

Command History

Release
Modification

12.1(3)T

This command was introduced.


Usage Guidelines

The debug management event command prints messages to the screen whenever the Event MIB evaluates a specified trigger. These messages are are given in real-time, and are intendended to be used by technical support engineers for troubleshooting purposes.

Examples

The following example shows sample output for this command:

Router# debug management event
Event Process Bool: Owner aseem, Trigger 01 
 Event Bool process: invoke event
 Event Bool process: no wildcarding
Event: OID ifEntry.10.3
Event getValue abs: 69847284
 Event Bool process: Trigger Fired !
 mteSetNotifyObjects: 
 Event execOnFiring: sending notification
Event: OID ifEntry.10.1
Event add_objects: Owner , Trigger 
Event add_objects: Owner aseem, Trigger sethi
Event Found Owner: aseem
Event Found Name: sethi
Event: OID ifEntry.10.1
 Event: sending trap with 7 OIDs
Event: OID mteHotTrigger.0
Event: OID mteHotTargetName.0
Event: OID mteHotContextName.0
Event: OID ifEntry.10.3
Event: OID mteHotValue.0
Event: OID ifEntry.10.1
Event: OID ifEntry.10.1
Event mteDoSets: setting oid
 Event mteDoSets: non-wildcarded oid
Event: OID ciscoSyslogMIB.1.2.1.0
Event Thresh Process: Owner aseem, Trigger 01 
 Event Thresh process: invoke rising event
 Event Thresh process: invoke falling event
 Event Thresh process: no wildcarding
Event: OID ifEntry.10.3
Event getValue abs: 69847284
Event Existence Process: Owner aseem, Trigger 01 
 Event Exist process: invoke event
 Event Exist process: no wildcarding
Event: OID ifEntry.10.3
Event getValue abs: 69847284
 Event Check ExistTrigger for Absent
 Event Check ExistTrigger for Changed
Router# no debug management event

Glossary

IETF—Internet Engineering Task Force. The IETF is the body (supervised by the Internet Architecture Board) that defines Internet operating standards such as SNMP MIBs, and publishes RFCs for use by the Internet community. The IETF's web site address is http://www.ietf.org.

MIB---Management Information Base. The MIBs referred to in this document are MIB modules. These modules contain definitions of management information for use by SNMP network management systems.

OID—Object Identifier. The values for OIDs are defined in specific MIB modules.

NMS—Network Management System. An application or suite of applications designed to monitor networks using SNMP. CiscoView is one example of an NMS.

SNMP—Simple Network Management Protocol. Network management protocol used almost exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices, and to manage configurations, statistics collection, performance, and security.

Appendix: Draft of Disman-Event-MIB

Expires 7 December 2000

Network Working Group                           Editor of this version:
Internet-Draft                                  Ramanathan R. Kavasseri
Expires December 2000                               Cisco Systems, Inc.
                                            Author of previous version:
                                                            Bob Stewart
                                                            7 June 2000




                               Event MIB

                   draft-ietf-disman-event-mib-10.txt


                          Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.''

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Distribution of this document is unlimited. Please send comments to the
Distributed Management Working Group, <disman@dorothy.BMC.com>.


Copyright Notice

Copyright (C) The Internet Society (2000).  All Rights Reserved.
















Internet Draft      Distributed Management Event MIB         7 June 2000


1.  Abstract

This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community.  In particular, it describes managed objects that can be used
to manage and monitor MIB objects and take action through events.

The Event MIB provides the ability to monitor MIB objects on the local
system or on a remote system and take simple action when a trigger
condition is met.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.


2.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

    o   An overall architecture, described in RFC 2571 [RFC2571].

    o   Mechanisms for describing and naming objects and events for the
        purpose of management. The first version of this Structure of
        Management Information (SMI) is called SMIv1 and described in
        STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
        1215 [RFC1215]. The second version, called SMIv2, is described
        in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580
        [RFC2580].

    o   Message protocols for transferring management information. The
        first version of the SNMP message protocol is called SNMPv1 and
        described in STD 15, RFC 1157 [RFC1157]. A second version of the
        SNMP message protocol, which is not an Internet standards track
        protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
        and RFC 1906 [RFC1906]. The third version of the message
        protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
        RFC 2572 [RFC2572] and RFC 2574 [RFC2574].

    o   Protocol operations for accessing management information. The
        first set of protocol operations and associated PDU formats is
        described in STD 15, RFC 1157 [RFC1157]. A second set of
        protocol operations and associated PDU formats is described in





Expires 7 December 2000                                         [Page 2]





Internet Draft      Distributed Management Event MIB         7 June 2000


        RFC 1905 [RFC1905].

    o   A set of fundamental applications described in RFC 2573
        [RFC2573] and the view-based access control mechanism described
        in RFC 2575 [RFC2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [RFC2570].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2. A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations. The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64). Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process. However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB. It may not be possible to meaningfully monitor Counter64 objects
   using an SMIv1 version of the MIB.



























Expires 7 December 2000                                         [Page 3]





Internet Draft      Distributed Management Event MIB         7 June 2000


3.  Overview

With network sizes well beyond the ability of people to manage them
directly, automated, distributed management is vital.  An important
aspect of such management is the ability of a system to monitor itself
or for some other system to monitor it.

The Event MIB provides the ability to monitor MIB objects on the local
system or on a remote system and take simple action when a trigger
condition is met.

The MIB is intended to suit either a relatively powerful manager or mid-
level manager, as well as a somewhat more limited self-managing system.


4.  Relationship to Other MIBs

The Event MIB is based on extensive experience with the RMON MIB
[RFC1757] and provides a superset of the capabilities of the RMON alarm
and event groups.  Conceptually, the key extension is the ability to
allow alarms to be generated for MIB objects that are on another network
element. The Event MIB calls "triggers" what the RMON MIB called
"alarms," but the concepts are the same.  Event MIB triggers maintain
the RMON handling of thresholds and add the concept of booleans.  Event
MIB events maintain the RMON concept of sending an SNMP notification in
response to a trigger and add the concept of setting a MIB object.

The Event MIB is the successor and update to SNMPv2's Manager-to-Manager
MIB [RFC1451] which was declared Historic pending this work.

The Event MIB depends on the services of the SNMPv3 Management Target
and Notification MIBs [RFC2573].

The Event MIB is nicely complemented by the Distributed Management
Expression MIB [RFCExpressionMIB], which is the expected source of
boolean objects to monitor.  Note that there is considerable overlap
between the wildcard and delta sample capabilities of the Event and
Expression MIBs.  A carefully-planned implementation might well use
common code to provide the overlapping functions.


5.  MIB Sections

The MIB has four sections: triggers, objects, events, and notifications.
Triggers define the conditions that lead to events.  Events may cause





Expires 7 December 2000                                         [Page 4]





Internet Draft      Distributed Management Event MIB         7 June 2000


notifications.

The trigger table lists what objects are to be monitored and how and
relates each trigger to an event.  It has supplementary, companion
tables for additional objects that depend on the type of test done for
the trigger.

The objects table lists objects that can be added to notifications based
on the trigger, the trigger test type, or the event that resulted in the
notification.

The event table defines what happens when an event is triggered: sending
a notification, setting a MIB object or both.  It has supplementary,
companion tables for additional objects that depend on the action taken.

The notification section defines a set of generic notifications to go
with the events and for Event MIB error handling, and it defines a set
of objects to put in those notifications.
































Expires 7 December 2000                                         [Page 5]





Internet Draft      Distributed Management Event MIB         7 June 2000


The following diagram describes the relationships between the tables
in the Event MIB.


+-----------------------------+
| mteTriggerEntry             |      subclassed by:
|  { mteOwner,                |---+
|    IMPLIED mteTriggerName } |   +-- mteTriggerDeltaEntry
|                             |   |
|                             |   +-- mteTriggerExistenceEntry
|                             |   |
|                             |   +-- mteTriggerBooleanEntry
|                             |   |
|                             |   +-- mteTriggerThresholdEntry
|                             |
|       mteTrigger*Event -------------------------------->+
|                             |                           |
|       mteTriggerObjects ------------------>+            |
+-----------------------------+              |            |
                                             |            |
+-----------------------------+              V            |
| mteObjectsEntry             |              |            |
|  { mteOwner,                |<-------------+            |
|    mteObjectsName,          |                           |
|    mteObjectsIndex }        |                           |
+-----------------------------+                           |
                                                          V
+---------------------------+                             |
| mteEventEntry             |<----------------------------+
|  { mteOwner,              |
|    IMPLIED mteEventName } |
|                           |
|            mteEventAction---> + (condition)
+---------------------------+   |
                                V
+---------------------------+   |   +---------------------------+
| mteEventNotificationEntry |   |   | mteEventSetEntry          |
|  { mteOwner,              |<--+-->|  { mteOwner,              |
|    IMPLIED mteEventName } |       |    IMPLIED mteEventName } |
+---------------------------+       +---------------------------+










Expires 7 December 2000                                         [Page 6]





Internet Draft      Distributed Management Event MIB         7 June 2000


6.  Operation

The Event MIB is instrumentation for a distributed management
application that monitors MIB objects.  In its simplest form this
application monitors individual, local MIB objects, just as an RMON
probe fulfills the functions implied by RMON's alarm and event
operation.  Additionally the application can monitor remote objects and
wildcarded groups of objects.

Remote monitoring uses the tag service of the Management Target MIB
[RFC2573] to select and access remote systems as an ordinary SNMP-based
management application.  Local monitoring may be via a more intimate,
local interface which may, for example, bypass SNMP encoding but
otherwise is functionally identical to remote SNMP operation, including
the application of access control.  A self-management only system MAY
not implement remote monitoring.

Wildcards indicate that the application SHOULD use a GetNext-type
operation to find the zero or more instances implied by a truncated
object identifier, just like an ordinary SNMP-based management
application.  Each instance of a wildcard is treated as if it were a
separate entry, that is the instances of a wildcarded object are
independent of one another.  For example, a wild-carded object may
trigger an event, and result in the setting of another wildcarded
object.  The instance that satisfied the trigger function is used to
perform the set function.  All of this takes place independently of any
additional instances that may fill the wildcard.

Error handling is by notification.  These error notifications SHOULD be
enabled only for the diagnosis of problems indicated by error counters.
If minimizing the probability of notification loss is a concern they
SHOULD be transmitted as Inform PDUs as described in the [SNMP-TARGET-
MIB] or directed to a log as described in the Notification Log MIB
[rfcNotificationLogMIB]. Note that this does not mean the Notification
Log MIB is REQUIRED, since in fact notifications usually are not lost,
but that the Notification Log MIB can be helpful with this as well as
other MIBs that include notifications.

Although like most MIBs this one has no explicit controls for the
persistence of the values set in configuring events, a robust, polite
implementation would certainly not force its managing applications to
reconfigure it whenever it resets.

Again, as with most MIBs, it is implementation-specific how a system
provides and manages such persistence.  To speculate, one could imagine,





Expires 7 December 2000                                         [Page 7]





Internet Draft      Distributed Management Event MIB         7 June 2000


for example, that persistence depended on the context in which the
expression was configured, or perhaps system-specific characteristics of
the expression's owner.  Or perhaps everything in a MIB such as this
one, which is clearly aimed at persistent configuration, is
automatically part of a system's other persistent configuration.


7.  Security

Security of Event MIB entries depends on SNMPv3 access control for the
entire MIB or for subsets based on entry owner names.

Security of monitored objects for remote access depends on the
Management Target MIB [RFC2573].  Security for local access can depend
on the Management Target MIB or on recording appropriate security
credentials of the creator of an entry and using those to access the
local objects.  These security credentials are the parameters necessary
as inputs to isAccessAllowed from the Architecture for Describing SNMP
Management Frameworks.  When accessing local objects without using a
local target tag, the system MUST (conceptually) use isAccessAllowed to
ensure that it does not violate security.

To facilitate the provisioning of access control by a security
administrator for this MIB itself using the View-Based Access Control
Model (VACM) defined in RFC 2275 [RFC2575] for tables in which multiple
users may need to independently create or modify entries, the initial
index is used as an "owner index". Such an initial index has a syntax of
SnmpAdminString, and can thus be trivially mapped to a securityName or
groupName as defined in VACM, in accordance with a security policy.

If a security administrator were to employ such an approach, all entries
in related tables belonging to a particular user will have the same
value for this initial index.  For a given user's entries in a
particular table, the object identifiers for the information in these
entries will have the same sub-identifiers (except for the "column" sub-
identifier) up to the end of the encoded owner index. To configure VACM
to permit access to this portion of the table, one would create
vacmViewTreeFamilyTable entries with the value of
vacmViewTreeFamilySubtree including the owner index portion, and
vacmViewTreeFamilyMask "wildcarding" the column sub-identifier.  More
elaborate configurations are possible.









Expires 7 December 2000                                         [Page 8]





Internet Draft      Distributed Management Event MIB         7 June 2000


8.  Definitions

DISMAN-EVENT-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    Integer32, Unsigned32,
    NOTIFICATION-TYPE, Counter32,
    Gauge32, mib-2, zeroDotZero         FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, RowStatus,
    TruthValue                FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP,
    NOTIFICATION-GROUP             FROM SNMPv2-CONF
    sysUpTime                 FROM SNMPv2-MIB
    SnmpTagValue              FROM SNMP-TARGET-MIB
    SnmpAdminString           FROM SNMP-FRAMEWORK-MIB;

dismanEventMIB MODULE-IDENTITY
    LAST-UPDATED "200006070000Z"            -- 7 June 2000
    ORGANIZATION "IETF Distributed Management Working Group"
    CONTACT-INFO "Ramanathan Kavasseri
                  Cisco Systems, Inc.
                  170 West Tasman Drive,
                  San Jose CA 95134-1706.
                  Phone: +1 408 526 4527
                  Email: ramk@cisco.com"
    DESCRIPTION
     "The MIB module for defining event triggers and actions
     for network management purposes."
-- Revision History

       REVISION     "200006070000Z"            -- 7 June 2000
       DESCRIPTION  "This is the initial version of this MIB.
                    Published as RFC xxxx"
    ::= { mib-2 xx } -- final assignment by IANA at publication time

dismanEventMIBObjects OBJECT IDENTIFIER ::= { dismanEventMIB 1 }

-- Management Triggered Event (MTE) objects

mteResource           OBJECT IDENTIFIER ::= { dismanEventMIBObjects 1 }
mteTrigger            OBJECT IDENTIFIER ::= { dismanEventMIBObjects 2 }
mteObjects            OBJECT IDENTIFIER ::= { dismanEventMIBObjects 3 }
mteEvent              OBJECT IDENTIFIER ::= { dismanEventMIBObjects 4 }






Expires 7 December 2000                                         [Page 9]





Internet Draft      Distributed Management Event MIB         7 June 2000


--
-- Textual Conventions
--

FailureReason ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "Reasons for failures in an attempt to perform a management
        request.

        The first group of errors, numbered less than 0, are related
        to problems in sending the request.  The existence of a
        particular error code here does not imply that all
        implementations are capable of sensing that error and
        returning that code.

        The second group, numbered greater than 0, are copied
        directly from SNMP protocol operations and are intended to
        carry exactly the meanings defined for the protocol as returned
        in an SNMP response.

        localResourceLack       some local resource such as memory lacking
                                or mteResourceSampleInstanceMaximum
                                exceeded
        badDestination          unrecognized domain name or otherwise
                                invalid destination address
        destinationUnreachable  can't get to destination address
        noResponse              no response to SNMP request
        badType                 the data syntax of a retrieved object
                                as not as expected
        sampleOverrun           another sample attempt occurred before
                                the previous one completed"

    SYNTAX      INTEGER { localResourceLack(-1),
                          badDestination(-2),
                          destinationUnreachable(-3),
                          noResponse(-4),
                          badType(-5),
                          sampleOverrun(-6),

                          noError(0),

                          tooBig(1),
                          noSuchName(2),
                          badValue(3),





Expires 7 December 2000                                        [Page 10]





Internet Draft      Distributed Management Event MIB         7 June 2000


                          readOnly(4),
                          genErr(5),
                          noAccess(6),
                          wrongType(7),
                          wrongLength(8),
                          wrongEncoding(9),
                          wrongValue(10),
                          noCreation(11),
                          inconsistentValue(12),
                          resourceUnavailable(13),
                          commitFailed(14),
                          undoFailed(15),
                          authorizationError(16),
                          notWritable(17),
                          inconsistentName(18) }
--
-- Resource Control Section
--

mteResourceSampleMinimum OBJECT-TYPE
    SYNTAX      Integer32 (1..2147483647)
    UNITS       "seconds"
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "The minimum mteTriggerFrequency this system will
        accept.  A system may use the larger values of this minimum to
        lessen the impact of constant sampling.  For larger
        sampling intervals the system samples less often and
        suffers less overhead.  This object provides a way to enforce
        such lower overhead for all triggers created after it is
        set.

        Unless explicitly resource limited, a system's value for
        this object SHOULD be 1, allowing as small as a 1 second
        interval for ongoing trigger sampling.

        Changing this value will not invalidate an existing setting
        of mteTriggerFrequency."
    ::= { mteResource 1 }

mteResourceSampleInstanceMaximum OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "instances"
    MAX-ACCESS  read-write





Expires 7 December 2000                                        [Page 11]





Internet Draft      Distributed Management Event MIB         7 June 2000


    STATUS      current
    DESCRIPTION
        "The maximum number of instance entries this system will
        support for sampling.

        These are the entries that maintain state, one for each
        instance of each sampled object as selected by
        mteTriggerValueID.  Note that wildcarded objects result
        in multiple instances of this state.

        A value of 0 indicates no preset limit, that is, the limit
        is dynamic based on system operation and resources.

        Unless explicitly resource limited, a system's value for
        this object SHOULD be 0.

        Changing this value will not eliminate or inhibit existing
        sample state but could prevent allocation of additional state
        information."
    ::= { mteResource 2 }

mteResourceSampleInstances OBJECT-TYPE
    SYNTAX      Gauge32
    UNITS       "instances"
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The number of currently active instance entries as
        defined for mteResourceSampleInstanceMaximum."
    ::= { mteResource 3 }

mteResourceSampleInstancesHigh OBJECT-TYPE
    SYNTAX      Gauge32
    UNITS       "instances"
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The highest value of mteResourceSampleInstances that has
        occurred since initialization of the management system."
    ::= { mteResource 4 }

mteResourceSampleInstanceLacks OBJECT-TYPE
    SYNTAX      Counter32