As per Relevance of the word monitoring, we have this rfc below:
Network Working Group S.
Request for Comments: 2021
Category: Standards Track January 1997
Remote Network Monitoring Management Information
Version 2
using SMIv
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 .............................................. 2
2.1 Remote Network Management Goals ..................... 3
2.2 Structure of MIB .................................... 5
3 Control of Remote Network Monitoring Devices .......... 6
3.1 Resource Sharing Among Multiple Management Sta
tions .............................................. 7
3.2 Row Addition Among Multiple Management Stations ..... 9
4 Conventions ........................................... 10
5 RMON 2 Conventions .................................... 10
5.1 Usage of the term Application Level ................. 10
5.2 Protocol Directory and Limited Extensibility ........ 11
5.3 Errors in packets ................................... 11
6 Definitions ........................................... 12
7 Security Considerations ............................... 122
8 Appendix - TimeFilter Implementation Notes ........... 123
9 Acknowledgments ...................................... 129
10 References ........................................... 129
11 Author's Address...................................... 130
Waldbusser Standards Track [Page 1]
RFC 2021 Remote Network Monitoring MIB January 1997
1. The Network Management
The Internet-standard Network Management Framework consists of
components. They are
RFC 1902 [1] which defines the SMI, the mechanisms used
describing and naming objects for the purpose of management
RFC 1213, STD 17, [3] which defines MIB-II, the core set
managed objects for the Internet suite of protocols
RFC 1905 [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 the SMI's OBJECT-TYPE macro. At a 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 [6] language is
for this purpose. However, RFC 1902 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
2.
This document continues the architecture created in the RMON MIB [
1757] by providing a major feature upgrade, primarily by
RMON analysis up to the application layer
Waldbusser Standards Track [Page 2]
RFC 2021 Remote Network Monitoring MIB January 1997
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
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
communication between management station and probe
not continuous, fault, performance, and
information may be continuously accumulated
communicated to the management station
and efficiently
Waldbusser Standards Track [Page 3]
RFC 2021 Remote Network Monitoring MIB January 1997
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 Standards Track [Page 4]
RFC 2021 Remote Network Monitoring MIB January 1997
2.2. Structure of
The objects are arranged into the following groups
- protocol
- protocol
- address
- network layer
- network layer
- application layer
- application layer
- user
- probe
These groups are the basic units of conformance. If a
monitoring device implements a group, then it must implement
objects in that group. For example, a managed agent that
the network layer matrix group must implement the nlMatrixSDTable
the nlMatrixDSTable
Implementations of this MIB must also implement the system
interfaces group of MIB-II [3]. MIB-II may also mandate
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
This document also contains enhancements to tables defined in
RMON MIB [RFC 1757]. These enhancements include
1) Adding the DroppedFrames and
conventions to each table defined in the RMON MIB
2) Augmenting the RMON filter table with a
that allows filtering based on an offset from
beginning of a particular protocol, even if
protocol headers are variable length
Waldbusser Standards Track [Page 5]
RFC 2021 Remote Network Monitoring MIB January 1997
3) Augmenting the RMON filter and capture status
with additional bits for WAN media and generic media
These bits are defined here as
Bit
6 For WAN media, this bit is set for
coming from one direction and cleared
packets coming from the other direction
It is an implementation specific
as to which bit is assigned to
direction, but it must be consistent
all packets received by the agent, and
the agent knows which end of the link
"local" and which end is "network", the
should be set for packets from the "local
side and should be cleared for packets
the "network" side
7 For any media, this bit is set for any
with a physical layer error. This bit may
set in addition to other media-specific
that denote the same condition
8 For any media, this bit is set for any
that is too short for the media. This bit
be set in addition to other media-
bits that denote the same condition
9 For any media, this bit is set for any
that is too long for the media. This bit
be set in addition to other media-specific
that denote the same condition
These enhancements are implemented by RMON-2 probes that
implement RMON and do not add any requirements to probes that
compliant to just RMON
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
Waldbusser Standards Track [Page 6]
RFC 2021 Remote Network Monitoring MIB January 1997
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 not active. Thus, the method for
these parameters is to de-activate the entry, perform the SNMP
operations to modify the entry, and then re-activate the entry
Deleting the control entry causes the deletion of any associated
entries, which 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
The OwnerString mechanism is provided for each management
initiated function in this MIB to avoid these conflicts and to
resolve them when they occur. Each function has a label
the 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
o A network operator may decide to unilaterally
resources another network operator has reserved
Waldbusser Standards Track [Page 7]
RFC 2021 Remote Network Monitoring MIB January 1997
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
discretion
Waldbusser Standards Track [Page 8]
RFC 2021 Remote Network Monitoring MIB January 1997
3.2. Row Addition Among Multiple Management
The addition of new rows is achieved using the RowStatus
described in RFC 1903 [2]. In this MIB, rows are often added to
table in order to configure a function. This configuration
involves parameters that control the operation of the function.
agent must check these parameters to make sure they are
given 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 row status
to active
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
In the RMON MIB [RFC 1757], the EntryStatus textual convention
introduced to provide this mutual exclusion function. Since then
this function was added to the SNMP framework as the
textual convention. The RowStatus textual convention is used for
definition of all new tables
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
Waldbusser Standards Track [Page 9]
RFC 2021 Remote Network Monitoring MIB January 1997
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
5. RMON 2
The following practices and conventions are introduced in the RMON 2
MIB
5.1. Usage of the term Application
There are many cases in this MIB where the term Application Level
used to describe a class of protocols or a capability. This does
typically mean a protocol that is an OSI Layer 7 protocol. Rather
it is used to identify a class of protocols that is not limited
MAC-layer and network-layer protocols, but can also
transport, session, presentation, and application-layer protocols
Waldbusser Standards Track [Page 10]
RFC 2021 Remote Network Monitoring MIB January 1997
5.2. Protocol Directory and Limited
Every RMON 2 implementation will have the capability to parse
types of packets and identify their protocol type at multiple levels
The protocol directory presents an inventory of those protocol
the probe is capable of monitoring, and allows the addition
deletion, and configuration of protocol types in this list
One concept deserves special attention: the "limited extensibility
of the protocol directory table. The RMON 2 model is that
are detected by static software that has been written
implementation time. Therefore, as a matter of configuration,
implementation does not have the ability to suddenly learn how
parse new packet types. However, an implementation may be
such that the software knows where the demultiplexing field is for
particular protocol, and can be written in such a way that
decoding of the next layer up is table-driven. This works when
code has been written to accomodate it and can be extended no
than one level higher. This extensibility is called "
extensibility" to highlight these limitations. However, this can
a very useful tool
For example, suppose that an implementation has C code
understands how to decode IP packets on any of several
encapsulations, and also knows how to interpret the IP protocol
to recognize UDP packets and how to decode the UDP port
fields. That implementation may be table- driven so that among
many different UDP port numbers possible, it is configured
recognize 161 as SNMP, port 53 as DNS, and port 69 as TFTP.
limited extensibility of the protocol directory table would allow
SNMP operation to create an entry that would create an
table mapping for UDP that would recognize UDP port 123 as NTP
begin counting such packets
This limited extensibility is an option that an implementation
choose to allow or disallow for any protocol that has
protocols
5.3. Errors in
Packets with link-level errors are not counted anywhere in this
because most variables in this MIB requires the decoding of
contents of the packet, which is meaningless if there is a link-
error
Packets in which protocol errors are detected are counted for
protocols below the layer in which the error was encountered.
implication of this is that packets in which errors are detected
Waldbusser Standards Track [Page 11]
RFC 2021 Remote Network Monitoring MIB January 1997
the network-layer are not counted anywhere in this MIB, while
with errors detected at the transport layer may have network-
statistics counted
6.
RMON2-MIB DEFINITIONS ::=
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32,
Gauge32, IpAddress, TimeTicks FROM SNMPv2-
TEXTUAL-CONVENTION, RowStatus, DisplayString,
FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-
mib-2, ifIndex FROM RFC1213-
OwnerString, statistics, history, hosts
matrix, filter, etherStatsEntry, historyControlEntry
hostControlEntry, matrixControlEntry, filterEntry
channelEntry FROM RMON-
tokenRing, tokenRingMLStatsEntry, tokenRingPStatsEntry
ringStationControlEntry,
FROM TOKEN-RING-RMON-MIB
-- Remote Network Monitoring
rmon MODULE-
LAST-UPDATED "9605270000Z
ORGANIZATION "IETF RMON MIB Working Group
CONTACT-
"Steve Waldbusser (WG Editor
Postal: International Network
650 Castro Street, Suite 260
Mountain View, CA 94041
Phone: +1 415 254 4251
Email: waldbusser@ins.
Andy Bierman (WG Chair
Phone: +1 805 648 2028
Email: abierman@west.net
"The MIB module for managing remote
device implementations. This MIB
augments the original RMON MIB as specified
RFC 1757."
::= { mib-2 16 }
-- { rmon 1 } through { rmon 10 } are defined in RMON
-- the Token Ring RMON MIB [RFC 1513]
Waldbusser Standards Track [Page 12]
RFC 2021 Remote Network Monitoring MIB January 1997
protocolDir OBJECT IDENTIFIER ::= { rmon 11 }
protocolDist OBJECT IDENTIFIER ::= { rmon 12 }
addressMap OBJECT IDENTIFIER ::= { rmon 13 }
nlHost OBJECT IDENTIFIER ::= { rmon 14 }
nlMatrix OBJECT IDENTIFIER ::= { rmon 15 }
alHost OBJECT IDENTIFIER ::= { rmon 16 }
alMatrix OBJECT IDENTIFIER ::= { rmon 17 }
usrHistory OBJECT IDENTIFIER ::= { rmon 18 }
probeConfig OBJECT IDENTIFIER ::= { rmon 19 }
rmonConformance OBJECT IDENTIFIER ::= { rmon 20 }
-- Textual
ZeroBasedCounter32 ::= TEXTUAL-
STATUS
"This TC describes an object which counts events with
following semantics: objects of this type will be set
zero(0) on creation and will thereafter count
events, wrapping back to zero(0) when the value 2^32
reached
Provided that an application discovers the new object
the minimum time to wrap it can use the initial value as
delta since it last polled the table of which this object
part. It is important for a management station to be aware
this minimum time and the actual time between polls, and
discard data if the actual time is too long or there is
defined minimum time
Typically this TC is used in tables where the INDEX space
constantly changing and/or the TimeFilter mechanism is in use."
SYNTAX Gauge32
LastCreateTime ::= TEXTUAL-
STATUS
"This TC describes an object that stores the last time
entry was created
This can be used for polling applications to determine that
entry has been deleted and re-created between polls,
an otherwise undetectable discontinuity in the data."
SYNTAX
TimeFilter ::= TEXTUAL-
STATUS
Waldbusser Standards Track [Page 13]
RFC 2021 Remote Network Monitoring MIB January 1997
"To be used for the index to a table. Allows an
to download only those rows changed since a particular time
A row is considered changed if the value of any object in
row changes or if the row is created or deleted
When sysUpTime is equal to zero, this table shall be empty
One entry exists for each past value of sysUpTime, except
the whole table is purged should sysUpTime wrap
As this basic row is updated new conceptual rows are
(which still share the now updated object values with
other instances). The number of instances which are
is determined by the value of sysUpTime at which the basic
was last updated. One instance will exist for each value
sysUpTime at the last update time for the row. A
timeMark instance is created for each new sysUpTime value
Each new conceptual row will be associated with the
instance which was created at the value of sysUpTime
which the conceptual row is to be associated
By definition all conceptual rows were updated at or
time zero and so at least one conceptual row (associated
timeMark.0) must exist for each underlying (basic) row
See the appendix for further discussion of this variable
Consider the following fooTable
fooTable ...
INDEX { fooTimeMark, fooIndex }
FooEntry {
fooTimeMark
fooIndex INTEGER
fooCounts
}
Should there be two basic rows in this table (fooIndex == 1,
fooIndex == 2) and row 1 was updated most recently at time 6,
while row 2 was updated most recently at time 8, and both
had been updated on several earlier occasions such that
current values were 5 and 9 respectively then the
fooCounts instances would exist
fooCounts.0.1 5
fooCounts.0.2 9
fooCounts.1.1 5
Waldbusser Standards Track [Page 14]
RFC 2021 Remote Network Monitoring MIB January 1997
fooCounts.1.2 9
fooCounts.2.1 5
fooCounts.2.2 9
fooCounts.3.1 5
fooCounts.3.2 9
fooCounts.4.1 5
fooCounts.4.2 9
fooCounts.5.1 5
fooCounts.5.2 9
fooCounts.6.1 5
fooCounts.6.2 9
fooCounts.7.2 9 -- note that row 1 doesn't exist
fooCounts.8.2 9 -- times 7 and 8"
SYNTAX
DataSource ::= TEXTUAL-
STATUS
"Identifies the source of the data that the
function is configured to analyze. This source can be
interface on this device
In order to identify a particular interface,
object shall identify the instance of the
object, defined in [3,5], for the desired interface
For example, if an entry were to receive data
interface #1, this object would be set to ifIndex.1."
SYNTAX OBJECT
--
-- Protocol Directory
--
-- Lists the inventory of protocols the probe has the capability
-- monitoring and allows the addition, deletion, and configuration
-- entries in this list
protocolDirLastChange OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The value of sysUpTime at the time the protocol
was last modified, either through insertions or deletions
or through modifications of either
protocolDirAddressMapConfig, protocolDirHostConfig,
protocolDirMatrixConfig."
::= { protocolDir 1 }
Waldbusser Standards Track [Page 15]
RFC 2021 Remote Network Monitoring MIB January 1997
protocolDirTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"This table lists the protocols that this agent has
capability to decode and count. There is one entry in
table for each such protocol. These protocols
different network layer, transport layer, and higher-
protocols. The agent should boot up with this
preconfigured with those protocols that it knows about
wishes to monitor. Implementations are strongly encouraged
support protocols higher than the network layer (at least
the protocol distribution group), even for
that don't support the application layer groups."
::= { protocolDir 2 }
protocolDirEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A conceptual row in the protocolDirTable
An example of the indexing of this entry
protocolDirLocalIndex.8.0.0.0.1.0.0.8.0.2.0.0, which is
encoding of a length of 8, followed by 8 subids encoding
protocolDirID of 1.2048, followed by a length of 2 and
2 subids encoding zero-valued parameters."
INDEX { protocolDirID, protocolDirParameters }
::= { protocolDirTable 1 }
ProtocolDirEntry ::= SEQUENCE {
protocolDirID OCTET STRING
protocolDirParameters OCTET STRING
protocolDirLocalIndex Integer32,
protocolDirDescr DisplayString
protocolDirType BITS
protocolDirAddressMapConfig INTEGER
protocolDirHostConfig INTEGER
protocolDirMatrixConfig INTEGER
protocolDirOwner OwnerString
protocolDirStatus
protocolDirID OBJECT-
SYNTAX OCTET
MAX-ACCESS not-
Waldbusser Standards Track [Page 16]
RFC 2021 Remote Network Monitoring MIB January 1997
STATUS
"A unique identifier for a particular protocol.
identifiers will be defined in a manner such that
can often be used as specifications for new protocols - i.e
a tree-structured assignment mechanism that matches
protocol encapsulation `tree' and which has
assignment mechanisms for certain subtrees. See RFC XXX
more details
Despite the algorithmic mechanism, the probe will only
entries in here for those protocols it chooses to collect.
other words, it need not populate this table with all of
possible ethernet protocol types, nor need it create them
the fly when it sees them. Whether or not it does
things is a matter of product definition (cost/benefit
usability), and is up to the designer of the product
If an entry is written to this table with a protocolDirID
the agent doesn't understand, either directly
algorithmically, the SET request will be rejected with
inconsistentName or badValue (for SNMPv1) error."
::= { protocolDirEntry 1 }
protocolDirParameters OBJECT-
SYNTAX OCTET
MAX-ACCESS not-
STATUS
"A set of parameters for the associated protocolDirID
See the associated RMON2 Protocol Identifiers
for a description of the possible parameters.
will be one octet in this string for each sub-identifier
the protocolDirID, and the parameters will appear here in
same order as the associated sub-identifiers appear in
protocolDirID
Every node in the protocolDirID tree has a different,
set of parameters defined (that is, the definition
parameters for a node is optional). The proper
value for each node is included in this string. Note that
inclusion of a parameter value in this string for each node
not optional - what is optional is that a node may have
parameters defined, in which case the parameter field for
node will be zero."
::= { protocolDirEntry 2 }
protocolDirLocalIndex OBJECT-
Waldbusser Standards Track [Page 17]
RFC 2021 Remote Network Monitoring MIB January 1997
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-
STATUS
"The locally arbitrary, but unique identifier
with this protocolDir entry
The value for each supported protocol must remain constant
least from one re-initialization of the entity's
management system to the next re-initialization, except
if a protocol is deleted and re-created, it must be re-
with a new value that has not been used since the
re-initialization
The specific value is meaningful only within a given
entity. A protocolDirLocalIndex must not be re-used until
next agent-restart in the event the protocol directory
is deleted."
::= { protocolDirEntry 3 }
protocolDirDescr OBJECT-
SYNTAX DisplayString (SIZE (1..64))
MAX-ACCESS read-
STATUS
"A textual description of the protocol encapsulation
A probe may choose to describe only a subset of
entire encapsulation (e.g. only the highest layer).
This object is intended for human consumption only
This object may not be modified if the
protocolDirStatus object is equal to active(1)."
::= { protocolDirEntry 4 }
protocolDirType OBJECT-
SYNTAX BITS {
extensible(0),
addressRecognitionCapable(1)
}
MAX-ACCESS read-
STATUS
"This object describes 2 attributes of this
directory entry
The presence or absence of the `extensible' bit
whether or not this protocol directory entry can be
Waldbusser Standards Track [Page 18]
RFC 2021 Remote Network Monitoring MIB January 1997
by the user by creating protocol directory entries which
children of this protocol
An example of an entry that will often allow extensibility
`ip.udp'. The probe may automatically populate some
of this node such as `ip.udp.snmp' and `ip.udp.dns'.
A probe administrator or user may also populate
children via remote SNMP requests that create entries in
table. When a child node is added for a protocol for which
probe has no built in support, extending a parent node (
which the probe does have built in support),
that child node is not extendible. This is termed `
extensibility'.
When a child node is added through this
mechanism, the values of protocolDirLocalIndex
protocolDirType shall be assigned by the agent
The other objects in the entry will be assigned by
manager who is creating the new entry
This object also describes whether or not this agent
recognize addresses for this protocol, should it be a
level protocol. That is, while a probe may be able
recognize packets of a particular network layer protocol
count them, it takes additional logic to be able to
the addresses in this protocol and to populate network
or application layer tables with the addresses in
protocol. If this bit is set, the agent will
network layer addresses for this protoocl and populate
network and application layer host and matrix tables
these protocols
Note that when an entry is created, the agent will
values for the bits that match the capabilities of the
with respect to this protocol. Note that since row
usually exercise the limited extensibility feature,
bits will usually be set to zero."
::= { protocolDirEntry 5 }
protocolDirAddressMapConfig OBJECT-
SYNTAX INTEGER {
notSupported(1),
supportedOff(2),
supportedOn(3)
}
MAX-ACCESS read-
STATUS
Waldbusser Standards Track [Page 19]
RFC 2021 Remote Network Monitoring MIB January 1997
"This object describes and configures the probe's support
address mapping for this protocol. When the probe
entries in this table for all protocols that it understands
it will set the entry to notSupported(1) if it doesn't
the capability to perform address mapping for the protocol
if this protocol is not a network-layer protocol.
an entry is created in this table by a management operation
part of the limited extensibility feature, the probe must
this value to notSupported(1), because limited
of the protocolDirTable does not extend to
addresses of the extended protocols
If the value of this object is notSupported(1), the
will not perform address mapping for this protocol
shall not allow this object to be changed to any other value
If the value of this object is supportedOn(3), the
supports address mapping for this protocol and is
to perform address mapping for this protocol for
addressMappingControlEntries and all interfaces
If the value of this object is supportedOff(2), the
supports address mapping for this protocol but is
to not perform address mapping for this protocol for
addressMappingControlEntries and all interfaces
Whenever this value changes from supportedOn(3)
supportedOff(2), the probe shall delete all related entries
the addressMappingTable."
::= { protocolDirEntry 6 }
protocolDirHostConfig OBJECT-
SYNTAX INTEGER {
notSupported(1),
supportedOff(2),
supportedOn(3)
}
MAX-ACCESS read-
STATUS
"This object describes and configures the probe's support
the network layer and application layer host tables for
protocol. When the probe creates entries in this table
all protocols that it understands, it will set the entry
notSupported(1) if it doesn't have the capability to track
nlHostTable for this protocol or if the alHostTable
implemented but doesn't have the capability to track
protocol. Note that if the alHostTable is implemented,
probe may only support a protocol if it is supported in
the nlHostTable and the alHostTable
Waldbusser Standards Track [Page 20]
RFC 2021 Remote Network Monitoring MIB January 1997
If the associated protocolDirType object has
addressRecognitionCapable bit set, then this is a
layer protocol for which the probe recognizes addresses,
thus the probe will populate the nlHostTable and
with addresses it discovers for this protocol
If the value of this object is notSupported(1), the
will not track the nlHostTable or alHostTable for
protocol and shall not allow this object to be changed to
other value. If the value of this object is supportedOn(3),
the probe supports tracking of the nlHostTable and
for this protocol and is configured to track both
for this protocol for all control entries and all interfaces
If the value of this object is supportedOff(2), the
supports tracking of the nlHostTable and alHostTable for
protocol but is configured to not track these
for any control entries or interfaces
Whenever this value changes from supportedOn(3)
supportedOff(2), the probe shall delete all related entries
the nlHostTable and alHostTable
Note that since each alHostEntry references 2
directory entries, one for the network address and one for
type of the highest protocol recognized, that an entry
only be created in that table if this value is supportedOn(3)
for both protocols."
::= { protocolDirEntry 7 }
protocolDirMatrixConfig OBJECT-
SYNTAX INTEGER {
notSupported(1),
supportedOff(2),
supportedOn(3)
}
MAX-ACCESS read-
STATUS
"This object describes and configures the probe's support
the network layer and application layer matrix tables for
protocol. When the probe creates entries in this table
all protocols that it understands, it will set the entry
notSupported(1) if it doesn't have the capability to track
nlMatrixTables for this protocol or if the alMatrixTables
implemented but don't have the capability to track
protocol. Note that if the alMatrix tables are implemented
the probe may only support a protocol if it is supported
the the both of the nlMatrixTables and both of
alMatrixTables
Waldbusser Standards Track [Page 21]
RFC 2021 Remote Network Monitoring MIB January 1997
If the associated protocolDirType object has
addressRecognitionCapable bit set, then this is a
layer protocol for which the probe recognizes addresses,
thus the probe will populate both of the nlMatrixTables
both of the alMatrixTables with addresses it discovers
this protocol
If the value of this object is notSupported(1), the
will not track either of the nlMatrixTables or
alMatrixTables for this protocol and shall not allow
object to be changed to any other value. If the value of
object is supportedOn(3), the probe supports tracking of
of the nlMatrixTables and (if implemented) both of
alMatrixTables for this protocol and is configured to
these tables for this protocol for all control entries and
interfaces. If the value of this object is supportedOff(2),
the probe supports tracking of both of the nlMatrixTables
(if implemented) both of the alMatrixTables for this
but is configured to not track these tables for
protocol for any control entries or interfaces
Whenever this value changes from supportedOn(3)
supportedOff(2), the probe shall delete all related entries
the nlMatrixTables and the alMatrixTables
Note that since each alMatrixEntry references 2
directory entries, one for the network address and one for
type of the highest protocol recognized, that an entry
only be created in that table if this value is supportedOn(3)
for both protocols."
::= { protocolDirEntry 8 }
protocolDirOwner OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The entity that configured this entry and
therefore using the resources assigned to it."
::= { protocolDirEntry 9 }
protocolDirStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The status of this protocol directory entry
An entry may not exist in the active state unless
Waldbusser Standards Track [Page 22]
RFC 2021 Remote Network Monitoring MIB January 1997
objects in the entry have an appropriate value
If this object is not equal to active(1), all
entries in the nlHostTable, nlMatrixSDTable, nlMatrixDSTable
alHostTable, alMatrixSDTable, and alMatrixDSTable shall
deleted."
::= { protocolDirEntry 10 }
--
-- Protocol Distribution Group (protocolDist
--
-- Collects the relative amounts of octets and packets for
-- different protocols detected on a network segment
-- protocolDistControlTable
--
protocolDistControlTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"Controls the setup of protocol type distribution
tables
Implementations are encouraged to add an entry per
interface upon initialization so that a default
of protocol statistics is available
Rationale
This table controls collection of very basic
for any or all of the protocols detected on a given interface
An NMS can use this table to quickly determine
allocation utilized by different protocols
A media-specific statistics collection could
be configured (e.g. etherStats, trPStats) to easily
total frame, octet, and droppedEvents for the
interface."
::= { protocolDist 1 }
protocolDistControlEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A conceptual row in the protocolDistControlTable
An example of the indexing of this entry
Waldbusser Standards Track [Page 23]
RFC 2021 Remote Network Monitoring MIB January 1997
protocolDistControlDroppedFrames.7"
INDEX { protocolDistControlIndex }
::= { protocolDistControlTable 1 }
ProtocolDistControlEntry ::= SEQUENCE {
protocolDistControlIndex Integer32,
protocolDistControlDataSource DataSource
protocolDistControlDroppedFrames Counter32,
protocolDistControlCreateTime LastCreateTime
protocolDistControlOwner OwnerString
protocolDistControlStatus
protocolDistControlIndex OBJECT-
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-
STATUS
"A unique index for this protocolDistControlEntry."
::= { protocolDistControlEntry 1 }
protocolDistControlDataSource OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The source of data for the this protocol distribution
The statistics in this group reflect all
on the local network segment attached to
identified interface
This object may not be modified if the
protocolDistControlStatus object is equal to active(1)."
::= { protocolDistControlEntry 2 }
protocolDistControlDroppedFrames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of frames which were received by the
and therefore not accounted for in the *StatsDropEvents,
for which the probe chose not to count for this entry
whatever reason. Most often, this event occurs when the
is out of some resources and decides to shed load from
collection
Waldbusser Standards Track [Page 24]
RFC 2021 Remote Network Monitoring MIB January 1997
This count does not include packets that were not
because they had MAC-layer errors
Note that, unlike the dropEvents counter, this number is
exact number of frames dropped."
::= { protocolDistControlEntry 3 }
protocolDistControlCreateTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The value of sysUpTime when this control entry was
activated. This can be used by the management station
ensure that the table has not been deleted and
between polls."
::= { protocolDistControlEntry 4 }
protocolDistControlOwner OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The entity that configured this entry and
therefore using the resources assigned to it."
::= { protocolDistControlEntry 5 }
protocolDistControlStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The status of this row
An entry may not exist in the active state unless
objects in the entry have an appropriate value
If this object is not equal to active(1), all
entries in the protocolDistStatsTable shall be deleted."
::= { protocolDistControlEntry 6 }
-- per interface protocol distribution statistics
protocolDistStatsTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"An entry is made in this table for every protocol in
Waldbusser Standards Track [Page 25]
RFC 2021 Remote Network Monitoring MIB January 1997
protocolDirTable which has been seen in at least one packet
Counters are updated in this table for every protocol
that is encountered when parsing a packet, but no counters
updated for packets with MAC-layer errors
Note that if a protocolDirEntry is deleted, all
entries in this table are removed."
::= { protocolDist 2 }
protocolDistStatsEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A conceptual row in the protocolDistStatsTable
The index is composed of the protocolDistControlIndex of
associated protocolDistControlEntry followed by
protocolDirLocalIndex of the associated protocol that
entry represents. In other words, the index identifies
protocol distribution an entry is a part of as well as
particular protocol that it represents
An example of the indexing of this entry
protocolDistStatsPkts.1.18"
INDEX { protocolDistControlIndex, protocolDirLocalIndex }
::= { protocolDistStatsTable 1 }
ProtocolDistStatsEntry ::= SEQUENCE {
protocolDistStatsPkts ZeroBasedCounter32,
protocolDistStatsOctets ZeroBasedCounter32
protocolDistStatsPkts OBJECT-
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-
STATUS
"The number of packets without errors received of
protocol type. Note that this is the number of link-
packets, so if a single network-layer packet is
into several link-layer frames, this counter is
several times."
::= { protocolDistStatsEntry 1 }
protocolDistStatsOctets OBJECT-
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-
Waldbusser Standards Track [Page 26]
RFC 2021 Remote Network Monitoring MIB January 1997
STATUS
"The number of octets in packets received of this
type since it was added to the
(excluding framing bits but including FCS octets), except
those octets in packets that contained errors
Note this doesn't count just those octets in the
protocol frames, but includes the entire packet that
the protocol."
::= { protocolDistStatsEntry 2 }
--
-- Address Map Group (addressMap
--
-- Lists MAC address to network address bindings discovered by
-- probe and what interface they were last seen on
--
--
addressMapInserts OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of times an address mapping entry has
inserted into the addressMapTable. If an entry is inserted
then deleted, and then inserted, this counter will
incremented by 2.
Note that the table size can be determined by
addressMapDeletes from addressMapInserts."
::= { addressMap 1 }
addressMapDeletes OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of times an address mapping entry has
deleted from the addressMapTable (for any reason).
an entry is deleted, then inserted, and then deleted,
counter will be incremented by 2.
Note that the table size can be determined by
addressMapDeletes from addressMapInserts."
::= { addressMap 2 }
Waldbusser Standards Track [Page 27]
RFC 2021 Remote Network Monitoring MIB January 1997
addressMapMaxDesiredEntries OBJECT-
SYNTAX Integer32 (-1..2147483647)
MAX-ACCESS read-
STATUS
"The maximum number of entries that are desired in
addressMapTable. The probe will not create more
this number of entries in the table, but may choose to
fewer entries in this table for any reason including the
of resources
If this object is set to a value less than the current
of entries, enough entries are chosen in
implementation-dependent manner and deleted so that the
of entries in the table equals the value of this object
If this value is set to -1, the probe may create any
of entries in this table
This object may be used to control how resources are
on the probe for the various RMON functions."
::= { addressMap 3 }
addressMapControlTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"A table to control the collection of network layer address
physical address to interface mappings
Note that this is not like the typical
controlTable and dataTable in which each entry
its own data table. Each entry in this table enables
discovery of addresses on a new interface and the
of address mappings into the central addressMapTable
Implementations are encouraged to add an entry per
interface upon initialization so that a default
of address mappings is available."
::= { addressMap 4 }
addressMapControlEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A conceptual row in the addressMapControlTable
Waldbusser Standards Track [Page 28]
RFC 2021 Remote Network Monitoring MIB January 1997
An example of the indexing of this entry
addressMapControlDroppedFrames.1"
INDEX { addressMapControlIndex }
::= { addressMapControlTable 1 }
AddressMapControlEntry ::= SEQUENCE {
addressMapControlIndex Integer32,
addressMapControlDataSource DataSource
addressMapControlDroppedFrames Counter32,
addressMapControlOwner OwnerString
addressMapControlStatus
addressMapControlIndex OBJECT-
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-
STATUS
"A unique index for this entry in the addressMapControlTable."
::= { addressMapControlEntry 1 }
addressMapControlDataSource OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The source of data for this addressMapControlEntry."
::= { addressMapControlEntry 2 }
addressMapControlDroppedFrames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of frames which were received by the
and therefore not accounted for in the *StatsDropEvents,
for which the probe chose not to count for this entry
whatever reason. Most often, this event occurs when the
is out of some resources and decides to shed load from
collection
This count does not include packets that were not
because they had MAC-layer errors
Note that, unlike the dropEvents counter, this number is
exact number of frames dropped."
::= { addressMapControlEntry 3 }
Waldbusser Standards Track [Page 29]
RFC 2021 Remote Network Monitoring MIB January 1997
addressMapControlOwner OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The entity that configured this entry and
therefore using the resources assigned to it."
::= { addressMapControlEntry 4 }
addressMapControlStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The status of this addressMap control entry
An entry may not exist in the active state unless
objects in the entry have an appropriate value
If this object is not equal to active(1), all
entries in the addressMapTable shall be deleted."
::= { addressMapControlEntry 5 }
addressMapTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"A table of network layer address to physical address
interface mappings
The probe will add entries to this table based on the
MAC and network addresses seen in packets without MAC-
errors. The probe will populate this table for all
in the protocol directory table whose value
protocolDirAddressMapConfig is equal to supportedOn(3),
will delete any entries whose protocolDirEntry is deleted
has a protocolDirAddressMapConfig value of supportedOff(2)."
::= { addressMap 5 }
addressMapEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A conceptual row in the addressMapTable
The protocolDirLocalIndex in the index identifies the
layer protocol of the addressMapNetworkAddress
Waldbusser Standards Track [Page 30]
RFC 2021 Remote Network Monitoring MIB January 1997
An example of the indexing of this entry
addressMapSource.783495.18.4.128.2.6.6.11.1.3.6.1.2.1.2.2.1.1.1"
INDEX { addressMapTimeMark, protocolDirLocalIndex
addressMapNetworkAddress, addressMapSource }
::= { addressMapTable 1 }
AddressMapEntry ::= SEQUENCE {
addressMapTimeMark TimeFilter
addressMapNetworkAddress OCTET STRING
addressMapSource OBJECT IDENTIFIER
addressMapPhysicalAddress OCTET STRING
addressMapLastChange
addressMapTimeMark OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A TimeFilter for this entry. See the TimeFilter
convention to see how this works."
::= { addressMapEntry 1 }
addressMapNetworkAddress OBJECT-
SYNTAX OCTET
MAX-ACCESS not-
STATUS
"The network address for this relation
This is represented as an octet string
specific semantics and length as
by the protocolDirLocalIndex component of
index
For example, if the protocolDirLocalIndex indicates
encapsulation of ip, this object is encoded as a
octet of 4, followed by the 4 octets of the ip address
in network byte order."
::= { addressMapEntry 2 }
addressMapSource OBJECT-
SYNTAX OBJECT
MAX-ACCESS not-
STATUS
"The interface or port on which the associated
address was most recently seen
Waldbusser Standards Track [Page 31]
RFC 2021 Remote Network Monitoring MIB January 1997
If this address mapping was discovered on an interface,
object shall identify the instance of the
object, defined in [3,5], for the desired interface
For example, if an entry were to receive data
interface #1, this object would be set to ifIndex.1.
If this address mapping was discovered on a port,
object shall identify the instance of the
object, defined in [RFC1516], for the desired port
For example, if an entry were to receive data
group #1, port #1, this object would be set
rptrGroupPortIndex.1.1.
Note that while the dataSource associated with this
may only point to index objects, this object may at
point to repeater port objects. This situation occurs
the dataSource points to an interface which is a
attached repeater and the agent has additional
about the source port of traffic seen on that repeater."
::= { addressMapEntry 3 }
addressMapPhysicalAddress OBJECT-
SYNTAX OCTET
MAX-ACCESS read-
STATUS
"The last source physical address on which the
network address was seen. If the protocol of the
network address was encapsulated inside of a network-level
higher protocol, this will be the address of the next-
protocol with the addressRecognitionCapable bit enabled
will be formatted as specified for that protocol."
::= { addressMapEntry 4 }
addressMapLastChange OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The value of sysUpTime at the time this entry was
created or the values of the physical address changed
This can be used to help detect duplicate address problems,
which case this object will be updated frequently."
::= { addressMapEntry 5 }
--
-- Network Layer Host
Waldbusser Standards Track [Page 32]
RFC 2021 Remote Network Monitoring MIB January 1997
--
-- Counts the amount of traffic sent from and to each network
-- discovered by the probe
-- Note that while the hlHostControlTable also has objects
-- control an optional alHostTable, implementation of the alHostTable
-- not required to fully implement this group
hlHostControlTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"A list of higher layer (i.e. non-MAC) host table control entries
These entries will enable the collection of the network
application level host tables indexed by network addresses
Both the network and application level host tables
controlled by this table is so that they will both be
and deleted at the same time, further increasing the ease
which they can be implemented as a single datastore (note
if an implementation stores application layer host records
memory, it can derive network layer host records from them).
Entries in the nlHostTable will be created on behalf of
entry in this table. Additionally, if this probe
the alHostTable, entries in the alHostTable will be created
behalf of each entry in this table
Implementations are encouraged to add an entry per
interface upon initialization so that a default
of host statistics is available."
::= { nlHost 1 }
hlHostControlEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"A conceptual row in the hlHostControlTable
An example of the indexing of this entry
hlHostControlNlDroppedFrames.1"
INDEX { hlHostControlIndex }
::= { hlHostControlTable 1 }
HlHostControlEntry ::= SEQUENCE {
hlHostControlIndex Integer32,
hlHostControlDataSource DataSource
Waldbusser Standards Track [Page 33]
RFC 2021 Remote Network Monitoring MIB January 1997
hlHostControlNlDroppedFrames Counter32,
hlHostControlNlInserts Counter32,
hlHostControlNlDeletes Counter32,
hlHostControlNlMaxDesiredEntries Integer32,
hlHostControlAlDroppedFrames Counter32,
hlHostControlAlInserts Counter32,
hlHostControlAlDeletes Counter32,
hlHostControlAlMaxDesiredEntries Integer32,
hlHostControlOwner OwnerString
hlHostControlStatus
hlHostControlIndex OBJECT-
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-
STATUS
"An index that uniquely identifies an entry in
hlHostControlTable. Each such entry
a function that discovers hosts on a
interface and places statistics about them in
nlHostTable, and optionally in the alHostTable,
behalf of this hlHostControlEntry."
::= { hlHostControlEntry 1 }
hlHostControlDataSource OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The source of data for the associated host tables
The statistics in this group reflect all
on the local network segment attached to
identified interface
This object may not be modified if the
hlHostControlStatus object is equal to active(1)."
::= { hlHostControlEntry 2 }
hlHostControlNlDroppedFrames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of frames which were received by the
and therefore not accounted for in the *StatsDropEvents,
for which the probe chose not to count for the
Waldbusser Standards Track [Page 34]
RFC 2021 Remote Network Monitoring MIB January 1997
nlHost entries for whatever reason. Most often, this
occurs when the probe is out of some resources and decides
shed load from this collection
This count does not include packets that were not
because they had MAC-layer errors
Note that if the nlHostTable is inactive because no
are enabled in the protocol directory, this value should be 0.
Note that, unlike the dropEvents counter, this number is
exact number of frames dropped."
::= { hlHostControlEntry 3 }
hlHostControlNlInserts OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of times an nlHost entry has
inserted into the nlHost table. If an entry is inserted,
deleted, and then inserted, this counter will be
by 2.
To allow for efficient implementation strategies, agents
delay up