As per Relevance of the word associated, we have this rfc below:
Network Working Group S.
Request for Comments: 1757 Carnegie Mellon
Obsoletes: 1271 February 1995
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
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
Table of
1. The Network Management Framework ...................... 2
2. Overview .............................................. 3
2.1 Remote Network Management Goals ...................... 3
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 .................................... 6
2.3.5 The Host Group ..................................... 6
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 ........................... 7
2.3.10 The Event Group ................................... 7
3. Control of Remote Network Monitoring Devices .......... 7
3.1 Resource Sharing Among Multiple Management Stations .. 8
3.2 Row Addition Among Multiple Management Stations ...... 10
4. Conventions ........................................... 11
5. Definitions ........................................... 11
6. Acknowledgments ....................................... 89
7. References ............................................ 89
8. Security Considerations ............................... 90
Waldbusser [Page 1]
RFC 1757 Remote Network Monitoring MIB February 1995
9. Author's Address ...................................... 90
10. Appendix: Changes from RFC 1271 ...................... 91
1. The Network Management
The Internet-standard Network Management Framework consists of
components. They are
STD 16, RFC 1155 [1] which defines the SMI, the mechanisms
for describing and naming objects for the purpose of management
STD 16, RFC 1212 [2] defines a more concise description mechanism
which is wholly consistent with the SMI
STD 17, RFC 1213 [3] which defines MIB-II, the core set of
objects for the Internet suite of protocols
STD 15, RFC 1157 [4] which defines the SNMP, the protocol used
network access to managed objects
The Framework permits new objects to be defined for the purpose
experimentation and evaluation
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Within a given MIB module
objects are defined using RFC 1212's OBJECT-TYPE macro. At
minimum, each object has a name, a syntax, an access-level, and
implementation-status
The name is an object identifier, an administratively assigned name
which specifies an object type. The object type together with
object instance serves to uniquely identify a specific
of the object. For human convenience, we often use a textual string
termed the object descriptor, to also refer to the object type
The syntax of an object type defines the abstract data
corresponding to that object type. The ASN.1[5] language is used
this purpose. However, RFC 1155 purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly
for simplicity
The access-level of an object type defines whether it makes "
sense" to read and/or write the value of an instance of the
type. (This access-level is independent of any
authorization policy.)
The implementation-status of an object type indicates whether
object is mandatory, optional, obsolete, or deprecated
Waldbusser [Page 2]
RFC 1757 Remote Network Monitoring MIB February 1995
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
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
such as Token Ring and FDDI
2.1. Remote Network Management
o Offline
There are sometimes conditions when a
station will not be in constant contact with
remote monitoring devices. This is sometimes
design in an attempt to lower communications
(especially when communicating over a WAN
dialup link), or by accident as network
affect the communications between the
station and the probe
For this reason, this MIB allows a probe to
configured to perform diagnostics and to
statistics continuously, even when communication
the management station may not be possible
efficient. The probe may then attempt to
the management station when an exceptional
occurs. Thus, even in circumstances
Waldbusser [Page 3]
RFC 1757 Remote Network Monitoring MIB February 1995
communication between management station and probe
not continuous, fault, performance, and
information may be continuously accumulated
communicated to the management station
and efficiently
o Proactive
Given the resources available on the monitor,
is potentially helpful for it continuously to
diagnostics and to log network performance.
monitor is always available at the onset of
failure. It can notify the management station of
failure and can store historical
information about the failure. This
information can be played back by the
station in an attempt to perform further
into the cause of the problem
o Problem Detection and
The monitor can be configured to
conditions, most notably error conditions,
continuously to check for them. When one of
conditions occurs, the event may be logged,
management stations may be notified in a number
ways
o Value Added
Because a remote monitoring device represents
network resource dedicated exclusively to
management functions, and because it is
directly on the monitored portion of the network,
remote network monitoring device has the
to add significant value to the data it collects
For instance, by highlighting those hosts on
network that generate the most traffic or errors,
probe can give the management station precisely
information it needs to solve a class of problems
o Multiple
An organization may have multiple management
for different units of the organization, for
functions (e.g. engineering and operations), and in
attempt to provide disaster recovery.
environments with multiple management stations
common, the remote network monitoring device has
deal with more than own management station
potentially using its resources concurrently
Waldbusser [Page 4]
RFC 1757 Remote Network Monitoring MIB February 1995
2.2. Textual
Two new data types are introduced as a textual convention in this
document. These textual conventions enhance the readability of
specification and can ease comparison with other specifications
appropriate. It should be noted that the introduction of the
textual conventions has no effect on either the syntax nor
semantics of any managed objects. The use of these is merely
artifact of the explanatory method used. Objects defined in terms
one of these methods are always encoded by means of the rules
define the primitive type. Hence, no changes to the SMI or the
are necessary to accommodate these textual conventions which
adopted merely for the convenience of readers and writers in
of the elusive goal of clear, concise, and unambiguous MIB documents
The new data types are: OwnerString and EntryStatus
2.3. Structure of
The objects are arranged into the following groups
- ethernet
- history
- ethernet
-
-
-
-
-
- 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
Waldbusser [Page 5]
RFC 1757 Remote Network Monitoring MIB February 1995
All groups in this MIB are optional. Implementations of this
must also implement the system and interfaces group of MIB-II [6].
MIB-II may also mandate the implementation of additional groups
These groups are defined to provide a means of assigning
identifiers, and to provide a method for managed agents to know
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. In the future other
will be defined for other media types including Token Ring and FDDI
These groups should follow the same model as the ethernet
group
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. In the future, other groups
be defined for other media types including Token Ring and FDDI
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
Waldbusser [Page 6]
RFC 1757 Remote Network Monitoring MIB February 1995
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
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
Waldbusser [Page 7]
RFC 1757 Remote Network Monitoring MIB February 1995
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
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
resources that together would exceed the capability
the device
o A management station uses a significant amount
resources for a long period of time
o A management station uses resources and then crashes
forgetting to free the resources so others
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
and no longer needs
o A network operator can find the management station
owns the resource and negotiate for it to be freed
Waldbusser [Page 8]
RFC 1757 Remote Network Monitoring MIB February 1995
o A network operator may decide to unilaterally
resources another network operator has reserved
o Upon initialization, a management station may
resources it had reserved in the past. With
information it may free the resources if it no
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
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
Waldbusser [Page 9]
RFC 1757 Remote Network Monitoring MIB February 1995
discretion
3.2. Row Addition Among Multiple Management
The addition of new rows is achieved using the method described
RFC 1212 [9]. 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
to 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
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 will 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
Waldbusser [Page 10]
RFC 1757 Remote Network Monitoring MIB February 1995
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
5.
RMON-MIB DEFINITIONS ::=
Counter FROM RFC1155-
DisplayString FROM RFC1158-
mib-2 FROM RFC1213-
OBJECT-TYPE FROM RFC-1212
TRAP-TYPE FROM RFC-1215;
-- Remote Network Monitoring
rmon OBJECT IDENTIFIER ::= { mib-2 16 }
-- textual
OwnerString ::=
-- This data type is used to model an
-- assigned name of the owner of a resource.
-- information is taken from the NVT ASCII
-- set. It is suggested that this name contain one
Waldbusser [Page 11]
RFC 1757 Remote Network Monitoring MIB February 1995
-- more of the following: IP address, management
-- name, network manager's name, location, or
-- 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 cooperating managers
-- they realize no access control function with
-- to uncooperative parties
--
-- By convention, objects with this syntax are declared
--
--
-- SIZE (0..127)
EntryStatus ::=
{ valid(1),
createRequest(2),
underCreation(3),
invalid(4)
}
-- 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
-- corresponds 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.
Waldbusser [Page 12]
RFC 1757 Remote Network Monitoring MIB February 1995
-- the creation of these default objects is entirely
-- the option of the agent, the manager must not
-- that any will be created, but may make use of any
-- are created. Immediately after completing the
-- operation, the agent must set this object
-- underCreation(3).
--
-- When in the underCreation(3) state, an entry
-- allowed to exist in a possibly incomplete,
-- inconsistent state, usually to allow it to
-- modified in mutiple PDUs. When in this state,
-- entry is not fully active. Entries shall exist
-- the underCreation(3) state until the
-- station is finished configuring the entry and
-- this object to valid(1) or aborts, setting
-- object to invalid(4). If the agent determines
-- an entry has been in the underCreation(3) state
-- an abnormally long time, it may decide that
-- management station has crashed. If the agent
-- this decision, it may set this object to invalid(4)
-- to reclaim the entry. A prudent agent
-- understand that the management station may need
-- wait for human input and will allow for
-- possibility in its determination of this
-- 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
-- entry in the following ways
--
-- create
-- To: valid Request Creation
-- 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
-- state from the createRequest state to any
Waldbusser [Page 13]
RFC 1757 Remote Network Monitoring MIB February 1995
-- state because the manager will never find
-- variable in that state. The nonExistent state
-- not a value of the enumeration, rather it means
-- the entryStatus variable does not exist at all
--
-- An agent may allow an entryStatus variable to
-- state in additional ways, so long as the
-- of the states are followed. This allowance is
-- to ease the implementation of the agent and is
-- despite the fact that managers should
-- excercise these additional state transitions
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 }
-- The Ethernet Statistics
--
-- Implementation of the Ethernet Statistics group
-- optional
--
-- The ethernet statistics group contains
-- measured by the probe for each monitored interface
-- this device. These statistics take the form of
-- running counters that start from zero when a valid
-- is created
--
-- This group currently has statistics defined only
-- Ethernet interfaces. Each etherStatsEntry
-- statistics for one Ethernet interface. The probe
-- create one etherStats entry for each monitored
-- interface on the device
etherStatsTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"A list of Ethernet statistics entries."
::= { statistics 1 }
Waldbusser [Page 14]
RFC 1757 Remote Network Monitoring MIB February 1995
etherStatsEntry OBJECT-
SYNTAX
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 INTEGER (1..65535),
etherStatsDataSource OBJECT IDENTIFIER
etherStatsDropEvents Counter
etherStatsOctets Counter
etherStatsPkts Counter
etherStatsBroadcastPkts Counter
etherStatsMulticastPkts Counter
etherStatsCRCAlignErrors Counter
etherStatsUndersizePkts Counter
etherStatsOversizePkts Counter
etherStatsFragments Counter
etherStatsJabbers Counter
etherStatsCollisions Counter
etherStatsPkts64Octets Counter
etherStatsPkts65to127Octets Counter
etherStatsPkts128to255Octets Counter
etherStatsPkts256to511Octets Counter
etherStatsPkts512to1023Octets Counter
etherStatsPkts1024to1518Octets Counter
etherStatsOwner OwnerString
etherStatsStatus
}
etherStatsIndex OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS
"The value of this object uniquely identifies
etherStats entry."
::= { etherStatsEntry 1 }
etherStatsDataSource OBJECT-
SYNTAX OBJECT
ACCESS read-
STATUS
Waldbusser [Page 15]
RFC 1757 Remote Network Monitoring MIB February 1995
"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,
object shall identify the instance of the
object, defined in RFC 1213 and RFC 1573 [4,6],
the desired interface. For example, if an
were to receive data from interface #1, this
would be set to ifIndex.1.
The statistics in this group reflect all
on the local network segment attached to
identified interface
An agent may or may not be able to tell
fundamental changes to the media of the
have occurred and necessitate an invalidation
this entry. For example, a hot-pluggable
card could be pulled out and replaced by
token-ring card. In such a case, if the agent
such knowledge of the change, it is recommended
it invalidate this entry
This object may not be modified if the
etherStatsStatus object is equal to valid(1)."
::= { etherStatsEntry 2 }
etherStatsDropEvents OBJECT-
SYNTAX
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
ACCESS read-
STATUS
"The total number of octets of data (
those in bad packets) received on
network (excluding framing bits but
Waldbusser [Page 16]
RFC 1757 Remote Network Monitoring MIB February 1995
FCS octets).
This object can be used as a reasonable estimate
ethernet utilization. If greater precision
desired, the etherStatsPkts and
objects should be sampled before and after a
interval. The differences in the sampled values
Pkts and Octets, respectively, and the number
seconds in the interval is Interval. These
are used to calculate the Utilization as follows
Pkts * (9.6 + 6.4) + (Octets * .8)
Utilization = -------------------------------------
Interval * 10,000
The result of this equation is the value
which is the percent utilization of the
segment on a scale of 0 to 100 percent."
::= { etherStatsEntry 4 }
etherStatsPkts OBJECT-
SYNTAX
ACCESS read-
STATUS
"The total number of packets (including bad packets
broadcast packets, and multicast packets) received."
::= { etherStatsEntry 5 }
etherStatsBroadcastPkts OBJECT-
SYNTAX
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
ACCESS read-
STATUS
"The total number of good packets received that
directed to a multicast address. Note that
number does not include packets directed to
broadcast address."
Waldbusser [Page 17]
RFC 1757 Remote Network Monitoring MIB February 1995
::= { etherStatsEntry 7 }
etherStatsCRCAlignErrors OBJECT-
SYNTAX
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 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
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
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
ACCESS read-
STATUS
"The total number of packets received that were
than 64 octets in length (excluding framing bits
including FCS octets) and had either a bad
Check Sequence (FCS) with an integral number
octets (FCS Error) or a bad FCS with a non-
Waldbusser [Page 18]
RFC 1757 Remote Network Monitoring MIB February 1995
number of octets (Alignment Error).
Note that it is entirely normal
etherStatsFragments to increment. This is
it counts both runts (which are normal
due to collisions) and noise hits."
::= { etherStatsEntry 11 }
etherStatsJabbers OBJECT-
SYNTAX
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
non-integral 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
ACCESS read-
STATUS
"The best estimate of the total number of
on this Ethernet segment
The value returned will depend on the location
the RMON probe. Section 8.2.1.3 (10BASE-5)
section 10.3.1.3 (10BASE-2) of IEEE standard 802.3
states that a station must detect a collision,
the receive mode, if three or more stations
transmitting simultaneously. A repeater port
detect a collision when two or more stations
transmitting simultaneously. Thus a probe placed
a repeater port could record more collisions than
probe connected to a station on the same
would
Waldbusser [Page 19]
RFC 1757 Remote Network Monitoring MIB February 1995
Probe location plays a much smaller role
considering 10BASE-T. 14.2.1.4 (10BASE-T) of
standard 802.3 defines a collision as
simultaneous presence of signals on the DO and
circuits (transmitting and receiving at the
time). A 10BASE-T station can only
collisions when it is transmitting. Thus
placed on a station and a repeater, should
the same number of collisions
Note also that an RMON probe inside a
should ideally report collisions between
repeater and one or more other hosts (
collisions as defined by IEEE 802.3k) plus
collisions observed on any coax segments to
the repeater is connected."
::= { etherStatsEntry 13 }
etherStatsPkts64Octets OBJECT-
SYNTAX
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
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
ACCESS read-
STATUS
"The total number of packets (including
packets) received that were
128 and 255 octets in length
(excluding framing bits but including FCS octets)."
Waldbusser [Page 20]
RFC 1757 Remote Network Monitoring MIB February 1995
::= { etherStatsEntry 16 }
etherStatsPkts256to511Octets OBJECT-
SYNTAX
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
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
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
ACCESS read-
STATUS
"The entity that configured this entry and
therefore using the resources assigned to it."
::= { etherStatsEntry 20 }
etherStatsStatus OBJECT-
SYNTAX
ACCESS read-
STATUS
Waldbusser [Page 21]
RFC 1757 Remote Network Monitoring MIB February 1995
"The status of this etherStats entry."
::= { etherStatsEntry 21 }
-- The History Control
-- Implementation of the History Control group is optional
--
-- 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
-- similarly-named counterpart in the etherStatsEntry
-- except that each value here is a cumulative sum during
-- sampling period
--
-- If the probe keeps track of the time of day, it
-- start 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
-- a short term and a long term polling period.
-- parameters are 30 seconds for the short term polling
-- and 30 minutes for the long term period
historyControlTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"A list of history control entries."
::= { history 1 }
historyControlEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
Waldbusser [Page 22]
RFC 1757 Remote Network Monitoring MIB February 1995
"A list of parameters that set up a periodic
of statistics. As an example, an instance of
historyControlInterval object might be
historyControlInterval.2"
INDEX { historyControlIndex }
::= { historyControlTable 1 }
HistoryControlEntry ::= SEQUENCE {
historyControlIndex INTEGER (1..65535),
historyControlDataSource OBJECT IDENTIFIER
historyControlBucketsRequested INTEGER (1..65535),
historyControlBucketsGranted INTEGER (1..65535),
historyControlInterval INTEGER (1..3600),
historyControlOwner OwnerString
historyControlStatus
}
historyControlIndex OBJECT-
SYNTAX INTEGER (1..65535)
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
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
a particular interface, this object shall
the instance of the ifIndex object,
in RFC 1213 and RFC 1573 [4,6], for the
interface. For example, if an entry were to
data from interface #1, this object would be
to ifIndex.1.
The statistics in this group reflect all
on the local network segment attached to
Waldbusser [Page 23]
RFC 1757 Remote Network Monitoring MIB February 1995
identified interface
An agent may or may not be able to tell if
changes to the media of the interface have
and necessitate an invalidation of this entry.
example, a hot-pluggable ethernet card could
pulled out and replaced by a token-ring card.
such a case, if the agent has such knowledge of
change, it is recommended that it invalidate
entry
This object may not be modified if the
historyControlStatus object is equal to valid(1)."
::= { historyControlEntry 2 }
historyControlBucketsRequested OBJECT-
SYNTAX INTEGER (1..65535)
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 INTEGER (1..65535)
ACCESS read-
STATUS
"The number of discrete sampling
over which data shall be saved in the part
the media-specific table associated with
historyControlEntry
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
Waldbusser [Page 24]
RFC 1757 Remote Network Monitoring MIB February 1995
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
greater than the current value, the number
associated media- specific entries may be allowed
grow."
::= { historyControlEntry 4 }
historyControlInterval OBJECT-
SYNTAX INTEGER (1..3600)
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
maximum value with no indication, a prudent
will take into account the possibility of
in any of the associated counters. It is
to consider the minimum time in which any
could overflow on a particular media type and
the historyControlInterval object to a value
Waldbusser [Page 25]
RFC 1757 Remote Network Monitoring MIB February 1995
than this interval. This is typically
important for the 'octets' counter in
media-specific table. For example, on an
network, the etherHistoryOctets counter
overflow 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
ACCESS read-
STATUS
"The entity that configured this entry and
therefore using the resources assigned to it."
::= { historyControlEntry 6 }
historyControlStatus OBJECT-
SYNTAX
ACCESS read-
STATUS
"The status of this historyControl entry
Each instance of the media-specific table
with this historyControlEntry will be deleted by
agent if this historyControlEntry is not equal
valid(1)."
::= { historyControlEntry 7 }
-- The Ethernet History
-- Implementation of the Ethernet History group is optional
--
-- The Ethernet History group records
-- statistical samples from a network and stores
-- for later retrieval. Once samples are taken,
-- data is stored in an entry in a media-
-- table. Each such entry defines one sample, and
-- associated with the historyControlEntry that
-- the sample to be taken. This group defines
-- etherHistoryTable, for Ethernet networks
--
Waldbusser [Page 26]
RFC 1757 Remote Network Monitoring MIB February 1995
etherHistoryTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"A list of Ethernet history entries."
::= { history 2 }
etherHistoryEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"An historical sample of Ethernet statistics on
particular Ethernet interface. This sample
associated with the historyControlEntry which set
the parameters for a regular collection of
samples. As an example, an instance of
etherHistoryPkts object might be
etherHistoryPkts.2.89"
INDEX { etherHistoryIndex , etherHistorySampleIndex }
::= { etherHistoryTable 1 }
EtherHistoryEntry ::= SEQUENCE {
etherHistoryIndex INTEGER (1..65535),
etherHistorySampleIndex INTEGER (1..2147483647),
etherHistoryIntervalStart TimeTicks
etherHistoryDropEvents Counter
etherHistoryOctets Counter
etherHistoryPkts Counter
etherHistoryBroadcastPkts Counter
etherHistoryMulticastPkts Counter
etherHistoryCRCAlignErrors Counter
etherHistoryUndersizePkts Counter
etherHistoryOversizePkts Counter
etherHistoryFragments Counter
etherHistoryJabbers Counter
etherHistoryCollisions Counter
etherHistoryUtilization INTEGER (0..10000)
}
etherHistoryIndex OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS
"The history of which this entry is a part.
history identified by a particular value of
Waldbusser [Page 27]
RFC 1757 Remote Network Monitoring MIB February 1995
index is the same history as
by the same value of historyControlIndex."
::= { etherHistoryEntry 1 }
etherHistorySampleIndex OBJECT-
SYNTAX INTEGER (1..2147483647)
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
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
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
detected."
::= { etherHistoryEntry 4 }
etherHistoryOctets OBJECT-
Waldbusser [Page 28]
RFC 1757 Remote Network Monitoring MIB February 1995
SYNTAX
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
ACCESS read-
STATUS
"The number of packets (including bad packets
received during this sampling interval."
::= { etherHistoryEntry 6 }
etherHistoryBroadcastPkts OBJECT-
SYNTAX
ACCESS read-
STATUS
"The number of good packets received during
sampling interval that were directed to
broadcast address."
::= { etherHistoryEntry 7 }
etherHistoryMulticastPkts OBJECT-
SYNTAX
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 }
etherHistoryCRCAlignErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"The number of packets received during this
interval that had a length (excluding framing
but including FCS octets) between 64 and 1518
Waldbusser [Page 29]
RFC 1757 Remote Network Monitoring MIB February 1995
octets, inclusive, but had either a bad Frame
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
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
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
ACCESS read-
STATUS
"The total number of packets received during
sampling interval that were less than 64 octets
length (excluding framing bits but including
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
etherHistoryFragments to increment. This is
it counts both runts (which are normal
due to collisions) and noise hits."
::= { etherHistoryEntry 12 }
etherHistoryJabbers OBJECT-
Waldbusser [Page 30]
RFC 1757 Remote Network Monitoring MIB February 1995
SYNTAX
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
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
the RMON probe. Section 8.2.1.3 (10BASE-5)
section 10.3.1.3 (10BASE-2) of IEEE standard 802.3
states that a station must detect a collision,
the receive mode, if three or more stations
transmitting simultaneously. A repeater port
detect a collision when two or more stations
transmitting simultaneously. Thus a probe placed
a repeater port could record more collisions than
probe connected to a station on the same
would
Probe location plays a much smaller role
considering 10BASE-T. 14.2.1.4 (10BASE-T) of
standard 802.3 defines a collision as
simultaneous presence of signals on the DO and
circuits (transmitting and receiving at the
time). A 10BASE-T station can only
collisions when it is transmitting. Thus
Waldbusser [Page 31]
RFC 1757 Remote Network Monitoring MIB February 1995
placed on a station and a repeater, should
the same number of collisions
Note also that an RMON probe inside a
should ideally report collisions between
repeater and one or more other hosts (
collisions as defined by IEEE 802.3k) plus
collisions observed on any coax segments to
the repeater is connected."
::= { etherHistoryEntry 14 }
etherHistoryUtilization OBJECT-
SYNTAX INTEGER (0..10000)
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 Group requires the implementation of the
-- group
--
-- The Alarm group periodically
-- statistical samples from variables in the probe
-- compares them to thresholds that have
-- configured. The alarm table stores
-- entries that each define a variable, polling period
-- and threshold parameters. If a sample is found
-- cross the threshold values, an event is generated
-- Only variables that resolve to an ASN.1
-- type of INTEGER (INTEGER, Counter, Gauge,
-- TimeTicks) may be monitored in this way
--
-- This function has a hysteresis mechanism to
-- the generation of events. This mechanism
-- one event as a threshold is crossed in
-- appropriate direction. No more events are
-- for that threshold until the opposite threshold
-- crossed
--
-- In the case of a sampling a deltaValue, a probe
Waldbusser [Page 32]
RFC 1757 Remote Network Monitoring MIB February 1995
-- implement this mechanism with more precision if
-- takes a delta sample twice per period, each
-- comparing the sum of the latest two samples to
-- threshold. This allows the detection of
-- crossings that span the sampling boundary.
-- that this does not require any special
-- of the threshold value. It is suggested that
-- implement this more precise 