As per Relevance of the word monitoring, we have this rfc below:
Network Working Group S.
Request for Comments: 2819 Lucent
STD: 59 May 2000
Obsoletes: 1757
Category: Standards
Remote Network Monitoring Management Information
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo defines a portion of the Management Information Base (MIB
for use with network management protocols in TCP/IP-based internets
In particular, it defines objects for managing remote
monitoring devices
This memo obsoletes RFC 1757. This memo extends that specification
documenting the RMON MIB in SMIv2 format while remaining
identical to the existing SMIv1-based MIB
Waldbusser Standards Track [Page 1]
RFC 2819 Remote Network Monitoring MIB May 2000
Table of
1 The SNMP Management Framework .............................. 2
2 Overview ................................................... 3
2.1 Remote Network Management Goals .......................... 4
2.2 Textual Conventions ...................................... 5
2.3 Structure of MIB ......................................... 5
2.3.1 The Ethernet Statistics Group .......................... 6
2.3.2 The History Control Group .............................. 6
2.3.3 The Ethernet History Group ............................. 6
2.3.4 The Alarm Group ........................................ 7
2.3.5 The Host Group ......................................... 7
2.3.6 The HostTopN Group ..................................... 7
2.3.7 The Matrix Group ....................................... 7
2.3.8 The Filter Group ....................................... 7
2.3.9 The Packet Capture Group ............................... 8
2.3.10 The Event Group ....................................... 8
3 Control of Remote Network Monitoring Devices ............... 8
3.1 Resource Sharing Among Multiple Management Stations ... 9
3.2 Row Addition Among Multiple Management Stations .......... 10
4 Conventions ................................................ 11
5 Definitions ................................................ 12
6 Security Considerations .................................... 94
7 Acknowledgments ............................................ 95
8 Author's Address ........................................... 95
9 References ................................................. 95
10 Intellectual Property ..................................... 97
11 Full Copyright Statement .................................. 98
1. The SNMP Management
The SNMP Management Framework presently consists of five
components
o An overall architecture, described in RFC 2571 [1].
o Mechanisms for describing and naming objects and events for
purpose of management. The first version of this Structure
Management Information (SMI) is called SMIv1 and described in
16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
second version, called SMIv2, is described in STD 58, RFC 2578
[5], RFC 2579 [6] and RFC 2580 [7].
o Message protocols for transferring management information.
first version of the SNMP message protocol is called SNMPv1
described in STD 15, RFC 1157 [8]. A second version of the
message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901 [9] and
Waldbusser Standards Track [Page 2]
RFC 2819 Remote Network Monitoring MIB May 2000
1906 [10]. The third version of the message protocol is
SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
[12].
o Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in STD 15, RFC 1157 [8]. A second set of
operations and associated PDU formats is described in RFC 1905
[13].
o A set of fundamental applications described in RFC 2573 [14]
the view-based access control mechanism described in RFC 2575
[15].
A more detailed introduction to the current SNMP Management
can be found in RFC 2570 [22].
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI
This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
translation is possible (use of Counter64). Some machine
information in SMIv2 will be converted into textual descriptions
SMIv1 during the translation process. However, this loss of
readable information is not considered to change the semantics of
MIB
2.
Remote network monitoring devices, often called monitors or probes
are instruments that exist for the purpose of managing a network
Often these remote probes are stand-alone devices and
significant internal resources for the sole purpose of managing
network. An organization may employ many of these devices, one
network segment, to manage its internet. In addition, these
may be used for a network management service provider to access
client network, often geographically remote
The objects defined in this document are intended as an
between an RMON agent and an RMON management application and are
intended for direct manipulation by humans. While some users
tolerate the direct display of some of these objects, few
Waldbusser Standards Track [Page 3]
RFC 2819 Remote Network Monitoring MIB May 2000
tolerate the complexity of manually manipulating objects
accomplish row creation. These functions should be handled by
management application
While most of the objects in this document are suitable for
management of any type of network, there are some which are
to managing Ethernet networks. These are the objects in
etherStatsTable, the etherHistoryTable, and some attributes of
filterPktStatus and capturBufferPacketStatus objects. The design
this MIB allows similar objects to be defined for other
types. It is intended that future versions of this document
additional documents will define extensions for other network types
There are a number of companion documents to the RMON MIB. The
Ring RMON MIB [19] provides objects specific to managing Token
networks. The RMON-2 MIB [20] extends RMON by providing RMON
up to the application layer. The SMON MIB [21] extends RMON
providing RMON analysis for switched networks
2.1. Remote Network Management
o Offline
There are sometimes conditions when a management station
not be in constant contact with its remote monitoring devices
This is sometimes by design in an attempt to
communications costs (especially when communicating over a
or dialup link), or by accident as network failures affect
communications between the management station and the probe
For this reason, this MIB allows a probe to be configured
perform diagnostics and to collect statistics continuously,
when communication with the management station may not
possible or efficient. The probe may then attempt to notify
management station when an exceptional condition occurs. Thus
even in circumstances where communication between
station and probe is not continuous, fault, performance,
configuration information may be continuously accumulated
communicated to the management station conveniently
efficiently
o Proactive
Given the resources available on the monitor, it is
helpful for it continuously to run diagnostics and to
network performance. The monitor is always available at
onset of any failure. It can notify the management station
the failure and can store historical statistical
Waldbusser Standards Track [Page 4]
RFC 2819 Remote Network Monitoring MIB May 2000
about the failure. This historical information can be
back by the management station in an attempt to perform
diagnosis into the cause of the problem
o Problem Detection and
The monitor can be configured to recognize conditions,
notably error conditions, and continuously to check for them
When one of these conditions occurs, the event may be logged
and management stations may be notified in a number of ways
o Value Added
Because a remote monitoring device represents a network
dedicated exclusively to network management functions,
because it is located directly on the monitored portion of
network, the remote network monitoring device has
opportunity to add significant value to the data it collects
For instance, by highlighting those hosts on the network
generate the most traffic or errors, the probe can give
management station precisely the information it needs to solve
class of problems
o Multiple
An organization may have multiple management stations
different units of the organization, for different
(e.g. engineering and operations), and in an attempt to
disaster recovery. Because environments with
management stations are common, the remote network
device has to deal with more than own management station
potentially using its resources concurrently
2.2. Textual
Two new data types are introduced as a textual convention in this
document, OwnerString and EntryStatus
2.3. Structure of
The objects are arranged into the following groups
- ethernet
- history
- ethernet
-
-
Waldbusser Standards Track [Page 5]
RFC 2819 Remote Network Monitoring MIB May 2000
-
-
-
- packet
-
These groups are the basic unit of conformance. If a
monitoring device implements a group, then it must implement
objects in that group. For example, a managed agent that
the host group must implement the hostControlTable, the hostTable
the hostTimeTable. While this section provides an overview
grouping and conformance information for this MIB, the
reference for such information is contained in the MODULE-
and OBJECT-GROUP macros later in this MIB
All groups in this MIB are optional. Implementations of this
must also implement the system group of MIB-II [16] and the IF-
[17]. MIB-II may also mandate the implementation of
groups
These groups are defined to provide a means of assigning
identifiers, and to provide a method for implementors of
agents to know which objects they must implement
2.3.1. The Ethernet Statistics
The ethernet statistics group contains statistics measured by
probe for each monitored Ethernet interface on this device.
group consists of the etherStatsTable
2.3.2. The History Control
The history control group controls the periodic statistical
of data from various types of networks. This group consists of
historyControlTable
2.3.3. The Ethernet History
The ethernet history group records periodic statistical samples
an ethernet network and stores them for later retrieval. This
consists of the etherHistoryTable
Waldbusser Standards Track [Page 6]
RFC 2819 Remote Network Monitoring MIB May 2000
2.3.4. The Alarm
The alarm group periodically takes statistical samples from
in the probe and compares them to previously configured thresholds
If the monitored variable crosses a threshold, an event is generated
A hysteresis mechanism is implemented to limit the generation
alarms. This group consists of the alarmTable and requires
implementation of the event group
2.3.5. The Host
The host group contains statistics associated with each
discovered on the network. This group discovers hosts on the
by keeping a list of source and destination MAC Addresses seen
good packets promiscuously received from the network. This
consists of the hostControlTable, the hostTable, and
hostTimeTable
2.3.6. The HostTopN
The hostTopN group is used to prepare reports that describe the
that top a list ordered by one of their statistics. The
statistics are samples of one of their base statistics over
interval specified by the management station. Thus, these
are rate based. The management station also selects how many
hosts are reported. This group consists of the
and the hostTopNTable, and requires the implementation of the
group
2.3.7. The Matrix
The matrix group stores statistics for conversations between sets
two addresses. As the device detects a new conversation, it
a new entry in its tables. This group consists of
matrixControlTable, the matrixSDTable and the matrixDSTable
2.3.8. The Filter
The filter group allows packets to be matched by a filter equation
These matched packets form a data stream that may be captured or
generate events. This group consists of the filterTable and
channelTable
Waldbusser Standards Track [Page 7]
RFC 2819 Remote Network Monitoring MIB May 2000
2.3.9. The Packet Capture
The Packet Capture group allows packets to be captured after
flow through a channel. This group consists of
bufferControlTable and the captureBufferTable, and requires
implementation of the filter group
2.3.10. The Event
The event group controls the generation and notification of
from this device. This group consists of the eventTable and
logTable
3. Control of Remote Network Monitoring
Due to the complex nature of the available functions in
devices, the functions often need user configuration. In many cases
the function requires parameters to be set up for a data
operation. The operation can proceed only after these parameters
fully set up
Many functional groups in this MIB have one or more tables in
to set up control parameters, and one or more data tables in which
place the results of the operation. The control tables are
read-write in nature, while the data tables are typically read-only
Because the parameters in the control table often describe
data in the data table, many of the parameters can be modified
when the control entry is invalid. Thus, the method for
these parameters is to invalidate the control entry, causing
deletion and the deletion of any associated data entries, and
create a new control entry with the proper parameters. Deleting
control entry also gives a convenient method for reclaiming
resources used by the associated data
Some objects in this MIB provide a mechanism to execute an action
the remote monitoring device. These objects may execute an action
a result of a change in the state of the object. For those
in this MIB, a request to set an object to the same value as
currently holds would thus cause no action to occur
To facilitate control by multiple managers, resources have to
shared among the managers. These resources are typically the
and computation resources that a function requires
Waldbusser Standards Track [Page 8]
RFC 2819 Remote Network Monitoring MIB May 2000
3.1. Resource Sharing Among Multiple Management
When multiple management stations wish to use functions that
for a finite amount of resources on a device, a method to
this sharing of resources is required. Potential conflicts include
o Two management stations wish to simultaneously use
that together would exceed the capability of the device
o A management station uses a significant amount of resources
a long period of time
o A management station uses resources and then crashes
forgetting to free the resources so others may use them
A mechanism is provided for each management station
function in this MIB to avoid these conflicts and to help
them when they occur. Each function has a label identifying
initiator (owner) of the function. This label is set by
initiator to provide for the following possibilities
o A management station may recognize resources it owns and
longer needs
o A network operator can find the management station that
the resource and negotiate for it to be freed
o A network operator may decide to unilaterally free
another network operator has reserved
o Upon initialization, a management station may
resources it had reserved in the past. With this
it may free the resources if it no longer needs them
Management stations and probes should support any format of the
string dictated by the local policy of the organization. It
suggested that this name contain one or more of the following:
address, management station name, network manager's name, location
or phone number. This information will help users to share
resources more effectively
There is often default functionality that the device or
administrator of the probe (often the network administrator)
to set up. The resources associated with this functionality are
owned by the device itself or by the network administrator, and
intended to be long-lived. In this case, the device or
administrator will set the relevant owner object to a string
with 'monitor'. Indiscriminate modification of the monitor-
configuration by network management stations is discouraged.
fact, a network management station should only modify these
under the direction of the administrator of the probe
Waldbusser Standards Track [Page 9]
RFC 2819 Remote Network Monitoring MIB May 2000
Resources on a probe are scarce and are typically allocated
control rows are created by an application. Since many
may be using a probe simultaneously, indiscriminate allocation
resources to particular applications is very likely to cause
shortages in the probe
When a network management station wishes to utilize a function in
monitor, it is encouraged to first scan the control table of
function to find an instance with similar parameters to share.
is especially true for those instances owned by the monitor,
can be assumed to change infrequently. If a management
decides to share an instance owned by another management station,
should understand that the management station that owns the
may indiscriminately modify or delete it
It should be noted that a management application should have the
trust in a monitor-owned row because it should be changed
infrequently. A row owned by the management application is
long-lived because a network administrator is more likely to re
assign resources from a row that is in use by one user than from
monitor-owned row that is potentially in use by many users. A
owned by another application would be even less long-lived
the other application may delete or modify that row completely at
discretion
3.2. Row Addition Among Multiple Management
The addition of new rows is achieved using the method described
RFC 1905 [13]. In this MIB, rows are often added to a table in
to configure a function. This configuration usually
parameters that control the operation of the function. The
must check these parameters to make sure they are appropriate
restrictions defined in this MIB as well as any
specific restrictions such as lack of resources. The
implementor may be confused as to when to check these parameters
when to signal to the management station that the parameters
invalid. There are two opportunities
o When the management station sets each parameter object
o When the management station sets the entry status object
valid
If the latter is chosen, it would be unclear to the
station which of the several parameters was invalid and caused
badValue error to be emitted. Thus, wherever possible,
implementor should choose the former as it will provide
information to the management station
Waldbusser Standards Track [Page 10]
RFC 2819 Remote Network Monitoring MIB May 2000
A problem can arise when multiple management stations attempt to
configuration information simultaneously using SNMP. When
involves the addition of a new conceptual row in the same
table, the managers may collide, attempting to create the same entry
To guard against these collisions, each such control entry contains
status object with special semantics that help to arbitrate among
managers. If an attempt is made with the row addition mechanism
create such a status object and that object already exists, an
is returned. When more than one manager simultaneously attempts
create the same conceptual row, only the first can succeed.
others will receive an error
When a manager wishes to create a new control entry, it needs
choose an index for that row. It may choose this index in a
of ways, hopefully minimizing the chances that the index is in use
another manager. If the index is in use, the mechanism
previously will guard against collisions. Examples of schemes
choose index values include random selection or scanning the
table looking for the first unused index. Because index values
be any valid value in the range and they are chosen by the manager
the agent must allow a row to be created with any unused index
if it has the resources to create a new row
Some tables in this MIB reference other tables within this MIB.
creating or deleting entries in these tables, it is
allowable for dangling references to exist. There is no
order for creating or deleting entries in these tables
4.
The following conventions are used throughout the RMON MIB and
companion documents
Good
Good packets are error-free packets that have a valid frame length
For example, on Ethernet, good packets are error-free packets
are between 64 octets long and 1518 octets long. They follow
form defined in IEEE 802.3 section 3.2.all
Bad
Bad packets are packets that have proper framing and are
recognized as packets, but contain errors within the packet or
an invalid length. For example, on Ethernet, bad packets have
valid preamble and SFD, but have a bad CRC, or are either
than 64 octets or longer than 1518 octets
Waldbusser Standards Track [Page 11]
RFC 2819 Remote Network Monitoring MIB May 2000
5.
RMON-MIB DEFINITIONS ::=
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY
NOTIFICATION-TYPE, mib-2, Counter32,
Integer32, TimeTicks FROM SNMPv2-
TEXTUAL-CONVENTION, DisplayString FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-GROUP
NOTIFICATION-GROUP FROM SNMPv2-CONF
-- Remote Network Monitoring
rmonMibModule MODULE-
LAST-UPDATED "200005110000Z" -- 11 May, 2000
ORGANIZATION "IETF RMON MIB Working Group
CONTACT-
"Steve
Phone: +1-650-948-6500
Fax: +1-650-745-0671
Email: waldbusser@nextbeacon.com
"Remote network monitoring devices, often
monitors or probes, are instruments that exist
the purpose of managing a network. This MIB
objects for managing remote network monitoring devices."
REVISION "200005110000Z" -- 11 May, 2000
"Reformatted into SMIv2 format
This version published as RFC 2819."
REVISION "199502010000Z" -- 1 Feb, 1995
"Bug fixes, clarifications and minor changes based
implementation experience, published as RFC1757 [18].
Two changes were made to object definitions
1) A new status bit has been defined for
captureBufferPacketStatus object, indicating that
packet order within the capture buffer may not be identical
the packet order as received off the wire. This bit may
Waldbusser Standards Track [Page 12]
RFC 2819 Remote Network Monitoring MIB May 2000
be used for packets transmitted by the probe. Older
applications can safely ignore this status bit, which might
used by newer agents
2) The packetMatch trap has been removed. This trap was
actually 'approved' and was not added to this document
with the risingAlarm and fallingAlarm traps. The
trap could not be throttled, which could cause disruption
normal network traffic under some circumstances. An NMS
configure a risingAlarm threshold on the
channelMatches instance if a trap is desired for a
event. Note that logging of packetMatch events is
supported--only trap generation for such events has
removed
In addition, several clarifications to individual
definitions have been added to assist agent and
implementors
- global definition of 'good packets' and 'bad packets
- more detailed text governing conceptual row creation
- instructions for probes relating to interface changes
- clarification of some ethernet counter
- recommended formula for calculating network
- clarification of channel and captureBuffer behavior for
unusual
- examples of proper instance naming for each table
REVISION "199111010000Z" -- 1 Nov, 1991
"The original version of this MIB, published as RFC1271."
::= { rmonConformance 8 }
rmon OBJECT IDENTIFIER ::= { mib-2 16 }
-- textual
OwnerString ::= TEXTUAL-
STATUS
Waldbusser Standards Track [Page 13]
RFC 2819 Remote Network Monitoring MIB May 2000
"This data type is used to model an
assigned name of the owner of a resource.
must accept values composed of well-formed NVT
sequences. In addition, implementations should
values composed of well-formed UTF-8 sequences
It is suggested that this name contain one or more
the following: IP address, management station name
network manager's name, location, or phone number
In some cases the agent itself will be the owner
an entry. In these cases, this string shall be
to a string starting with 'monitor'.
SNMP access control is articulated entirely in
of the contents of MIB views; access to a
SNMP object instance depends only upon its
or absence in a particular MIB view and never
its value or the value of related object instances
Thus, objects of this type afford resolution
resource contention only among
managers; they realize no access control
with respect to uncooperative parties."
SYNTAX OCTET STRING (SIZE (0..127))
EntryStatus ::= TEXTUAL-
STATUS
"The status of a table entry
Setting this object to the value invalid(4) has
effect of invalidating the corresponding entry
That is, it effectively disassociates the
identified with said entry
It is an implementation-specific matter as to
the agent removes an invalidated entry from the table
Accordingly, management stations must be prepared
receive tabular information from agents that
to entries currently not in use.
interpretation of such entries requires
of the relevant EntryStatus object
An existing instance of this object cannot be set
createRequest(2). This object may only be set
createRequest(2) when this instance is created.
this object is created, the agent may wish to
supplemental object instances with default
to complete a conceptual row in this table. Because
Waldbusser Standards Track [Page 14]
RFC 2819 Remote Network Monitoring MIB May 2000
creation of these default objects is entirely at the
of the agent, the manager must not assume that any will
created, but may make use of any that are created
Immediately after completing the create operation, the
must set this object to underCreation(3).
When in the underCreation(3) state, an entry is allowed
exist in a possibly incomplete, possibly inconsistent state
usually to allow it to be modified in multiple PDUs. When
this state, an entry is not fully active
Entries shall exist in the underCreation(3) state
the management station is finished configuring the
and sets this object to valid(1) or aborts, setting
object to invalid(4). If the agent determines that
entry has been in the underCreation(3) state for
abnormally long time, it may decide that the
station has crashed. If the agent makes this decision
it may set this object to invalid(4) to reclaim
entry. A prudent agent will understand that
management station may need to wait for human
and will allow for that possibility in
determination of this abnormally long period
An entry in the valid(1) state is fully configured
consistent and fully represents the configuration
operation such a row is intended to represent.
example, it could be a statistical function that
configured and active, or a filter that is
in the list of filters processed by the packet
process
A manager is restricted to changing the state of an entry
the following ways
To: valid createRequest underCreation
From
valid OK NO OK
createRequest N/A N/A N/A N/
underCreation OK NO OK
invalid NO NO NO
nonExistent NO OK NO
In the table above, it is not applicable to move the
from the createRequest state to any other state because
manager will never find the variable in that state.
nonExistent state is not a value of the enumeration,
it means that the entryStatus variable does not exist at all
Waldbusser Standards Track [Page 15]
RFC 2819 Remote Network Monitoring MIB May 2000
An agent may allow an entryStatus variable to change state
additional ways, so long as the semantics of the states
followed. This allowance is made to ease the implementation
the agent and is made despite the fact that managers
never exercise these additional state transitions."
SYNTAX INTEGER {
valid(1),
createRequest(2),
underCreation(3),
invalid(4)
}
statistics OBJECT IDENTIFIER ::= { rmon 1 }
history OBJECT IDENTIFIER ::= { rmon 2 }
alarm OBJECT IDENTIFIER ::= { rmon 3 }
hosts OBJECT IDENTIFIER ::= { rmon 4 }
hostTopN OBJECT IDENTIFIER ::= { rmon 5 }
matrix OBJECT IDENTIFIER ::= { rmon 6 }
filter OBJECT IDENTIFIER ::= { rmon 7 }
capture OBJECT IDENTIFIER ::= { rmon 8 }
event OBJECT IDENTIFIER ::= { rmon 9 }
rmonConformance OBJECT IDENTIFIER ::= { rmon 20 }
-- The Ethernet Statistics
--
-- Implementation of the Ethernet Statistics group is optional
-- Consult the MODULE-COMPLIANCE macro for the
-- conformance information for this MIB
--
-- The ethernet statistics group contains statistics measured by
-- probe for each monitored interface on this device.
-- statistics take the form of free running counters that start
-- zero when a valid entry is created
--
-- This group currently has statistics defined only
-- Ethernet interfaces. Each etherStatsEntry contains
-- for one Ethernet interface. The probe must create
-- etherStats entry for each monitored Ethernet
-- on the device
etherStatsTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"A list of Ethernet statistics entries."
::= { statistics 1 }
Waldbusser Standards Track [Page 16]
RFC 2819 Remote Network Monitoring MIB May 2000
etherStatsEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A collection of statistics kept for a
Ethernet interface. As an example, an instance of
etherStatsPkts object might be named etherStatsPkts.1"
INDEX { etherStatsIndex }
::= { etherStatsTable 1 }
EtherStatsEntry ::= SEQUENCE {
etherStatsIndex Integer32,
etherStatsDataSource OBJECT IDENTIFIER
etherStatsDropEvents Counter32,
etherStatsOctets Counter32,
etherStatsPkts Counter32,
etherStatsBroadcastPkts Counter32,
etherStatsMulticastPkts Counter32,
etherStatsCRCAlignErrors Counter32,
etherStatsUndersizePkts Counter32,
etherStatsOversizePkts Counter32,
etherStatsFragments Counter32,
etherStatsJabbers Counter32,
etherStatsCollisions Counter32,
etherStatsPkts64Octets Counter32,
etherStatsPkts65to127Octets Counter32,
etherStatsPkts128to255Octets Counter32,
etherStatsPkts256to511Octets Counter32,
etherStatsPkts512to1023Octets Counter32,
etherStatsPkts1024to1518Octets Counter32,
etherStatsOwner OwnerString
etherStatsStatus
}
etherStatsIndex OBJECT-
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-
STATUS
"The value of this object uniquely identifies
etherStats entry."
::= { etherStatsEntry 1 }
etherStatsDataSource OBJECT-
SYNTAX OBJECT
MAX-ACCESS read-
STATUS
Waldbusser Standards Track [Page 17]
RFC 2819 Remote Network Monitoring MIB May 2000
"This object identifies the source of the data
this etherStats entry is configured to analyze.
source can be any ethernet interface on this device
In order to identify a particular interface, this
shall identify the instance of the ifIndex object
defined in RFC 2233 [17], for the desired interface
For example, if an entry were to receive data
interface #1, this object would be set to ifIndex.1.
The statistics in this group reflect all
on the local network segment attached to the
interface
An agent may or may not be able to tell if
changes to the media of the interface have occurred
necessitate an invalidation of this entry. For example,
hot-pluggable ethernet card could be pulled out and
by a token-ring card. In such a case, if the agent has
knowledge of the change, it is recommended that
invalidate this entry
This object may not be modified if the
etherStatsStatus object is equal to valid(1)."
::= { etherStatsEntry 2 }
etherStatsDropEvents OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of events in which
were dropped by the probe due to lack of resources
Note that this number is not necessarily the number
packets dropped; it is just the number of times
condition has been detected."
::= { etherStatsEntry 3 }
etherStatsOctets OBJECT-
SYNTAX Counter32
UNITS "Octets
MAX-ACCESS read-
STATUS
"The total number of octets of data (
those in bad packets) received on
network (excluding framing bits but
FCS octets).
Waldbusser Standards Track [Page 18]
RFC 2819 Remote Network Monitoring MIB May 2000
This object can be used as a reasonable estimate
10-Megabit ethernet utilization. If greater precision
desired, the etherStatsPkts and etherStatsOctets
should be sampled before and after a common interval.
differences in the sampled values are Pkts and Octets
respectively, and the number of seconds in the interval
Interval. These values are used to calculate the
as follows
Pkts * (9.6 + 6.4) + (Octets * .8)
Utilization = -------------------------------------
Interval * 10,000
The result of this equation is the value Utilization
is the percent utilization of the ethernet segment on
scale of 0 to 100 percent."
::= { etherStatsEntry 4 }
etherStatsPkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets (including bad packets
broadcast packets, and multicast packets) received."
::= { etherStatsEntry 5 }
etherStatsBroadcastPkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of good packets received that
directed to the broadcast address. Note that
does not include multicast packets."
::= { etherStatsEntry 6 }
etherStatsMulticastPkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of good packets received that
directed to a multicast address. Note that this
does not include packets directed to the
Waldbusser Standards Track [Page 19]
RFC 2819 Remote Network Monitoring MIB May 2000
address."
::= { etherStatsEntry 7 }
etherStatsCRCAlignErrors OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets received
had a length (excluding framing bits,
including FCS octets) of between 64 and 1518
octets, inclusive, but had either a
Frame Check Sequence (FCS) with an
number of octets (FCS Error) or a bad FCS
a non-integral number of octets (Alignment Error)."
::= { etherStatsEntry 8 }
etherStatsUndersizePkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets received that
less than 64 octets long (excluding framing bits
but including FCS octets) and were otherwise
formed."
::= { etherStatsEntry 9 }
etherStatsOversizePkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets received that
longer than 1518 octets (excluding framing bits
but including FCS octets) and were
well formed."
::= { etherStatsEntry 10 }
etherStatsFragments OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
Waldbusser Standards Track [Page 20]
RFC 2819 Remote Network Monitoring MIB May 2000
"The total number of packets received that were less
64 octets in length (excluding framing bits but
FCS octets) and had either a bad Frame Check
(FCS) with an integral number of octets (FCS Error) or
bad FCS with a non-integral number of octets (
Error).
Note that it is entirely normal for etherStatsFragments
increment. This is because it counts both runts (which
normal occurrences due to collisions) and noise hits."
::= { etherStatsEntry 11 }
etherStatsJabbers OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets received that
longer than 1518 octets (excluding framing bits
but including FCS octets), and had either a
Frame Check Sequence (FCS) with an integral
of octets (FCS Error) or a bad FCS with a non-
number of octets (Alignment Error).
Note that this definition of jabber is
than the definition in IEEE-802.3 section 8.2.1.5
(10BASE5) and section 10.3.1.4 (10BASE2).
documents define jabber as the condition where
packet exceeds 20 ms. The allowed range to
jabber is between 20 ms and 150 ms."
::= { etherStatsEntry 12 }
etherStatsCollisions OBJECT-
SYNTAX Counter32
UNITS "Collisions
MAX-ACCESS read-
STATUS
"The best estimate of the total number of
on this Ethernet segment
The value returned will depend on the location of
RMON probe. Section 8.2.1.3 (10BASE-5) and
10.3.1.3 (10BASE-2) of IEEE standard 802.3 states that
station must detect a collision, in the receive mode,
three or more stations are transmitting simultaneously.
repeater port must detect a collision when two or
Waldbusser Standards Track [Page 21]
RFC 2819 Remote Network Monitoring MIB May 2000
stations are transmitting simultaneously. Thus a
placed on a repeater port could record more
than a probe connected to a station on the same
would
Probe location plays a much smaller role when
10BASE-T. 14.2.1.4 (10BASE-T) of IEEE standard 802.3
defines a collision as the simultaneous presence of
on the DO and RD circuits (transmitting and
at the same time). A 10BASE-T station can only
collisions when it is transmitting. Thus probes placed
a station and a repeater, should report the same number
collisions
Note also that an RMON probe inside a repeater
ideally report collisions between the repeater and one
more other hosts (transmit collisions as defined by
802.3k) plus receiver collisions observed on any
segments to which the repeater is connected."
::= { etherStatsEntry 13 }
etherStatsPkts64Octets OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets (including
packets) received that were 64 octets in
(excluding framing bits but including FCS octets)."
::= { etherStatsEntry 14 }
etherStatsPkts65to127Octets OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets (including
packets) received that were
65 and 127 octets in length
(excluding framing bits but including FCS octets)."
::= { etherStatsEntry 15 }
etherStatsPkts128to255Octets OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
Waldbusser Standards Track [Page 22]
RFC 2819 Remote Network Monitoring MIB May 2000
STATUS
"The total number of packets (including
packets) received that were
128 and 255 octets in length
(excluding framing bits but including FCS octets)."
::= { etherStatsEntry 16 }
etherStatsPkts256to511Octets OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets (including
packets) received that were
256 and 511 octets in length
(excluding framing bits but including FCS octets)."
::= { etherStatsEntry 17 }
etherStatsPkts512to1023Octets OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets (including
packets) received that were
512 and 1023 octets in length
(excluding framing bits but including FCS octets)."
::= { etherStatsEntry 18 }
etherStatsPkts1024to1518Octets OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets (including
packets) received that were
1024 and 1518 octets in length
(excluding framing bits but including FCS octets)."
::= { etherStatsEntry 19 }
etherStatsOwner OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
Waldbusser Standards Track [Page 23]
RFC 2819 Remote Network Monitoring MIB May 2000
"The entity that configured this entry and is
using the resources assigned to it."
::= { etherStatsEntry 20 }
etherStatsStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The status of this etherStats entry."
::= { etherStatsEntry 21 }
-- The History Control
-- Implementation of the History Control group is optional
-- Consult the MODULE-COMPLIANCE macro for the
-- conformance information for this MIB
--
-- The history control group controls the periodic
-- sampling of data from various types of networks.
-- historyControlTable stores configuration entries that
-- define an interface, polling period, and other parameters
-- Once samples are taken, their data is stored in an
-- in a media-specific table. Each such entry defines
-- sample, and is associated with the historyControlEntry
-- caused the sample to be taken. Each counter in
-- etherHistoryEntry counts the same event as its similarly-
-- counterpart in the etherStatsEntry, except that each value
-- is a cumulative sum during a sampling period
--
-- If the probe keeps track of the time of day, it should
-- the first sample of the history at a time such
-- when the next hour of the day begins, a sample
-- started at that instant. This tends to make
-- user-friendly reports, and enables comparison of
-- from different probes that have relatively accurate
-- of day
--
-- The probe is encouraged to add two history control
-- per monitored interface upon initialization that describe a
-- term and a long term polling period. Suggested parameters are 30
-- seconds for the short term polling period and 30 minutes
-- the long term period
historyControlTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
Waldbusser Standards Track [Page 24]
RFC 2819 Remote Network Monitoring MIB May 2000
STATUS
"A list of history control entries."
::= { history 1 }
historyControlEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A list of parameters that set up a periodic sampling
statistics. As an example, an instance of
historyControlInterval object might be
historyControlInterval.2"
INDEX { historyControlIndex }
::= { historyControlTable 1 }
HistoryControlEntry ::= SEQUENCE {
historyControlIndex Integer32,
historyControlDataSource OBJECT IDENTIFIER
historyControlBucketsRequested Integer32,
historyControlBucketsGranted Integer32,
historyControlInterval Integer32,
historyControlOwner OwnerString
historyControlStatus
}
historyControlIndex OBJECT-
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-
STATUS
"An index that uniquely identifies an entry in
historyControl table. Each such entry defines
set of samples at a particular interval for
interface on the device."
::= { historyControlEntry 1 }
historyControlDataSource OBJECT-
SYNTAX OBJECT
MAX-ACCESS read-
STATUS
"This object identifies the source of the data
which historical data was collected
placed in a media-specific table on behalf of
historyControlEntry. This source can be
interface on this device. In order to
Waldbusser Standards Track [Page 25]
RFC 2819 Remote Network Monitoring MIB May 2000
a particular interface, this object shall
the instance of the ifIndex object,
in RFC 2233 [17], for the desired interface
For example, if an entry were to receive data
interface #1, this object would be set to ifIndex.1.
The statistics in this group reflect all
on the local network segment attached to the
interface
An agent may or may not be able to tell if
changes to the media of the interface have occurred
necessitate an invalidation of this entry. For example,
hot-pluggable ethernet card could be pulled out and
by a token-ring card. In such a case, if the agent has
knowledge of the change, it is recommended that
invalidate this entry
This object may not be modified if the
historyControlStatus object is equal to valid(1)."
::= { historyControlEntry 2 }
historyControlBucketsRequested OBJECT-
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-
STATUS
"The requested number of discrete time
over which data is to be saved in the part of
media-specific table associated with
historyControlEntry
When this object is created or modified, the
should set historyControlBucketsGranted as closely
this object as is possible for the particular
implementation and available resources."
DEFVAL { 50 }
::= { historyControlEntry 3 }
historyControlBucketsGranted OBJECT-
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-
STATUS
"The number of discrete sampling
over which data shall be saved in the part
the media-specific table associated with
historyControlEntry
Waldbusser Standards Track [Page 26]
RFC 2819 Remote Network Monitoring MIB May 2000
When the associated
object is created or modified, the
should set this object as closely to the
value as is possible for the
probe implementation and available resources.
probe must not lower this value except as a
of a modification to the
historyControlBucketsRequested object
There will be times when the actual number
buckets associated with this entry is less
the value of this object. In this case, at
end of each sampling interval, a new bucket
be added to the media-specific table
When the number of buckets reaches the value
this object and a new bucket is to be added to
media-specific table, the oldest bucket
with this historyControlEntry shall be deleted
the agent so that the new bucket can be added
When the value of this object changes to a value
than the current value, entries are
from the media-specific table associated with
historyControlEntry. Enough of the oldest of
entries shall be deleted by the agent so that
number remains less than or equal to the new value
this object
When the value of this object changes to a value
than the current value, the number of associated media
specific entries may be allowed to grow."
::= { historyControlEntry 4 }
historyControlInterval OBJECT-
SYNTAX Integer32 (1..3600)
UNITS "Seconds
MAX-ACCESS read-
STATUS
"The interval in seconds over which the data
sampled for each bucket in the part of
media-specific table associated with
historyControlEntry. This interval
be set to any number of seconds between 1
3600 (1 hour).
Because the counters in a bucket may overflow at
Waldbusser Standards Track [Page 27]
RFC 2819 Remote Network Monitoring MIB May 2000
maximum value with no indication, a prudent manager
take into account the possibility of overflow in any
the associated counters. It is important to consider
minimum time in which any counter could overflow on
particular media type and set the
object to a value less than this interval. This
typically most important for the 'octets' counter in
media-specific table. For example, on an
network, the etherHistoryOctets counter could
in about one hour at the Ethernet's
utilization
This object may not be modified if the
historyControlStatus object is equal to valid(1)."
DEFVAL { 1800 }
::= { historyControlEntry 5 }
historyControlOwner OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The entity that configured this entry and is
using the resources assigned to it."
::= { historyControlEntry 6 }
historyControlStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The status of this historyControl entry
Each instance of the media-specific table
with this historyControlEntry will be deleted by the
if this historyControlEntry is not equal to valid(1)."
::= { historyControlEntry 7 }
-- The Ethernet History
-- Implementation of the Ethernet History group is optional
-- Consult the MODULE-COMPLIANCE macro for the
-- conformance information for this MIB
--
-- The Ethernet History group records periodic statistical
-- from a network and stores them for later retrieval
-- Once samples are taken, their data is stored in an
-- in a media-specific table. Each such entry defines
Waldbusser Standards Track [Page 28]
RFC 2819 Remote Network Monitoring MIB May 2000
-- sample, and is associated with the historyControlEntry
-- caused the sample to be taken. This group defines
-- etherHistoryTable, for Ethernet networks
--
etherHistoryTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"A list of Ethernet history entries."
::= { history 2 }
etherHistoryEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"An historical sample of Ethernet statistics on a
Ethernet interface. This sample is associated with
historyControlEntry which set up the parameters
a regular collection of these samples. As an example,
instance of the etherHistoryPkts object might be
etherHistoryPkts.2.89"
INDEX { etherHistoryIndex , etherHistorySampleIndex }
::= { etherHistoryTable 1 }
EtherHistoryEntry ::= SEQUENCE {
etherHistoryIndex Integer32,
etherHistorySampleIndex Integer32,
etherHistoryIntervalStart TimeTicks
etherHistoryDropEvents Counter32,
etherHistoryOctets Counter32,
etherHistoryPkts Counter32,
etherHistoryBroadcastPkts Counter32,
etherHistoryMulticastPkts Counter32,
etherHistoryCRCAlignErrors Counter32,
etherHistoryUndersizePkts Counter32,
etherHistoryOversizePkts Counter32,
etherHistoryFragments Counter32,
etherHistoryJabbers Counter32,
etherHistoryCollisions Counter32,
etherHistoryUtilization Integer32
}
etherHistoryIndex OBJECT-
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-
Waldbusser Standards Track [Page 29]
RFC 2819 Remote Network Monitoring MIB May 2000
STATUS
"The history of which this entry is a part.
history identified by a particular value of
index is the same history as
by the same value of historyControlIndex."
::= { etherHistoryEntry 1 }
etherHistorySampleIndex OBJECT-
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-
STATUS
"An index that uniquely identifies the
sample this entry represents among all
associated with the same historyControlEntry
This index starts at 1 and increases by
as each new sample is taken."
::= { etherHistoryEntry 2 }
etherHistoryIntervalStart OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The value of sysUpTime at the start of the
over which this sample was measured. If the
keeps track of the time of day, it should
the first sample of the history at a time such
when the next hour of the day begins, a sample
started at that instant. Note that following
rule may require the probe to delay collecting
first sample of the history, as each sample must
of the same interval. Also note that the sample
is currently being collected is not accessible in
table until the end of its interval."
::= { etherHistoryEntry 3 }
etherHistoryDropEvents OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of events in which
were dropped by the probe due to lack of
during this sampling interval. Note that this
is not necessarily the number of packets dropped,
is just the number of times this condition has
Waldbusser Standards Track [Page 30]
RFC 2819 Remote Network Monitoring MIB May 2000
detected."
::= { etherHistoryEntry 4 }
etherHistoryOctets OBJECT-
SYNTAX Counter32
UNITS "Octets
MAX-ACCESS read-
STATUS
"The total number of octets of data (
those in bad packets) received on
network (excluding framing bits but
FCS octets)."
::= { etherHistoryEntry 5 }
etherHistoryPkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The number of packets (including bad packets
received during this sampling interval."
::= { etherHistoryEntry 6 }
etherHistoryBroadcastPkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The number of good packets received during
sampling interval that were directed to
broadcast address."
::= { etherHistoryEntry 7 }
etherHistoryMulticastPkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The number of good packets received during
sampling interval that were directed to
multicast address. Note that this number does
include packets addressed to the broadcast address."
::= { etherHistoryEntry 8 }
Waldbusser Standards Track [Page 31]
RFC 2819 Remote Network Monitoring MIB May 2000
etherHistoryCRCAlignErrors OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The number of packets received during
sampling interval that had a length (
framing bits but including FCS octets)
64 and 1518 octets, inclusive, but had either a bad
Check Sequence (FCS) with an integral number of
(FCS Error) or a bad FCS with a non-integral
of octets (Alignment Error)."
::= { etherHistoryEntry 9 }
etherHistoryUndersizePkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The number of packets received during
sampling interval that were less than 64
long (excluding framing bits but including
octets) and were otherwise well formed."
::= { etherHistoryEntry 10 }
etherHistoryOversizePkts OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The number of packets received during
sampling interval that were longer than 1518
octets (excluding framing bits but
FCS octets) but were otherwise well formed."
::= { etherHistoryEntry 11 }
etherHistoryFragments OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The total number of packets received during
sampling interval that were less than 64 octets
length (excluding framing bits but including
Waldbusser Standards Track [Page 32]
RFC 2819 Remote Network Monitoring MIB May 2000
octets) had either a bad Frame Check Sequence (FCS
with an integral number of octets (FCS Error) or a
FCS with a non-integral number of octets (
Error).
Note that it is entirely normal for etherHistoryFragments
increment. This is because it counts both runts (which
normal occurrences due to collisions) and noise hits."
::= { etherHistoryEntry 12 }
etherHistoryJabbers OBJECT-
SYNTAX Counter32
UNITS "Packets
MAX-ACCESS read-
STATUS
"The number of packets received during
sampling interval that were longer than 1518
(excluding framing bits but including FCS octets),
and had either a bad Frame Check Sequence (FCS
with an integral number of octets (FCS Error)
a bad FCS with a non-integral number of
(Alignment Error).
Note that this definition of jabber is
than the definition in IEEE-802.3 section 8.2.1.5
(10BASE5) and section 10.3.1.4 (10BASE2).
documents define jabber as the condition where
packet exceeds 20 ms. The allowed range to
jabber is between 20 ms and 150 ms."
::= { etherHistoryEntry 13 }
etherHistoryCollisions OBJECT-
SYNTAX Counter32
UNITS "Collisions
MAX-ACCESS read-
STATUS
"The best estimate of the total number of
on this Ethernet segment during this
interval
The value returned will depend on the location of
RMON probe. Section 8.2.1.3 (10BASE-5) and
10.3.1.3 (10BASE-2) of IEEE standard 802.3 states that
station must detect a collision, in the receive mode,
three or more stations are transmitting simultaneously.
repeater port must detect a collision when two or
Waldbusser Standards Track [Page 33]
RFC 2819 Remote Network Monitoring MIB May 2000
stations are transmitting simultaneously. Thus a
placed on a repeater port could record more
than a probe connected to a station on the same
would
Probe location plays a much smaller role when
10BASE-T. 14.2.1.4 (10BASE-T) of IEEE standard 802.3
defines a collision as the simultaneous presence of
on the DO and RD circuits (transmitting and
at the same time). A 10BASE-T station can only
collisions when it is transmitting. Thus probes placed
a station and a repeater, should report the same number
collisions
Note also that an RMON probe inside a repeater
ideally report collisions between the repeater and one
more other hosts (transmit collisions as defined by
802.3k) plus receiver collisions observed on any
segments to which the repeater is connected."
::= { etherHistoryEntry 14 }
etherHistoryUtilization OBJECT-
SYNTAX Integer32 (0..10000)
MAX-ACCESS read-
STATUS
"The best estimate of the mean physical
network utilization on this interface during
sampling interval, in hundredths of a percent."
::= { etherHistoryEntry 15 }
-- The Alarm
-- Implementation of the Alarm group is optional. The Alarm
-- requires the implementation of the Event group
-- Consult the MODULE-COMPLIANCE macro for the
-- conformance information for this MIB
--
-- The Alarm group periodically takes statistical samples
-- variables in the probe and compares them to thresholds that
-- been configured. The alarm table stores
-- entries that each define a variable, polling period,
-- threshold parameters. If a sample is found to cross
-- threshold values, an event is generated. Only variables
-- resolve to an ASN.1 primitive type of INTEGER (INTEGER, Integer32,
-- Counter32, Counter64, Gauge32, or TimeTicks) may be monitored
-- this way
--
Waldbusser 