Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

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