Internet Draft G. Nunzi
Document: draft-nunzi-check-mib-00.txt J. Quittek
Expires: June 2004 M. Brunner
T. Dietz
NEC
December 2003
Definitions of Managed Objects for the Health Check Operations
<draft-nunzi-check-mib-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community,
that is targeted at increasing scalability of network monitoring via
SNMP. In particular, the MIB module defined in this document
describes a set of managed objects that allow to define a check
procedure on a managed device. The result of the check is
accumulated into a single managed object that can be read by a
manager instead of reading all individual managed objects to be
checked during the check procedure.
Nunzi, Quittek, Brunner, Dietz [Page 1]
Internet-Draft December 2003
Table of Contents
1 Introduction ................................................. 3
2 The Internet-Standard Management Framework ................... 3
3 Overview ..................................................... 3
3.1 Related MIB Modules ........................................ 4
3.1.1 Script MIB ............................................... 4
3.1.2 Expression MIB ........................................... 5
3.1.3 Event MIB ................................................ 5
4 Features ..................................................... 6
5 Structure of the MIB Module .................................. 8
5.1 checkCapabilities .......................................... 9
5.2 checkControl ............................................... 9
5.3 checkResultTable ........................................... 9
5.4 checkRuleTable ............................................. 10
5.5 checkFailureTable .......................................... 11
5.6 checkNotifications ......................................... 11
6 MIB Usage .................................................... 11
6.1 Usage Example .............................................. 12
7 Definitions .................................................. 13
8 Security Considerations ...................................... 33
9 Normative References ......................................... 34
10 Informative References ...................................... 35
11 Authors' Addresses .......................................... 35
12 IPR Notices ................................................. 36
13 Full Copyright Statement .................................... 36
Nunzi, Quittek, Brunner, Dietz [Page 2]
Internet-Draft December 2003
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that allow to
define a health check procedure on a managed device. The result of
the health check is accumulated into a single managed object that can
be read by a manager instead of reading all managed objects to be
checked during the health check procedure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Overview
Typically, checking healthiness of a managed node from a network
management station requires reading a lot of individual managed
objects at the node. The management applications checks if the
values of these objects are within certain ranges; indicating safe
states, or have reached values indicating failure or error states.
Polling the values from the managed device to compare them with the
ranges' boundaries causes load on the management station in the
network and on the managed node. This limits the scalability of
monitoring applications in terms of managed nodes and of managed
objects to be checked per node.
Configuring event notifications avoids the read operations; but can
lead to flooding of notifications when a single failure triggers
several events at the same time. In both approaches; the manager
applications can experiment difficulties in monitoring a high number
of managed objects per device in large networks.
Nunzi, Quittek, Brunner, Dietz [Page 3]
Internet-Draft December 2003
The basic idea of the CHECK MIB is to perform the comparison
operations at the device and to aggregate the result into a single
object. The manager can poll the single result object or,
eventually, configure the device to send a notification if the result
identifies a failure condition. This approach improves the
scalability of monitoring applications; because the interactions with
the controlled stations are reduced by a factor equal to number of
objects aggregated by the result.
The CHECK MIB aims to keep a high level of simplicity in the
configuration of the checks as well as in the implementation of the
module, while featuring, at the same time, capabilities which should
fit for the most monitoring applications.
3.1. Related MIB Modules
Existing MIBs define similar features to distribute monitoring
operations to managed nodes; as outlined briefly in the following
paragraphs. In general it can be stated that they focus on wider
ranges of applications and offer richer capabilities than the CHECK
MIB; but they don't achieve the same level of scalability, simplicity
and efficiency.
3.1.1. Script MIB
The Script MIB [RFC3165] allows a NMS to download arbitrary programs
(scripts) to the managed node and read intermediate or final results
from program execution. If supported by the Script MIB
implementation, programs can access local managed objects of other
MIB modules and perform even complex operations on them. Among these
operations the checks described above are included.
However, the Script MIB also creates a lot of overhead. It requires
to code all comparisons into programs, to download them to the
managed node and to control their execution. Changes in the check
operations, for example, the modification of one of several
thresholds requires to identify the corresponding line of the
program, modify it, re-compile it (required in some cases), download
the modified program to the managed node (required in some cases),
stop the execution of the original program and start the modified
one.
Another matter of complexity is the implementation of the Script MIB.
It is very powerful concerning the handling of programs, passing
arguments to them, receiving intermediate results and controlling
their execution. In addition, a runtime engine for the programs to
be executed must be provided. This is achieved by a rather complex
and costly implementation.
The rich capabilities of the Script MIB imply several security
Nunzi, Quittek, Brunner, Dietz [Page 4]
Internet-Draft December 2003
issues. Since the programs to be executed can potentially execute
arbitrary code, strict access control to the Script MIB is required.
Summarizing the consideration of the Script MIB, it is more than
powerful enough for increasing scalability of monitoring applications
as described above. It offers a much richer and more general
functionality. However, the prices for this is a costly
implementation, rather complex handling of the MIB required by an NMS
and a set of security issues to be considered.
3.1.2. Expression MIB
The Expression MIB [RFC2982] allows to compute in the managed station
simple expressions based on the values of the managed objects; the
goal is to offer to the manager directly an elaboration of those
values (for example the percentage line utilization per second
elaborated with a mathematical expression from four objects of
mib-2). Moreover the Expression MIB introduce two new features: the
"wildcard" to include the computation of all instances of an object
in a table within a single expression and the type of sampling to
consider different samples of object value.
The drawbacks of this flexibility are the complexity in defining the
expressions (each value in the expression is treated as a variable
and must be correctly defined in a table for variables) and the
difficulty in implementing it (the manager must implement a parser
for the expression, a checker for the consistency of the expression
with variables); moreover the expression can be incorrectly defined
and so the manager must check for errors before reading results,
avoiding automated control; finally the wildcard creates a value for
each instance of the object referred, without aggregating each
partial result.
Most of the monitoring operations performed by manager applications
resolve to simple comparison between values and don't require the
computational capabilities offered by the Expression MIB. However,
those applications which need such capabilities can use the value
objects of the Expression MIB as source for the comparison operations
defined in the CHECK MIB.
3.1.3. Event MIB
The Event MIB [RFC2981] allows an agent to monitor managed objects at
a device and to report failures when certain conditions on their
values are met. The manager can configure three types of condition
to monitor the objects. If a condition is met, two different actions
can be taken: either set a value of a object (to report failures to
other MIBs) or send a notification.
Each type of condition must be defined in a different table and is
Nunzi, Quittek, Brunner, Dietz [Page 5]
Internet-Draft December 2003
associated with a different notification. The Event MIB can control
objects on the local managed station or on remote managed stations
through the integration with the SNMPv3 Management Target and
Notification MIBs [RFC2573].
The Event MIB contains also two features already defined in the
Expression MIB: the wildcard to reference all the instances of an
object and the different types of sampling of the object's value.
There's a certain overlap in the definition of the monitor operations
in the Event MIB (trough the "trigger" objects) and in the CHECK MIB.
This overlap is needed to achieve the simplicity and scalability
goals aimed by the CHECK MIB. The configuration of the triggers of
the Event MIB is not simple due the need of accessing two different
tables for each trigger; the implementation as well is complicated by
the coexistence of three different types of triggers and the
correspondent tables in the MIB tree. Scalability is not addressed,
because each trigger monitors a managed object and cannot be
aggregated with others.
4. Features
The basic feature of the CHECK MIB is to perform a check procedure
through a set of simple comparison operations between values of the
monitored objects and control values. The manager station initially
configures the check procedure on the device and later it polls a
value representing the result of the check. Alternatively; the
manager can configure the device to send a notification when the
result identifies an error condition.
In the CHECK MIB the comparison operation is called "rule". A rule
defines a monitored object, a reference value and the relationship
expected between the value of the monitored object and the reference
value; a rule fails if the relationship is not respected. Rules are
defined as entries in the checkRuleTable.
A check is constituted by a set of rules and is defined in an object
called "result". When a check defined in a result is performed; each
rule included by that result is performed in sequence. At the end of
the performance, the result object contains the result of the check;
as explained afterwards. Results are defined as entries in the
checkResultTable and the rules included by a result are referenced
using the name of the result as first index in the checkRuleTable.
Several results can be defined on a device, where each of them
performs a different check. For example, one result can monitor
general conditions of the device (like the internal temperature) and
another one can monitor the operational status of a specific element
(for example the link status of the interfaces installed). The
Nunzi, Quittek, Brunner, Dietz [Page 6]
Internet-Draft December 2003
figure below gives a snapshot of a general configuration and
clarifies the aggregation of operations inducted by the CHECK MIB.
rule1: obj1<30 --|
rule2: obj2=2 |-- aggregated by --> result: checkGeneral
rule3: obj9>=60 --|
ruleA: obj1<30 --|
. . . |-- aggregated by --> result: checkSpecific
ruleZ: obj9>=60 --|
When a check is performed and some rules included fail; then a
"failure" object is created for each rule which failed; each failure
object contains the OID of the monitored object defined in the rule;
as depicted below:
performance of checkGeneral --> rule1: failed? Yes --> failure: obj1
--> rule2: failed? Yes --> failure: obj2
--> rule3: failed? Yes --> failure: obj9
When the manager polling the result discovers a failure in the check,
it can read the objects which didn't pass the last check.
A rule defines also the integer value "severity" which measures the
gravity of the rule for the result which includes it. If some rules
fail, then the result is updated with the maximum of the severities
of the failed rules. The purpose of the severity is to indicate the
severity of the failures occurred in a check to the network manager.
The scale of the severity is arbitrary chosen by the manager.
Nevertheless this document implicitly uses for the examples a scale
between 0 and 100, because it gives enough space to include enough
levels of gravity of the checks of the managed stations.
The CHECK MIB defines a notification object to report a failed check.
The notification contains the severity of the result. The trigger of
a notification is a threshold value for the severity of the result
and thus a notification is sent only if the severity reaches or
overcomes the threshold value. The management station can enable the
threshold only for highly severe failures, so that a notification
will not be sent for minor failures. It's worth to notice that even
if the managed objects controlled in a check carry correlated
information and all the rules in a result happen to fail for the same
failure in the monitored device, only one notification will be sent
(no "events storming" is triggered).
A check can be performed automatically, that is on regular intervals,
or manually, that is each time the severity of a result is retrieved
by the manager.
The CHECK MIB can be used to monitor all the object types defined in
Nunzi, Quittek, Brunner, Dietz [Page 7]
Internet-Draft December 2003
SMIv2 with the exception of the Opaque type. Integer values can be
compared to control values (with relationships like <,<=,=,!=,>,>=).
For counters it's possible to specify also a delta operation to
monitor the increments at each check. IpAddress, OID, BITS and OCTET
STRING values can be monitored only testing if they match the control
value. The control value for all the object types is encoded into an
OCTET STRING object, following the definitions given in the textual
convention RuleValue.
The objects to be monitored are identified by their OIDs. In the
simple case a rule monitors a single instance object. Beside, it's
possible to monitor with a single rule all the instances of a
columnar object (that is an object defined inside a row of a table);
in this case the OID of the columnar object itself must be indicated
and the rule is applied to all the instances of the columnar object
existing in the table. The instances are retrieved as the objects
next in lexicographical order to the OID specified in the rule. A
misconfigured OID (that is an OID which doesn't refer neither to an
instance object nor a columnar object) may lead to retrieve wrong
objects in the MIB tree and thus to compute wrong results in the
performance of a check.
Each result is identified by its name which is used as index in the
checkResultTable. The name of the result should give a brief
description of the purpose of the result to help readability of the
table. Some recommendations are given in the definition of the CHECK
MIB for the result's name; aiming at a common semantic between
different management stations. Following these suggestions, an
example for a result's name is "zeusInterfaces", which identifies a
check configured by a management application called "zeus" to monitor
the the interfaces of the device.
A useful application of the CHECK MIB is the support for checks pre-
configured in the device by the manufacturer. In this case the
manager application might use the pre-configured checks, bypassing
the configuration of all the rules.
5. Structure of the MIB Module
This section presents the structure of the MIB module that is
specified in Section 7.
The module contains five groups of managed objects:
- the capabilities group
containing managed objects that indicate capabilities of the
CHECK MIB implementation;
- the control group
containing managed objects that control the working status of
the CHECK MIB;
Nunzi, Quittek, Brunner, Dietz [Page 8]
Internet-Draft December 2003
- the result group
containing the checkResultTable that provides results of check
operations;
- the rule group
containing the checkRuleTable that specifies check operations;
- the failed checks group
containing the checkFailureTable that indicated managed objects
for which a check failed.
Additionally, a notification is specified that can be used for
notifying a NMS about failed checks.
5.1. checkCapabilities
Information on middle-box capabilities is provided by the
capabilities group of managed objects. The following objects are
defined:
o checkCapabMinCheckInterval
This object indicates the minimum time between two performances
of the same check that can be scheduled.
o checkCapabMaxResults
This object indicates the maximum number of entries in the
checkResultTable.
o checkCapabMaxRules
This object indicates the maximum number of entries in the
checkRuleTable.
5.2. checkControl
The working status of the CHECK MIB can be controlled through two
objects:
o checkCtrlAdminStatus
This object indicates the desiderated status of the CHECK MIB.
o checkCtrlOperStatus
This object indicates the actual status of the CHECK MIB.
5.3. checkResultTable
This tables contains the results of the checks performed by the agent
as well as some parameters to control how the checks are actually
performed. The following objects are defined:
o checkResultName
This object indicates the name of the result. The name is used
as index for the table and should give indicate the name of the
Nunzi, Quittek, Brunner, Dietz [Page 9]
Internet-Draft December 2003
manager configuring the check and a label identifying the check
procedure.
o checkResultSeverity
This object indicates the result of the checks performed from
the device. A value of 0 indicates that no failure have been
detected while performing the check. A value greater than 0
indicates the maximum of the severities of the rules failed at
the last performance.
o checkResultSize
This object indicates the number of failed rules at the last
performance.
o checkResultTime
This object indicates the time of the last performance.
o checkResultInterval
If this object is set to 0, then the check is performed each
time a manager retrieves the value of checkResultSeverity. A
value greater than 0 specifies the interval between two checks
automatically performed by the device.
o checkResultSeverityThreshold
This objects indicates if a notification should be sent if a
check fails. A value of 0 means that no notification will be
sent. A value different from 0 indicates that a notification
should be sent if a check fails with severity greater or equal
to that value.
o checkResultRowStatus
This objects permits the creation and deletion of rows.
5.4. checkRuleTable
This table defines the comparison operations to be executed for the
checks specified in the checkResultTable. The following objects are
defined:
o checkRuleName
This object indicates the name of the rule and is used as index
for the table coupled with the checkResultName of the check
which includes the rule.
o checkRuleOid
This object indicates the OID of the object to be monitored.
o checkRuleValue
This object indicates the value the object must be compared to.
Nunzi, Quittek, Brunner, Dietz [Page 10]
Internet-Draft December 2003
o checkRuleOperation
This object indicates the relationship expected between the
value of the monitored object and checkRuleValue.
o checkRuleSeverity
This object indicates the severity for the rule defined by this
entry.
o checkRuleRowStatus
This object permits the creation and deletion of rows.
5.5. checkFailureTable
This table contains the failures registered while performing the
checks. For each rule failed, an entry in this table. Each entry is
indexed by the checkResultName and the checkRuleName of the rule
failed and the checkFailureSeverity object. Two objects are defined
in the table:
o checkFailureSeverity
This objects is indicates the severity with which the rule
failed.
o checkFailureOid
This objects is indicates the OID of the object for which the
rule failed.
5.6. checkNotifications
The notification object checkResultFailed can be sent by the device
when a check fails. The notification contains only the
checkResultSeverity object.
6. MIB Usage
This section explains how to configure check procedures and to
implement monitor application with the CHECK MIB.
When defining a new check, the manager should follow these steps:
1. Create a new row in checkResultTable through the object
checkResultRowStatus, using the name of the check as index.
2. Set the values of checkResultSeverityThreshold and
checkResultInterval.
3. Create a new row in checkRuleTable through the object
checkRuleRowStatus giving the name of check and the name of the
rule as indexes.
4. Configure the operation defined in the rule and its severity.
5. Activate the row of the rule by writing to checkRuleRowStatus.
6. Repeat step 3-5 for each rule to be included in the check.
Nunzi, Quittek, Brunner, Dietz [Page 11]
Internet-Draft December 2003
7. Activate the row of the result by writing to
checkResultRowStatus.
A change in the RowStatus of a result is propagated also to the
RowStatus of all the rules included by that result. As consequences,
deleting a row in the checkResultTable causes the deletion of all
rows in the checkRuleTable and checkFailureTable with the same
checkResultName (they are respectively the rules and the failures
included by the check being deleted) and activating a results causes
the activation of all the rules included. The values of the objects
with read-create permissions can be modified only when the row they
belong to is put in the status notInService.
If the device is put under maintenance (for example monitored objects
are being reset); it's possible to disable temporally the performance
of the checks, changing the value of the checkCtrlAdminStatus object.
6.1. Usage Example
This section presents an example that explains how a manager can use
the CHECK MIB defined in this memo. The purpose of this example is
to explain the steps that can be performed by a network management
station (NMS) to configure check procedures and to retrieve their
results.
When monitoring the correct behavior of the interfaces installed on a
device; the main task is to make sure that all the interfaces
installed have their operational status as UP; besides, the number of
corrupted packets can be a first indicator of some malfunctions in
the device.
Instead of polling continuously the managed objects from the router,
the NMS can configure the CHECK MIB to follow these rules:
1. Control all the instances of ifOperStatus: if one interface is
down, sends a notification.
2. Control all the instances of ifInError and ifOutError: if too
corrupted packets traverse an interface, then raise the
severity of the check result. For example 30 corrupted packets
every 10 seconds should be marked as severity 40; 50 corrupted
packets every 10 seconds as severity 70.
If the check is configured to be performed every 10 seconds, then a
new row in the checkResultTable must be created with the following
set commands:
checkResultRowStatus."mgrInterfaces" = create-and-wait(5)
checkResultInterval."mgrInterfaces" = 10000
checkResultSeverityThreshold."mgrInterfaces" = 100
Then the rules must be defined for that check. For example the rule
Nunzi, Quittek, Brunner, Dietz [Page 12]
Internet-Draft December 2003
for the ifOperStatus is configured with the following set commands:
checkRuleRowStatus."mgrInterfaces"."status" = create-and-wait(5)
checkRuleOid."mgrInterfaces"."status" = ifOperStatus
checkRuleSeverity."mgrInterfaces"."status" = 100
checkRuleValue."mgrInterfaces"."status" = 1
checkRuleOperation."mgrInterfaces"."status" = less(3)
checkRuleRowStatus."mgrInterfaces"."status" = active(1)
Commands for the ifInErrors and ifOutErrors are similar. As the last
step, the check must be activated with the following command:
checkResultRowStatus."mgrInterfaces" = active(1)
The checkResultTable will look like:
-----------------------------------------------------
|Name |Severity|Time|Interval|SeverityThreshold|
-----------------------------------------------------
|mgr_router| 100|0:00| 1000| 100|
-----------------------------------------------------
The checkRuleTable will look like:
---------------------------------------------------
|Name | Oid|Value|Operation|Severity|
---------------------------------------------------
|status |ifOperStatus| 1| less| 100|
|inErrors30 |ifInErrors | 30| delta| 40|
|outErrors30|ifOutErrors | 30| delta| 40|
|inErrors50 |ifInErrors | 50| delta| 70|
|outErrors50|ifOutErrors | 50| delta| 70|
---------------------------------------------------
At this point if an interface switches its operational status to
DOWN, only one notification will be sent containing the severity 100.
On the other hand, if the NMS reports bad performance of end-services
in the network (for example high level of packet-loss), than it can
poll the severity of the result: a value of 40 or 70 might indicate
the right cause of the bad performance reported.
7. Definitions
CHECK-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
NOTIFICATION-TYPE, mib-2,
Unsigned32, TimeTicks, zeroDotZero
Nunzi, Quittek, Brunner, Dietz [Page 13]
Internet-Draft December 2003
FROM SNMPv2-SMI -- RFC2578
StorageType, RowStatus,
TimeInterval, TimeStamp,
TEXTUAL-CONVENTION
FROM SNMPv2-TC -- RFC2579
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- RFC2580
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB; -- RFC3411
checkMIB MODULE-IDENTITY
LAST-UPDATED "200312191313Z" -- December 19, 2003
ORGANIZATION "IETF Distributed Management man Working Group"
CONTACT-INFO
"Editor:
Giorgio Nunzi
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69221 Heidelberg
Germany
Tel: +49 6221 90511-39
Email: nunzi@netlab.nec.de"
DESCRIPTION
"This MIB module defines a set of objects that allow
to define a health check procedure on a managed node.
The health check procedure is performed through a sequence
of simple comparison operations on some managed objects
against a control value. The result of the health check
is accumulated into a single managed object that can be
read by a manager to discover the status of the whole
set of managed objects instead of retrieving all the single
values controlled during the health check procedure.
The main purpose of the CHECK-MIB is increasing scalability
of network management applications by moving check
operations from the management station to managed nodes.
There are five groups of managed objects defined
by this MIB module:
- objects describing capabilities
of the CHECK-MIB implementation;
- objects controlling the operational
status of the health check procedure;
- objects defining the checks in
the checkResultTable;
- objects defining the operations for each of
Nunzi, Quittek, Brunner, Dietz [Page 14]
Internet-Draft December 2003
the configured checks in the checkRuleTable;
- objects providing information about
failed checks."
REVISION "200312191313Z" -- December 19, 2003
DESCRIPTION "Initial version"
::= { mib-2 7777 }
-- 7777 to be assigned by IANA.
RuleValue ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x"
STATUS current
DESCRIPTION
"The control value compared with the value of a monitored
object. This value encodes all the object types
defined by the SMIv2, except the Opaque, with the
following rules:
- INTEGER, Integer32, Unsigned32, TimeTicks, Counter32,
Gauge32: the integer value is encoded with 4 octets in
network-byte order;
- Counter64: the integer value is encoded with 8 octets
in network-byte order;
- IpAddress: the address value is encoded with a 4 in
network-byte order;
- OBJECT IDENTIFIER: each sub-identifier is encoded with
4 octets in network-order and the whole OID is encoded
as a sequence of sub-identifiers starting from the
top-level;
- BITS: all the named bits in the bitstring, commencing
with the first bit and proceeding to the last bit, are
placed in bits 8 (high order bit) to 1 (low order bit)
of the first octet, followed by bits 8 to 1 of each
subsequent octet in turn, followed by as many bits as
are needed of the final subsequent octet, commencing
with bit 8. Remaining bits, if any, of the final octet
are set to zero on generation and ignored while
performing a check;
- OCTET STRING: the string is encoded as it is."
SYNTAX OCTET STRING
SeverityConfigured ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The severity value measures the gravity of a failure of a
rule or a result. A low value indicates a minor failure,
while a high value indicates a sever failure. The scale of
the severity is arbitrary chosen by the manager
application.
This textual convention represents the value of a severity
which is configured by the manager."
SYNTAX Unsigned32 (0..4294967293)
Nunzi, Quittek, Brunner, Dietz [Page 15]
Internet-Draft December 2003
SeverityReturned ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The severity value measures the gravity of a failure of a
rule or a result. A low value indicates a minor failure,
while a high value indicates a sever failure. The scale of
the severity is arbitrary chosen by the manager
application.
This textual convention represents the value of a severity
which is set by the device after the performance of a rule.
If the rule has been correctly performed, the value is
equal to the severity configured for the rule. If the rule
has not been performed because the monitored object
couldn't be accessed, then this values is set to
4294967295. If the rule has not been performed due to a
lack of resources, then this value is set to 4294967294."
SYNTAX Unsigned32
--
-- main components of this MIB module
--
checkObjects OBJECT IDENTIFIER ::= { checkMIB 1 }
checkNotifications OBJECT IDENTIFIER ::= { checkMIB 2 }
checkConformance OBJECT IDENTIFIER ::= { checkMIB 3 }
--
-- Capabilities group
--
-- The capabilities group contains a set of managed
-- objects describing the capabilities of the CHECK-MIB
-- implementation.
--
checkCapabilities OBJECT IDENTIFIER ::= { checkObjects 1 }
checkCapabMinCheckInterval OBJECT-TYPE
SYNTAX TimeTicks
UNITS "centi-seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum interval that can be scheduled between two
performances of the same check defined in the
checkResultTable using the object checkResultInterval.
This value is the minimum value allowed for the object
checkResultInterval of the checkResultTable."
::= { checkCapabilities 1 }
Nunzi, Quittek, Brunner, Dietz [Page 16]
Internet-Draft December 2003
checkCapabMaxResults OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of entries supported in the
checkResultTable. A value of 0 indicates that
there is no fixed limitation.
Creating a new row in the checkResultTable with the
object checkResultRowStatus after the maximum number
of entries supported, leads to a resourceUnavailable
error."
::= { checkCapabilities 2 }
checkCapabMaxRules OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of entries supported in the
checkRuleTable. A value of 0 indicates that there
is no fixed limitation.
Creating a new row in the checkRuleTable with the
object checkRuleRowStatus after the maximum number
of entries supported, leads to a resourceUnavailable
error."
::= { checkCapabilities 3 }
--
-- Control group
--
-- The control group contains managed objects controlling
-- the operational status of the check MIB implementation.
--
checkControl OBJECT IDENTIFIER ::= { checkObjects 2 }
checkCtrlAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- performing checks
silent(2), -- no notifications sent
down(3) -- all checks disabled
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desidered state of the checking engine of the
Check MIB implementation. Setting this object to up(1)
Nunzi, Quittek, Brunner, Dietz [Page 17]
Internet-Draft December 2003
indicates a request for performing all checks as defined
in the checkResultTable and the checkRuleTable performed.
Setting this object to silent(2) indicates that all the
checks defined in checkResultTable must be performed, but
no notification must be sent by the Check MIB
implementation. Setting this object to down(3) indicates
a request for performing o more tests.
When retrieved, the object returns the last value written
to it, except after system boot when it returns the value
up(1)."
DEFVAL { up }
::= { checkControl 1 }
checkCtrlOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- performing checks
silent(2), -- no notifications sent
down(3), -- all checks disabled
flushing(4) -- finishing checks already started
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of the Check MIB
implementation. The up(1) state indicates that all checks
defined in the checkResultTable and the checkRuleTable are
performed. The silent(2) state indicates that all checks
are performed as defined in the checkResultTable and the
checkRuleTable, but no notification is sent by the Check
MIB implementation. The down(3) state indicates that no
check is performed. The flushing(4) state indicates that
the checkCtrlAdminStatus has been set to down(3) and the
managed node is completing the performance of checks that
were scheduled before checkCtrlAdminStatus was set to
down(3). If the value of checkCtrlAdminStatus does not
change again before these checks are completed, then the
value of checkCtrlOperStatus will change to down(3) after
the checks are completed.
After a system re-initialization, the Check MIB
implementation starts up with this object set to up(1)."
::= { checkControl 2 }
--
-- Result group
--
-- The Result group contains the objects to define the checks
-- performed on the managed node. The checks are organized
-- in the checkResultTable.
Nunzi, Quittek, Brunner, Dietz [Page 18]
Internet-Draft December 2003
--
checkResultTable OBJECT-TYPE
SYNTAX SEQUENCE OF CheckResultEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the definitions of the checks
to be performed by the Check MIB implementation.
Each row defines one check and contains the
parameters controlling the performance of the check
as well as the result of the check.
The operations performed by each check are defined as
rules in the checkRuleTable."
::= { checkObjects 3 }
checkResultEntry OBJECT-TYPE
SYNTAX CheckResultEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry defining a check. Each entry is indexed by
the string checkResultName, which represents the name
of the check. An entry can be created with the object
checkResultRowStatus only with the createAndWait operation.
A check is never performed if its entry is in the
notInService status. Objects in an entry marked as
read-create can be modified only when the entry is in
notInService status."
INDEX { checkResultName }
::= { checkResultTable 1 }
CheckResultEntry ::= SEQUENCE {
checkResultName SnmpAdminString,
checkResultSeverity SeverityReturned,
checkResultSize Unsigned32,
checkResultTime TimeStamp,
checkResultInterval TimeInterval,
checkResultSeverityThreshold SeverityConfigured,
checkResultStorageType StorageType,
checkResultRowStatus RowStatus
}
checkResultName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Nunzi, Quittek, Brunner, Dietz [Page 19]
Internet-Draft December 2003
"A name describing the check. Since the name serves as
table index, it must be unique for each row in the table.
The name of a check is chosen arbitrary by the manager
creating the row in the checkResultTable, but some
suggestions are given to offer a common semantic
among different managers.
The name should give a brief description of the check
defined in the row. In particular it is recommended
that the name indicates:
- the name of the manager who defined the row.
- a label describing the check."
::= { checkResultEntry 1 }
checkResultSeverity OBJECT-TYPE
SYNTAX SeverityReturned
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Each time the check defined by this entry (and the
corresponding entries of the checkRuleTable) is performed,
this object is set to to the maximum value of all
checkRuleSeverity objects in corresponding entries of the
checkRuleTable for which the check failed. If the check
passes for all corresponding rules, then the value of
object checkResultSeverity is 0.
If the object checkResultInterval contains the value 0,
then the check is performed when the value of
checkResultSeverity is retrieved by a manager. If the
object checkResultInterval contains a value greater than 0,
then the check is performed automatically by the managed
node and a read access by a manager just returns the value
computed at the last scheduled check.
Each time object checkResultSeverity is set, the value of
object checkResultTime in the corresponding entry is
set to the current time, and the value of object
checkResultSize is set to the number of corresponding
entries in the checkRuleTable for which the check failed.
If no check has been performed so far, then the value
of this object is 0."
::= { checkResultEntry 2 }
checkResultSize OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Nunzi, Quittek, Brunner, Dietz [Page 20]
Internet-Draft December 2003
"The number of rules defined in corresponding entries of the
checkFailureTable for which the check failed when it was
performed last.
If no check has been performed so far, then the value
of this object is 0."
::= { checkResultEntry 3 }
checkResultTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A timestamp indicating the time when the last performance
of the check defined in this row was completed.
If no check has been performed so far, then the value of
this object is 0. Note that 0 is a valid timestamp."
::= { checkResultEntry 4 }
checkResultInterval OBJECT-TYPE
SYNTAX TimeInterval
UNITS "centi-seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The interval between two performances of the check
defined in this row.
When this object is set to a value greater than 0,
then the check is performed regularly with the number
of centi-seconds indicated by this object between two
performances. When this object is successfully set
to a value greater than 0, then the check is not
performed immediately. The first check is performed
after the number of centi-seconds specified by the
new value of the object. If a performance is scheduled
to start before the previous one has been completed,
then the previous check will be completed and the
scheduled check will be skipped.
If the number of this object is 0, then the check is
performed only on request when the value of the object
checkResultSeverity is retrieved by a manager.
A set operation on this object may lead to an
inconsistentValue error in two cases:
- if the vale passed is greater than 0 but less
than the value of checkCapabMinCheckInterval;
- if the value passed is greater than 0 and the
Nunzi, Quittek, Brunner, Dietz [Page 21]
Internet-Draft December 2003
check defined in this row includes rules with
delta operations."
DEFVAL { 0 }
::= { checkResultEntry 5 }
checkResultSeverityThreshold OBJECT-TYPE
SYNTAX SeverityConfigured
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object serves for sending notifications in
case of failures occurred in the check defined
in this row.
If the value of this object is set to 0, then no
notification is sent to the manager even if some
rule defined for the check fails.
Otherwise, if the performance of a check leads to
a value of the object checkResultSeverity that is
equal to or greater than the value of the object
checkResultSeverityThreshold, then a notification
is sent. The notification is an instance of
checkResultFailed."
DEFVAL { 0 }
::= { checkResultEntry 6 }
checkResultStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object indicates the storage type
of this entry in the checkResultTable and of all
corresponding entries in the checkRuleTable. The value
of this object indicates whether the entries are stored
in volatile memory and lost upon reboot or if they
are backed up by non-volatile or permanent storage.
If checkResultStorageType has the value permanent(4),
then all objects whose MAX-ACCESS value is read-write
can be modified, but the row cannot be deleted. All the
objects in corresponding entries of the checkRuleTable
whose MAX-ACCESS is read-create are instead read-only with
the exception of the checkRuleRowStatus.
Attempts to set this object to permanent(4) will always
fail with an inconsistentValue error."
DEFVAL { volatile }
::= { checkResultEntry 7 }
checkResultRowStatus OBJECT-TYPE
Nunzi, Quittek, Brunner, Dietz [Page 22]
Internet-Draft December 2003
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object allows to create and delete rows in the
table. The value createAndGo(4) is not allowed and an
wrongValue error is returned when attempting to set it.
Objects of the same row can be modified only when
checkResultRowStatus has the notInService(2) value and
set operations on objects of a row in active(1) status
result to inconsistentValue. A change of the value of the
checkResultRowStatus object is propagated to the
checkRuleRowStatus of all the related entries in the
checkRuleTable (those indexed by the same checkResultName);
if the change of the value of a checkRuleRowStatus object
results in an inconsistentValue error, then this error is
returned to the manager while setting the value of this
checkResultRowStatus.
An attempt to set the value of this object to active(1),
causes the following actions:
- all the related entries in the checkRuleTable become
active; if an attempt to activate an entry results in
an inconsistentValue error, then this error is returned
to the manager and further action is taken;
- all the objects of this row become read-only, with the
exception of checkResultRowStatus;
- if the value of checkResultInterval is greater than 0,
then the timer to schedule the performances of the
check starts immediately, but the first check will be
performed only but after the time specified by
checkResultInterval; for rules defining delta operations
the values of managed objects to be checked are read
immediately, so that delta operations can be computed at
the first scheduled check.
- if the value of checkResultInterval is equal to 0, then
retrieving the value of checkResultSeverity forces the
performance of the check.
When a row is put in the notInService status, then the
following actions are taken:
- all the objects of the row marked as read-create can be
modified;
- all the related entries in the checkRuleTable become
notInService;
- all scheduled future checks are canceled.
- retrieving the value of checkResultSeverity returns
always the value computed at the last check.
When a row is deleted, then if an alarm was configured, it
is removed, and all the related entries in checkRuleTable
Nunzi, Quittek, Brunner, Dietz [Page 23]
Internet-Draft December 2003
are deleted (eventually freeing the resources allocated
for delta operations defined by those rules).
Creating a new row when the table reached the maximum
number of entries defined in checkCapabMaxResults
results in a resourceUnavailable error."
::= { checkResultEntry 8 }
--
-- Check Rule group
--
-- The Rule group contains the objects to define the operations
-- performed for each check. The operations are organized
-- in the checkRuleTable.
--
checkRuleTable OBJECT-TYPE
SYNTAX SEQUENCE OF CheckRuleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the definitions of the operations
performed for checks defined in the checkResultTable.
Each row defines an operation on the value of a managed
object. The operation consists in a comparison of the
value of the managed object with a control value specified
in checkRuleValue. The relationship expected between the
two values is indicated by checkRuleOperation.
It is possible to reference in a single rule either a
single instances object or all the instance of a columnar
object of a table.
For each operation, a severity is set which indicates
the gravity of the failure of the comparison operation.
The storage type of entries in this table is determined
by the value of object checkResultStorageType in the
corresponding entry of the checkResultTable."
::= { checkObjects 4 }
checkRuleEntry OBJECT-TYPE
SYNTAX CheckRuleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry defining a rule for a check defined
in the checkResultTable. Each entry is indexed by:
1. the checkResultName of the check which includes
the operation defined by the entry;
2. the string checkRuleName, which represents the
Nunzi, Quittek, Brunner, Dietz [Page 24]
Internet-Draft December 2003
name of the operation.
An entry can be created with the object
checkResultRowStatus only with the createAndWait operation.
A rule is never considered in the performance of the
check defined in the related checkResultEntry, if its
entry is in the notInService status. Objects in an entry
can be modified only when the entry is in
notInService status."
INDEX { checkResultName, checkRuleName }
::= { checkRuleTable 1 }
CheckRuleEntry ::= SEQUENCE {
checkRuleName SnmpAdminString,
checkRuleOid OBJECT IDENTIFIER,
checkRuleValue RuleValue,
checkRuleOperation INTEGER,
checkRuleSeverity SeverityConfigured,
checkRuleRowStatus RowStatus
}
checkRuleName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A name describing the rule. Since the name serves as
table index coupled with the value of checkResultName,
it must be unique per each row in the table
inside the scope of checkResultName.
The name of a rule is chosen by the manager creating
the row, but some suggestions are given to offer a
common semantic between different managers.
The name should give a brief description of the rule
defined in the row. In particular it is recommended
that the name indicates the name of the managed object
controlled by the rule."
::= { checkRuleEntry 2 }
checkRuleOid OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The OID indicating the managed object to be checked.
The OID must be:
- the OID of an instance object: in this case the
rule is applied to that object;
- the OID of a columnar object (missing of the instance
sub-identifier): in this case the rule is applied to all
Nunzi, Quittek, Brunner, Dietz [Page 25]
Internet-Draft December 2003
the instances of the columnar object.
The validity of the OID is verified when the manager tries
to activate the row, following these actions:
- the agent should try to read the value of the object
referenced by the OID (like a snmp get operation); if the
value is read, the OID refers to a valid instance object
and the type of the object should be registered inside
the agent;
- if the object is not available, then the agent should try
to read the next object in the lexicographical order (like
a snmp get next operation); if the OID returned is a child
node of the checkRuleOid, then the latter is assumed to be
a columnar object and the type of the object read is
stored inside the agent;
- if no object could be found or the OID returned is not a
leaf of checkRuleOid, then an inconsistentValue error is
return to the attempt of activating the row.
When setting the OID of a columnar object, at least one
instance object must exist at the moment of the activation
of the row, so that the validity test of OID passes and the
row is activated.
If the OID references an instance object that is removed or
become inaccessible after the row has been activated, then
rule automatically fails with a severity equal to
4294967295. If the OID value references a columnar object
and no instance exists after the first performance, then
the rule doesn't fail."
DEFVAL { zeroDotZero }
::= { checkRuleEntry 3 }
checkRuleValue OBJECT-TYPE
SYNTAX RuleValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The control value compared to the value of the managed
object indicated by checkRuleOid.
The control value encoded in this object must be consistent
with the type of the object referenced by the checkRuleOid.
The control value is considered inconsistent if:
- the object type is INTEGER, Unsigned32, TimeTicks,
Gauge32, Counter32, IpAddress and the size of the
checkRuleValue is different from 4;
- the object type is Counter64 and the size of the
checkRuleValue is different from 8;
- the object type is OBJECT IDENTIFIER and the size of the
checkRuleValue is not a multiple of 4.
Nunzi, Quittek, Brunner, Dietz [Page 26]
Internet-Draft December 2003
The consistency between the control value and the object
type is verified when the rule is activated; if the
consistency test fails, the attempt to active the row
results in an inconsistentValue error."
DEFVAL { "" }
::= { checkRuleEntry 4 }
checkRuleOperation OBJECT-TYPE
SYNTAX INTEGER {
noOperation(0),
unequal(1), equal(2),
less(3), lessOrEqual(4),
greater(5), greaterOrEqual(6),
delta(7)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of this object specifies the comparison
operation to be performed between the value of the
managed object indicated by checkRuleOid and the
value indicated by checkRuleValue. Some operations
cannot be applied to all the types of object. If
the value of the checkRuleOperation is inconsistent
with the type of the object indicated by checkRuleOid,
then an attempt to activate the row results in an
inconsistentValue error.
The value 0 can be configured for all the object
types and means that no operation is performed and
the rule never fails.
When the type of the object indicated by checkRuleOid
is IpAddress, BITS, OBJECT IDENTIFIER then only the value
equal(2) can be configured. For the IpAddress, the value
of the object indicated by checkRuleOid is compared byte
by byte with the value of checkRuleValue and the rule
doesn't fail if all the bytes are matched. For the
OBJECT IDENTIFIER, the rule doesn't fail if checkRuleValue
encodes an OID of the same dimension of the value of the
object indicated by checkRuleOid and the two OIDs are
equal. For the BITS, the rule doesn't fail if the
checkRuleValue encodes a bitstring long at least as the
number of the named bits and all the named bits are
matched with that bitstring.
When the type of the object indicated by checkRuleOid
is INTEGER, Integer32, Unsigned32, Counter32, Counter64,
TimeTicks, Gauge32, all the values from 1 to 6 can be
configured. These values define simple mathematical
Nunzi, Quittek, Brunner, Dietz [Page 27]
Internet-Draft December 2003
operations: the rule doesn't fail if the the value
of the object indicated by checkRuleOid is, respectively,
!=, =, <, <=, >, >= than the value of checkRuleValue.
A value of of delta(7) can be configured only for
Counter32, Counter64, Gauge32; moreover it is permitted
only if the check including the rule is performed
automatically and thus its value of checkResultInterval
greater than 0, otherwise an inconsistentValue error is
returned. For a delta operation, each time the rule is
performed, the difference between the actual value of the
managed object and its value at the last performance is
considered and the rule doesn't fail if the difference is
<= than the value of the checkRuleValue. If the actual
value is less than the previous one, then the difference is
augmented with the value 4294967295, like as the managed
object reached its maximum value and it has been resetted.
Each time the new value of the managed object must be
stored by the device in an internal buffer. The buffer
must be handled so that when a new managed object is
controlled, a new entry is allocated for it. If no more
entries are available, then the rule fails with severity
4294967294.
If a managed object for which an entry was previously
allocated, doesn't exist when a new execution of the delta
operation is performed, its entry should be removed.
When a new entry is allocated for a new managed object,
its value is stored in the entry, but the operation is not
computed and the rule doesn't fail; the delta operation
is normally computed only from the second time."
DEFVAL { noOperation }
::= { checkRuleEntry 5 }
checkRuleSeverity OBJECT-TYPE
SYNTAX SeverityConfigured
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The severity of a failure of the operation specified by
the row for the whole check.
A severity of 0 indicates that a failure of the
operation is irrelevant."
DEFVAL { 1 }
::= { checkRuleEntry 6 }
checkRuleRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
Nunzi, Quittek, Brunner, Dietz [Page 28]
Internet-Draft December 2003
STATUS current
DESCRIPTION
"The control to create and delete rows. It is possible
to create new rules only for a check which is already
defined in the CHECK-MIB. Creating a new row indexed
by a value of checkResultName which doesn't exist
already in any row of the checkResultTable results in a
inconsistentName error. The value createAndGo(4) is not
allowed and an wrongValue error is returned when attempting
to set it.
Objects of the same row can be modified only when
checkRuleRowStatus has the notInService(2) value and
set operations on objects of a row in active(1) status
result to inconsistentValue.
A row in the notInService status is not considered in the
performance of the check defined by the related entry in
the checkResultTable (the one indexed by the same
checkResultName).
An attempt to set the value of this object to active(1),
causes the following actions:
- the validity of the value of checkRuleOid is verified;
if it fails, then an inconsistentValue error is returned;
- the consistency between the type of the object referenced
by checkRuleOid and the value of checkRuleOperation is
verified; if it fails, then an inconsistentValue error is
returned;
- the consistency between the type of the object referenced
by checkRuleOid and the value of checkRuleValue is
verified; if it fails, then an inconsistentValue error is
returned;
- if all the tests pass, the row is activated.
An attempt to create a new row when the table has reached
the maximum number of entries defined in checkCapabMaxRules
results in a resourceUnavailable error.
An attempt to create a new row in the table with the
corresponding entry in the checkResultTable having the
storage type permanent(4) results in an inconsistentValue
error."
::= { checkRuleEntry 7 }
--
-- Failure group
--
-- The Failure group contains the object describing the failures
-- of a check. The failures are organized in the checkFailureTable.
--
Nunzi, Quittek, Brunner, Dietz [Page 29]
Internet-Draft December 2003
checkFailureTable OBJECT-TYPE
SYNTAX SEQUENCE OF CheckFailureEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists all the rules defined in the
checkRuleTable, which failed at the last
time the check including them has been performed.
Entries only describe objects for which the last check
failed. Failures in checks before the last one are not
indicated."
::= { checkObjects 5 }
checkFailureEntry OBJECT-TYPE
SYNTAX CheckFailureEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry referencing a failed rule.
Each entry is indexed by:
1. the checkResultName of the check including
the rule failed;
2. the severity of the rule failed;
3. The checkRuleName of the rule failed.
The manager, after having read a value of
checkResultSeverity of a check different from 0, can
directly read the rule failed with the maximum severity by
retrieving the checkFailureOid with a get_next command
without specifying the checkRuleName."
INDEX { checkResultName, checkFailureSeverity, checkRuleName }
::= { checkFailureTable 1 }
CheckFailureEntry ::= SEQUENCE {
checkFailureSeverity SeverityReturned,
checkFailureOid OBJECT IDENTIFIER
}
checkFailureSeverity OBJECT-TYPE
SYNTAX SeverityReturned
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The severity with which the rule failed."
::= { checkFailureEntry 1}
checkFailureOid OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
Nunzi, Quittek, Brunner, Dietz [Page 30]
Internet-Draft December 2003
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The OID of the managed object for which a rule
failed.
This value contains the value of checkRuleOid
of the rule failed."
::= { checkFailureEntry 2 }
--
-- Notifications. The definition of checkEvent makes notification
-- registrations reversible (see STD 58, RFC 2578, Section 8.5).
--
checkEvent OBJECT IDENTIFIER ::= { checkNotifications 0 }
checkFailed NOTIFICATION-TYPE
OBJECTS { checkResultSeverity }
STATUS current
DESCRIPTION
"This notification can be generated to report
that a check failed. The notification is generated each
time, the value of checkSeverityThreshold is greater than
0 and the performance of a check results in a value of
checkResultSeverity that is greater than or equal to the
value of checkSeverityThreshold.
The notification contains the checkResultSeverity of
the check failed."
::= { checkEvent 1 }
--
-- Conformance information
--
checkCompliances OBJECT IDENTIFIER ::= { checkConformance 1 }
checkGroups OBJECT IDENTIFIER ::= { checkConformance 2 }
--
-- Compliance statements
--
-- This is the CHECK-MIB compliance definition.
--
checkCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities that
implement the CHECK-MIB."
Nunzi, Quittek, Brunner, Dietz [Page 31]
Internet-Draft December 2003
MODULE -- this module
MANDATORY-GROUPS {
checkCapabilitiesGroup,
checkControlGroup,
checkResultGroup,
checkRuleGroup,
checkFailureGroup,
checkNotificationsGroup
}
::= { checkCompliances 1 }
--
-- Groups statements
--
-- This is the definition of the objects group of the CHECK-MIB.
--
checkCapabilitiesGroup OBJECT-GROUP
OBJECTS {
checkCapabMinCheckInterval,
checkCapabMaxResults,
checkCapabMaxRules
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
the capabilities of the CHECK-MIB implementation."
::= { checkGroups 1 }
checkControlGroup OBJECT-GROUP
OBJECTS {
checkCtrlAdminStatus,
checkCtrlOperStatus
}
STATUS current
DESCRIPTION
"A collection of objects controlling the state of the
CHECK-MIB."
::= { checkGroups 2 }
checkResultGroup OBJECT-GROUP
OBJECTS {
checkResultSeverity,
checkResultSize,
checkResultTime,
checkResultInterval,
checkResultSeverityThreshold,
checkResultStorageType,
checkResultRowStatus
}
Nunzi, Quittek, Brunner, Dietz [Page 32]
Internet-Draft December 2003
STATUS current
DESCRIPTION
"A collection of objects defining a check."
::= { checkGroups 3 }
checkRuleGroup OBJECT-GROUP
OBJECTS {
checkRuleOid,
checkRuleValue,
checkRuleOperation,
checkRuleSeverity,
checkRuleRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects defining the operations
computed for each check."
::= { checkGroups 4 }
checkFailureGroup OBJECT-GROUP
OBJECTS {
checkFailureOid
}
STATUS current
DESCRIPTION
"A collection of objects indicating managed objects
for which a check operation failed."
::= { checkGroups 5 }
checkNotificationsGroup OBJECT-GROUP
OBJECTS {
checkFailed
}
STATUS current
DESCRIPTION
"The notifications emitted by the CHECK-MIB."
::= { checkGroups 6 }
END
8. Security Considerations
This MIB allow the execution of check procedures on the devices. An
improper manipulation of its objects can lead on one side to waste of
device's resources or to spoofing of managed object otherwise not
accessible and on the other hand to alter the normal monitor process
of managers.
There are a number of management objects defined in this MIB module
Nunzi, Quittek, Brunner, Dietz [Page 33]
Internet-Draft December 2003
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
- The use of checkCtrlAdminStatus can turn off the check procedures
configured on the device; thus disabling the whole monitor
application using them;
- The use of checkResultTable can alter or remove the configured
checks; moreover it can allow the creation of new checks wasting
resources on the controlled device;
- The use of the checkRuleTable can alter or remove the configured
rules; in particular it can be possible to set the OID of managed
objects to spy their values through the check procedure; moreover the
improper addition of new rules can result in waste of resources on
the controlled device.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is REQUIRED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
For implementations of the CHECK MIB it is REQUIRED to deploy SNMPv3
and to enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
9. Normative References
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
Nunzi, Quittek, Brunner, Dietz [Page 34]
Internet-Draft December 2003
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
for Describing Simple Network Management Protocol (SNMP)
Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3413] Levi, D., Meyer, P. and B. Stewart "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC 3413,
December 2002
10. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed
Objects for the Delegation of Management Scripts", RFC 3165,
August 2001.
[RFC2982] Stewart, B., "Distributed Management Expression MIB", RFC
2982, October 2000.
[RFC2981] Stewart, B., "Event MIB", RFC 2981, October 2000.
11. Authors' Addresses
Giorgio Nunzi
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-39
Email: nunzi@netlab.nec.de
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-15
EMail: quittek@netlab.nec.de
Nunzi, Quittek, Brunner, Dietz [Page 35]
Internet-Draft December 2003
Marcus Brunner
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-29
Email: brunner@netlab.nec.de
Thomas Dietz
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-28
Email: dietz@netlab.nec.de
12. IPR Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
Nunzi, Quittek, Brunner, Dietz [Page 36]
Internet-Draft December 2003
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Nunzi, Quittek, Brunner, Dietz [Page 37]