Digital PDFs

EK-DTRMN-UG-A01

July 1994

164 pages

Original

0.4MB

Document:	DECpacketprobe 900RR User's Information
Order Number:	EK-DTRMN-UG
Revision:	A01
Pages:	164
Original Filename:

OCR Text

DECpacketprobe 900RR
User’s Information
Order Number: EK–DTRMN–UG. A01

Revision Update Information:

Digital Equipment Corporation
Maynard, Massachusetts

This is a new manual.

First Edition, July 1994
Digital Equipment Corporation makes no representation that the use of its products in the manner
described in this publication will not infringe on existing or future patent rights, nor do the
descriptions contained in this publication imply the granting of licenses to make, use, or sell
equipment or software in accordance with the description.
© Digital Equipment Corporation 1993.
All Rights Reserved.
Printed in the U.S.A.
The following are trademarks of Digital Equipment Corporation: DEC, DECbridge, DECconnect,
DEChub, HUBwatch, DECagent, DECserver, Digital, POLYCENTER, ThinWire, ULTRIX, and the
Digital logo.
Motorola is a registered trademark of Motorola, Inc.

This document was prepared using VAX DOCUMENT Version 2.1.

FCC NOTICE: The equipment described in this manual generates, uses, and may emit radio
frequency energy. The equipment has been type tested and found to comply with the limits
for a Class A computing device pursuant to Part 15 of FCC Rules, which are designed to
provide reasonable protection against radio frequency interference when operated in a commercial
environment. Operation of this equipment in a residential area may cause interference, in which
case the user at his own expense may be required to take measures to correct the interference.
CE NOTICE:

Warning!
This is a Class A product. In a domestic environment this product may
cause radio interference in which case the user may be required to take
adequate measures.

Achtung!
Dieses ist ein Gerät der Funkstörgrenzwertklasse A. In Wohnbereichen
können bei Betrieb dieses Gerätes Rundfunkstörungen auftreten, in
welchen Fällen der Benutzer für entsprechende Gegenma nahmen
verantwortlich ist.

Attention!
Ceci est un produit de Classe A. Dans un environment domestique, ce
produit risque de crier des interfirences radioilectriques, il appartiendra
alors ‘ l’utilisateur de prendre les mesures spicifiques appropriies.

Contents
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Part I Product Overview
1 Overview
1.1
1.2
1.3
1.4
1.4.1
1.4.2
1.5
1.6

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How DECpacketprobe 900RR Works . . . . . . . . . . . . . . . . .
Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RMON–MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Community Strings for the DECpacketprobe 900RR . . . . .
LEDs and Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1–1
1–2
1–2
1–4
1–4
1–6
1–7
1–8

Part II Installation and Configuration Procedures
2 Installation
2.1
2.2
2.2.1
2.2.2
2.3
2.4

Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standalone Installation . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabletop Installation . . . . . . . . . . . . . . . . . . . . . . . . . .
Wallmount Installation . . . . . . . . . . . . . . . . . . . . . . . .
Backplane Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Powerup and Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2–1
2–1
2–1
2–2
2–5
2–7

3 Configuration
3.1
3.2
3.3
3.4
3.5
3.6

Out–of–Band Management (Asynchronous) Port . . . . . . . .
Console Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the DECpacketprobe 900RR for SNMP
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bootp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connecting the DECpacketprobe 900RR to a Ring . . . . . . .
Configuring for Serial Line Internet Protocol (SLIP) . . . . .

3–1
3–2
3–6
3–7
3–7
3–8

4 Problem Solving
4.1
4.2

Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . .
Troubleshooting the DECpacketprobe 900RR . . . . . . . . . . .

4–1
4–2

Part III RMON–MIB Reference
5 Remote Network Monitoring Management Information
Base
5.1
5.2
5.3
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5

Overview of SNMP and Dot Notation . . . . . . . . . . . . . . . .
The Network Management Framework . . . . . . . . . . . . . . .
Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of Remote Network Monitoring . . . . . . . . . . . . .
Remote Network Monitoring Goals . . . . . . . . . . . . . . .
Structure of the RMON–MIB . . . . . . . . . . . . . . . . . . . .
Control of Remote Network Monitoring Devices . . . . .
Resource Sharing Among Multiple Management
Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Row Addition Among Multiple Management
Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Statistics Group
7 History Group

5–1
5–4
5–4
5–5
5–5
5–6
5–7
5–7
5–9

8 Alarm Group
9 Host Group
10 Host Top N Group
11 Matrix Group
12 Filter Group
13 Packet Capture Group
14 Event Group
15 Token Ring Group
15.1
15.2
15.3
15.4
15.5
15.6
15.7
15.8
15.9

The Token Ring Mac-Layer Statistics Group . . . . . . . . . . .
The Token Ring Promiscuous Statistics Group . . . . . . . . . .
The Token Ring Mac-Layer History Group . . . . . . . . . . . . .
The Token Ring Promiscuous History Group . . . . . . . . . . .
The Token Ring Ring Station Group . . . . . . . . . . . . . . . . .
The Token Ring Ring Station Order Group . . . . . . . . . . . .
The Token Ring Ring Station Config Group . . . . . . . . . . . .
The ringStationConfig Table . . . . . . . . . . . . . . . . . . . . . . .
The Token Ring Source Routing group . . . . . . . . . . . . . . . .

15–1
15–6
15–9
15–14
15–18
15–24
15–25
15–26
15–27

A Specifications and Parts
A.1
A.2
A.2.1
A.2.2
A.3
A.4
A.4.1
A.4.2
A.5
A.6

Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environmental Specifications . . . . . . . . . . . . . . . . . . . . . . .
Operating Environment . . . . . . . . . . . . . . . . . . . . . . . .
Shipping Environment . . . . . . . . . . . . . . . . . . . . . . . . .
Acoustical Specifications . . . . . . . . . . . . . . . . . . . . . . . . . .
Electrical Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power Supply (H7827–BA) . . . . . . . . . . . . . . . . . . . . . .
Input Voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Connector Pin-Out (RS–232/DB9) . . . . . . . . . . . . .
Replacement Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A–1
A–2
A–2
A–2
A–2
A–3
A–4
A–4
A–5
A–5

vii

B Documentation and Ordering Information
B.1
B.2

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B–1
B–1

Sample DECpacketprobe 900RR Configuration . . . . . .
The DECpacketprobe 900RR Module . . . . . . . . . . . . . .
Removing the Back Cover . . . . . . . . . . . . . . . . . . . . . .
Mounting Hole Locations . . . . . . . . . . . . . . . . . . . . . . .
Connecting the Cables . . . . . . . . . . . . . . . . . . . . . . . . .
DECpacketprobe 900RR Backplane Installation . . . . .

1–3
1–8
2–2
2–3
2–4
2–6

RMON–MIB Token Ring Groups . . . . . . . . . . . . . . . . .
DECpacketprobe 900RR LEDs and Connectors . . . . . .
Asynchronous Port Cabling . . . . . . . . . . . . . . . . . . . . .
Console Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Object Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bootp File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Solving a DECpacketprobe 900RR Standalone
Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Solving a DECpacketprobe 900RR in a
DEChub 900 Backplane . . . . . . . . . . . . . . . . . . . . . . . .
Decimal Definitions for the Object Identifier Prefix . . .
Decimal Definitions for Groups in RMON–MIB . . . . . .
Acoustics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schallemissionswerte . . . . . . . . . . . . . . . . . . . . . . . . . .

1–5
1–9
3–2
3–4
3–5
3–7

Index
Figures
1–1
1–2
2–1
2–2
2–3
2–4

Tables
1–1
1–2
3–1
3–2
3–3
3–4
4–1
4–2
5–1
5–2
A–1
A–2

viii

4–2
4–3
5–3
5–3
A–3
A–3

About This Manual
Introduction
This manual describes how to install, configure, use, and troubleshoot the
DECpacketprobe 900RR agent module. The DECpacketprobe 900RR implements
the Token Ring Remote Network Monitoring Information Base (RMON–MIB).
It can be used in a standalone operation or in the DEChub 900 Multiswitch
backplane.

Intended Audience
This manual is intended for experienced network managers.

Organization
This manual is organized as follows:

Part I, Product Overview
•

Chapter 1 provides an overview of the DECpacketprobe 900RR. It also
describes its features, LEDs, and connectors.

Part II, Installation and Configuration Procedures
•

Chapter 2 describes how to install the DECpacketprobe 900RR as a
standalone unit or in a DEChub 900 Multiswitch backplane.

•

Chapter 3 provides configuration information for correct operation of the
DECpacketprobe 900RR.

•

Chapter 4 discusses conditions that may affect DECpacketprobe 900RR
performance. It also contains basic troubleshooting information.

Part III, RMON–MIB Reference
•

Chapter 5 discusses the Remote Network Monitoring Management
Information Base (RMON–MIB).

•

Chapter 6 contains the Statistics group parameters.

•

Chapter 7 contains the History group parameters.

•

Chapter 8 contains the Alarm group parameters.

•

Chapter 9 contains the Host group parameters.

•

Chapter 10 contains the Host Top N group parameters.

•

Chapter 11 contains the Matrix group parameters.

•

Chapter 12 contains the Filter group parameters.

•

Chapter 13 contains the Packet Capture group parameters.

•

Chapter 14 contains the Event group parameters.

•

Chapter 15 contains the Token Ring group parameters.

Appendixes
•

Appendix A contains DECpacketprobe 900RR specifications and a parts list.

•

Appendix B contains information about related documentation and ordering.

Part I
Product Overview

1
Overview
This chapter provides an overview of the DECpacketprobe 900RR module. It lists
the features of the module, describes the LEDs and connectors, and provides
information about community strings.

1.1 Features
The following list summarizes the features of the DECpacketprobe 900RR:
•

Implements the Remote Network Monitoring (RFC 1271) Management
Information Base (MIB).

•

Implements the Token Ring extension (RFC 1513).

•

Can be installed as a standalone unit or in a DEChub 900 Multiswitch
backplane.

•

Needs no downline load at powerup.

•

Is downline loadable for firmware upgrades (TFTP protocol).

•

Can be directly managed through SNMP.

•

Provides an out-of-band console port for SNMP management over SLIP.

•

Allows hot-swapping of modules.

Overview 1–1

1.2 Description
The DECpacketprobe 900RR module is a network management agent designed
for IEEE 802.5 networks. It uses Simple Network Management Protocol (SNMP)
and has one IEEE 802.5 compliant Asynchronous RS–232 (DB9) port.
The DECpacketprobe 900RR is a self-contained module that uses a Motorola
68ECO30 central processing unit (CPU). The DECpacketprobe 900RR can
operate in a standalone configuration with a 5-volt power supply or in a
DEChub 900 MultiSwitch Token Ring backplane.

1.3 How DECpacketprobe 900RR Works
DECpacketprobe 900RR agents gather a wide variety of statistical information
about network operation. An agent gathers the information by examining each
packet passed on a network segment. Segment statistics are stored in counters
within the agent. The counters are continuously updated and reset at powerup.
In addition to statistics, the agent captures and stores network traffic
information. You can examine these individual packets or sequences of packets to
identify and isolate network operational software or hardware problems.
A typical network consists of multiple network segments with one
DECpacketprobe 900 connected to each segment. You can control the agent
from a centrally located network management station designated as the ‘‘client.’’
The client has a user interface that permits you to request and examine data
from a selected agent. You can have multiple clients active to perform network
diagnostic functions from multiple location,s such as primary and secondary
network management centers.
Figure 1–1 contains a sample configuration for the DECpacketprobe 900RR.

1–2 Overview

Figure 1–1 Sample DECpacketprobe 900RR Configuration

Workgroup
Workstation

PROBEwatch

DEChub 900

DECmau 900TL

Workstation

DECpacketprobe 900 RR

DECmau 900TL

Token Ring

DECmau 900TL

Server

DECpacketprobe 90
Ethernet

Repeater

Workstation

Router
Token Ring
to Ethernet

PROBEwatch
Workstation
LKG-9273-94I

Overview 1–3

1.4 Standards
DECpacketprobe 900RR agents are based on widely accepted industry standards.
Communication between agents and clients are performed with Simple Network
Management Protocol (SNMP). The statistical information gathered is defined by
the Remote Network Monitoring Management Information Base (RMON–MIB) as
defined for Token Ring networks.
In addition to the Token Ring RMON–MIB groups (RFC 1513), DECpacketprobe
900RR supports RMON-MIB groups (RFC1271), MIBII System and Interface
groups (RFC 1213) and Enterprise-specific MIB extensions.
DECpacketprobe 900RR does not support the following MIBII groups:
•

Address translation

•

ICMP

•

TCP

•

UDP

•

EGP

•

Transmission

•

SNMP

1.4.1 RMON–MIB
The RMON–MIB is a standard developed under the auspices of the Internet
Engineering Task Force (IETF) as an extension of their pioneering work in the
development of SNMP. This standard provides a data object base compatible with
the widest range of network needs, and permits independent developers to design
network monitoring equipment that interoperates.
Table 1–1 describes the 10 RMON–MIB groups for Token Ring that
DECpacketprobe 900RR supports. Part III of this manual, contains a detailed
description of the RMON–MIB and the Token Ring groups.

1–4 Overview

Table 1–1 RMON–MIB Token Ring Groups
This group . . .

Allows you to . . .

Alarms

Set a wide variety of thresholds and sampling intervals on any
statistic to create an alarm condition. You may set threshold
values as:
•

An absolute value

•

A rising value

•

A falling value

•

A delta value, that allows each node or segment to be fully
customized

Events

Create entries in the monitor log and generate SNMP traps from
the agent to the client for selected events. You can initiate events
by setting a crossed threshold on any counter or from a specific
packet match count. The log includes the time of day for each
event and a description of the event.

Filters

Define specific packet match filters that serve as a stop/start
mechanism for all packet capture functions and events. You may
combine filters with AND, NOT, or OR functions to capture either
broad or unique network events.

History

Obtain a historical representation of statistics based on userdefined sample intervals and bucket counters for customized trend
analysis.

Host Table

Gather information for all nodes retrievable under SNMP for
non-SNMP devices by means of a host table. A table for each node
contains a variety of node statistics for each active node, including
the relative time the node was discovered.

HostTopN

Perform a user-defined study of sorted host statistics that provide
detailed information on the top n occurrences (where n is a
number supplied by you). Performed locally by the agent, this
function substantially reduces network traffic.

Packet Capture

Perform further analysis using matched packets captured and
stored under the control of selected filters. Buffer sizes can be
user-selected and can wrap or stop when full. You can upload
captured packets to a centralized client that, if equipped with
protocol decode software, will allow you to perform complete
protocol analysis.
(continued on next page)

Overview 1–5

Table 1–1 (Cont.) RMON–MIB Token Ring Groups
This group . . .

Allows you to . . .

Statistics

Obtain an array of operational statistics, including the following:

Traffic Matrix

•

Packets

•

Octets

•

Broadcasts

•

Dropped packets

•

Fragments

•

CRCalignment errors

•

Undersize/oversize

Obtain a matrix that shows the amount of traffic and the number
of errors between any pair of nodes. Retrieved by either source or
destination address.

1.4.2 Protocols
The DECpacketprobe 900RR has a single IP address. It implements the protocols
required for SNMP-based access and uses the following protocols:
•

Simple Network Management Protocol (SNMP)

•

Address Resolution Protocol (ARP)

•

Internet Protocol (IP)

•

User Datagram Protocol (UDP)

•

Trivial File Transfer Protocol (TFTP)
Note
TFTP is for network loading of upgrades.

1–6 Overview

1.5 Community Strings for the DECpacketprobe 900RR
A community, in SNMP, is a set of manageable attributes that are managed as
a group. Normally, there is a one-community-to-one-agent relationship. The
manageable attributes are usually contained within a single hardware device,
or within a single enclosure, when referenced with hubs. The single hardware
device, or the collection of devices within a hub, is treated as one community.
A particular manageable entity is uniquely identified on the network by the
combination of an IP address and a community string.
A community string is a sequence of ASCII characters that is checked by the
SNMP agent for access control to the manageable entity. The community string
can be thought of as a password. Two strings are associated with a given
community: the read-only string and the read/write string. For a GET or a GET
NEXT operation, the agent accepts either the read-only or the read/write string.
However, for a SET operation, the agent accepts only the read/write string.
Each community for a DECpacketprobe 900RR is identified by a unique
community address string for each standalone unit or module installed in a
DEChub 900 backplane.
The community string name can be up to 32 characters. A community string
consists of any printable characters and is case-sensitive. Here are two examples
of naming schemes:
MyHUBFloor3Room27
COMM_LAB_HUB_3
For more information about communities, see Chapter 5.

Overview 1–7

1.6 LEDs and Connectors
Figure 1–2 shows the DECpacketprobe 900RR and Table 1–2 describes its LEDs
and connectors.
Figure 1–2 The DECpacketprobe 900RR Module
9
8
7

1
2
3

4
5
11

12
6

LKG-8926-94I

1–8 Overview

Table 1–2 DECpacketprobe 900RR LEDs and Connectors
Item

Icon

Description

DC OK indicator — Monitors the voltage.
On: The +5.0 Vdc voltage is normal.
Off: The voltage is abnormal (as when a power failure occurs).
Ring A — Indicates that there is an active connection to Ring A.

16M— Indicates that the network port is transfering data at a rate
of 16 Megabits per second.

Ring activity indicator — Indicates ring activity.
Flashing: Ring activity.
Off: No Ring activity.

Token Ring connector — Connects the agent to the twisted-pair
ring.

Asynchronous serial port (RS–232) connector — Provides an
interface to the DECpacketprobe 900RR through a console terminal
or terminal emulation program. It can also be used for a SLIP
connection.

Selftest OK indicator — Indicates selftest status. This LED
turns on at power-up and turns off upon a successful selftest,
approximately 5 seconds.
Ring B — Indicates that there is an active connection to Ring B.
4M — Indicates that the network port is transferring data at a rate
of 4 Megabits per second.
Backplane connector — Provides network and power connections
to the DECpacketprobe 900RR when it is installed in the DEChub
900 backplane.
Power connector — Receives +5.0 volts from the DECpacketprobe
900RR power supply. Not used when the agent is installed in the
DEChub 900 backplane.
Back cover — Used with standalone units only. It covers the
backplane connector and mounting assembly.

Overview 1–9

Part II
Installation and Configuration
Procedures

2
Installation
This chapter describes how to install the DECpacketprobe 900RR as a standalone
unit or in a DEChub 900 backplane.

2.1 Inventory
You should have received the following items:
•

1 DECpacketprobe 900RR

•

2 mounting screws, if standalone

•

1 power supply and ac power cord (if the DECpacketprobe 900RR is ordered
for standalone use)

•

Documentation (this manual)

2.2 Standalone Installation
The DECpacketprobe 900RR can be installed either on a tabletop or on a wall.
The location should be within 2 meters (6 feet) of a power outlet that supplies the
correct voltage (Appendix A).
When operating as a standalone unit, the DECpacketprobe 900RR receives power
from a separate power supply. This power supply connects to the unit by a cable
with a 7-pin connector. There is one universal autosensing power supply with
power cords appropriate to local convention.

2.2.1 Tabletop Installation
For tabletop installation, place the DECpacketprobe 900RR on a table and
connect the cables as described in Section 2.2.2.

Installation 2–1

2.2.2 Wallmount Installation
To install the DECpacketprobe 900RR on a wall:
1. Remove the back cover (Figure 2–1).
a. Insert a small screwdriver into the top mounting hole on the cover.
b. Lift the latch with the screwdriver.
c.

Pull the cover away and down from the top of the unit.

Figure 2–1 Removing the Back Cover

LKG-8010-93I

2–2 Installation

2. Use the mounting holes on the back cover (Figure 2–2,
placement for the mounting screws on the wall.

) to determine the

3. Secure the back cover to the wall using the mounting screws (Figure 2–2,

The screws should be tight enough to provide resistance when you remove the
cover from the wall. Do not make them so tight that the cover is distorted or
cannot be removed from the wall.
Figure 2–2 Mounting Hole Locations

1
2

LKG-8015-93I

Installation 2–3

4. Remove the back cover from the wall, attach the cover to the unit, then mount
the unit onto the mounting screws.
5. Connect the cables (Figure 2–3).
a. Connect the twisted-pair connector as shown

b. Connect the cable from the power supply (H7827–BA)
power connector on the DECpacketprobe 900RR .
c.

Connect a terminal to the front panel asynchronous port
connection allows console management.

to the 7-pin

. This

Figure 2–3 Connecting the Cables

LKG-8927-94I

2–4 Installation

2.3 Backplane Installation
To install the DECpacketprobe 900RR in a 900 hub:
1. Remove the back cover (Figure 2–1 if one came with your unit).
2. Install the DECpacketprobe 900RR in the backplane (Figure 2–4). Place the
lower mounting tab, located on the back of the DECpacketprobe 900RR, into
any slot of the backplane.
3. Rock the unit towards the backplane until it clicks into place.
Note
The DECpacketprobe 900RR can be installed into or removed from
the DEChub 900 Token Ring backplane while power is supplied to the
backplane. This procedure is referred to as a ‘‘hot swap.’’

Installation 2–5

Figure 2–4 DECpacketprobe 900RR Backplane Installation

LKG-8925-94I

2–6 Installation

2.4 Powerup and Reset
Upon initial powerup of the DECpacketprobe 900RR, the DC OK LED
illuminates. After approximately 5 seconds, the ring activity LED lights
with intensity that is proportional to the amount of network activity on the port.
Upon powerup and reset, the DECpacketprobe 900RR performs self-test out of
ROM. The unit enters an operational mode if an IP address has been established.
If an IP address has not been established, the unit will attempt to obtain its IP
address via Bootp. You can also establish one with a terminal through the console
port.
If the unit encounters no FLASH image or a corrupted image during powerup or
reset, the unit enters the monitor mode. While the unit is in monitor mode, you
can access error information and logs through the console port.
To verify the operating mode, start a console session. The console screen indicates
whether the unit is operating from FLASH or EPROM. The DECpacketprobe
900RR should always operate out of FLASH with one exception, which is during
a FLASH update.
See Chapter 3 for information about starting a console session to set an IP
address, access error information, or check the operating mode.

Installation 2–7

3
Configuration
The DECpacketprobe 900RR agent software starts to run upon initial installation.
At this point, you must initialize the following agent parameters:
•

IP address

•

Net mask

•

Gateway address

The procedure is done from the console. During the console session, you can
also access and change some of the read/write parameters of the agent. See
Section 3.2 for instructions.

3.1 Out–of–Band Management (Asynchronous) Port
The signals on the asynchronous port (DB–9) conform to standard EIA–574.
Standard EIA–574 is based on standard EIA–232D, which uses a 9–pin connector
instead of a 25–pin connector. This is the signaling standard used by most
personal computers for their serial ports. The port appears as a data terminal
equipment (DTE) device. The asynchronous port supports flow control for
Request to Send (RTS) and Clear to Send (CTS) hardware communications. Refer
to Appendix A for information about signal connections.
The asynchronous port can be connected to a terminal server, personal computer,
or a modem using various cables and adapters. Refer to Table 3–1 for your
configuration.

Configuration 3–1

Table 3–1 Asynchronous Port Cabling
Cable/Adapter Type

Connecting Device

BC29Q–10

PC with 9–pin D–Sub connector

BC29P–10

Modem with 25–pin D–Sub connector

BN24h–xx†/H8571–J

Communications server with a 8 MJ connector

H8571–J

Terminal with a 6 pin MMJ connector

†The xx represents the length in meters.

Setup your terminal or terminal emulator for 9600 baud, 8 bits, 1 stop bit, no
parity.

3.2 Console Session
Since the module comes preloaded with the agent software, you may initiate a
session with the agent through use of the agent console port. To start a console
session, connect a terminal to the console port on the DECpacketprobe 900RR
and press Return twice.

3–2 Configuration

The following screen appears:
**** DECpacketprobe 90 Token Ring Probe Agent configuration utility ****
Copyright (c) 1993, Frontier Software Development, Inc.
ALL RIGHTS RESERVED.
***** DECpacketprobe 900 Token Ring Probe Rev 1.0 *****
Executing from FLASH
[1]
[2]
[3]
[4]
[5]
[6]

Change IP Address
Change Net Mask
Change Default Gateway Address
Change Read Community
Change Write Community
Change Interface Speed

[8] Select Interface
[9] Change Server Address
[10] Upgrade Software
[11] Enter Command-line mode
[12] Reset Agent

0.0.0.0
0.0.0.0
0.0.0.0
public
public
16
TOKEN_RING
0.0.0.0

Enter your response or Enter "exit" to logout
The following list describes each selection of the configuration utility.
•

Selections 1 through 9 allow you to view or change the corresponding
information. When you choose one of these selections, the current state of
the parameter appears. To change the state of the parameter, enter the new
information and press Return . To make no change, simply press Return .

•

Selection 10 allows you to update the firmware in FLASH. To be updated,
the DECpacketprobe 900RR must be connected to a TFTP server and the
server must have the update image loaded.

•

Selection 11 allows you to enter the command-line mode to access or change
agent parameters. Table 3–2 describes the permissible actions in commandline mode, and Table 3–3 describes each object variable that you can associate
with the actions.

Configuration 3–3

Entering help at the command-line prompt (%) displays the following help
screen:
%help
Syntax: action object [arg,...]
actions
get: display the value of an object
set: change the value of an object
do: perform an agent operation
help: display this menu
quit: exit command-line mode
objects
agent
agent_options
interface
max_log
nvram
tftp

agent_contact
eventlog
ip_addr
max_matrix
read_community
tftp_timeout

agent_location
gw_addr
max_captsize
myu_size
reset
tftp_server

agent_name
if_options
max_host
net_mask
speed
write_community

%
•

Selection 12 allows you to reset the agent and saves the current agent setup
parameters in battery-backed RAM.

The following tables contain information on console actions and object variables.
Table 3–2 Console Actions
Action

Description

get

Retrieves the value of the designated object.

set

Sets the value of the designated object.

Produces an action in the agent.

help

Provides a list of permissible commands and command objects.

quit

Exits from the command-line mode.

3–4 Configuration

Table 3–3 Object Variables
Variable

Description

agent

A composite list of the agent parameters and descriptions.

agent_contact

An ASCII text string corresponding to the MIBII system group
variable sysContact.

agent_location

An ASCII text string corresponding to the MIBII system group
variable sysLocation.

agent_name

An ASCII text string corresponding to the MIBII system group
variable sysName.

agent_options

The object variables that can be obtained through command-line
mode.

eventlog

A log maintained at the agent. Includes a list of the most recent
events that have occurred at the agent. These events are stored as
they occur.

gw_addr

Gateway address.

if_options

Not currently used.

interface

IP address, gateway address, and net mask address.

ip_addr

IP address.

max_captsize

Not currently used.

max_host

Decimal value specifying the maximum number of entries in each
instance of the RMON–MIB hostTable and hostTimeTable. The agent
removes the least recently seen host entries when this number is
exceeded. The default value is 500.

max_log

Decimal value specifying the maximum number of entries in the
RMON–MIB logTable. The default value is 500.

max_matrix

Decimal value specifying the maximum number of entries in each
instance of the RMON–MIB matrixDSTable and matrixSDTable.
The agent removes the least recently seen matrix entries when this
number is exceeded. The default value is 4000.

myu_size

Not currently used.

net_mask

Address for a network structure.

nvram

Not currently used.

read_community

Read only community string.

reset

Agent reset.

speed

Baud rate.
(continued on next page)

Configuration 3–5

Table 3–3 (Cont.) Object Variables
Variable

Description

tftp

Utility for agent updates.

tftp_timeout

Value specifying the response timeout from the TFTP server.

tftp_server

Address for the TFTP server.

write_community

Read/write community string.

3.3 Configuring the DECpacketprobe 900RR for SNMP
Management
To configure the DECpacketprobe 900RR perform the following steps:
1. Set the IP Address—Enter the IP address that is to be used.
2. Set the NET Mask—Set the NET Mask to the proper subnet mask.
3. Set the default gateway address— Set the default gateway address as
appropriate for the subnet that the DECpacketprobe 900RR is on.
4. Set community strings—Change the community strings, if necessary.
5. Set interface speed—Set the interface speed to match your modem.
6. Reset the agent—Reset the agent so the new paramerers can take effect.

3–6 Configuration

3.4 Bootp
The DECpacketprobe 900RR supports getting it’s IP address through Bootp. The
following file format must be followed:
#
#host type addr addr bootfile smask gateway
#
For example:
sample 1 00808C010181 45.20.0.205 dummy 255.255.252.0 45.20.0.94
Table 3–4 Bootp File Format
Entry

Description

sample

Name of agent

Hardware type 1

00808C010181

Agent’s 48–bit address

45.20.0.205

Ip address associated with agent

dummy

Placeholder, use "dummy"

255.255.252.0

Agent’s subnet mask

45.20.0.94

Desired default gateway address for the agent

Note
The agents default server IP address is set to the IP address of the host
that responds to the Boop request.

Warning
Do not install bootpd if another Bootp server is already running on your
network.

3.5 Connecting the DECpacketprobe 900RR to a Ring
The DECpacketprobe 900RR V1.0 must be externally cabled to a ring, even if it is
installed in a DEChub 900 Multiswitch. Connect a BN26M, BN25G or equivalent
cable between the Token Ring connector on the DECpacketprobe 900RR and a
MAU port.

Configuration 3–7

3.6 Configuring for Serial Line Internet Protocol (SLIP)
Selection 8 on the console menu allows you to use out-of-band management
(OBM) using the Serial Line Internet Protocol (SLIP). Once you switch to this
mode, you can manage the DECpacketprobe 900RR using any SNMP-compliant
Network Management Station (NMS) that supports a SLIP connection. When 8
is selected, the following screen will be displayed.
Select the Interface :
[1] TOKEN RING
[2] SERIAL

MODE = MANAGE + MONITOR
MODE = MANAGE

New Interface [1] :
Enter 2 to switch to the serial mode.
The DECpacketprobe 900RR is now able to use a SLIP connection through the
asynchronous port.
Use the above procedure to switch back to Token Ring mode.

3–8 Configuration

4
Problem Solving
This chapter describes the conditions that influence the performance of the
DECpacketprobe 900RR. It also provides information for solving problems related
to the DECpacketprobe 900RR when used as a standalone unit, or when installed
in a DEChub 900 backplane.

4.1 Performance Considerations
Protocol monitoring and analysis is a real-time function. Every packet and
event on the segment being monitored by the DECpacketprobe 900RR must be
examined, evaluated, and counted. In some cases, a sequence of filters must be
applied to the data before specific action such as counts or data storage take
place. In addition, irregular events such as packet fragments, jabbers, and
beaconing must be recognized, counted, and discarded.
The capability of the DECpacketprobe 900RR to process all packets and handle
all other requirements in real-time depends on many factors. The most common
factors are the following:
•

Fundamental speed of the processor

•

Arrival rate of data and events on the segment

•

Amount of work the agent has been configured to do by the client

Predicting the specific performance of an agent is impossible, due to the great
number of variables in a normal network configuration.

Problem Solving 4–1

At some point, the agent will not be able to respond as required to all the network
traffic. An example is when one agent is performing different functions under the
direction of two or more clients. Under these conditions, the following may occur:
•

Response to user inquiries from the client may slow down.

•

Some packets will be missed. The number of occasions when one or more
packets is missed is in the dropEvents statistic.

4.2 Troubleshooting the DECpacketprobe 900RR
To determine the cause of a problem with the DECpacketprobe 900RR:
1. Verify the installation of the DECpacketprobe 900RR.
2. Verify the IP, net mask, and gateway addresses. Installation must meet the
configuration information given in Chapter 3.
3. Note the fault condition.
4. Verify that the DECpacketprobe 900RR is operating from FLASH NVRAM.
5. Isolate the problem.
Use Table 4–1 to solve problems related to a standalone DECpacketprobe
900RR.
Use Table 4–2 to solve problems related to a DECpacketprobe 900RR
installed in a DEChub 900 backplane.
Table 4–1 Problem Solving a DECpacketprobe 900RR Standalone Unit
If . . .

Then . . .

Do this . . .

All LEDs are off.

Check the ac power
connection.

Check that the power supply is
properly plugged into the power
outlet. Check the power to the
power outlet.

Check the power supply.

Check the 7-pin connector to the
power supply. If the connections
are okay, replace the power
supply cord and power supply.
(continued on next page)

4–2 Problem Solving

Table 4–1 (Cont.) Problem Solving a DECpacketprobe 900RR Standalone Unit
If . . .

Then . . .

Do this . . .

All LEDs flicker.

The DECpacketprobe
900RR is not receiving
the correct voltages.

Connect the DECpacketprobe
900RR to the correct power
supply or replace the power
supply.

The ring activity LED
is off.

There is low ring activity or
no ring activity.

Ensure that ring activity
is present and that the
DECpacketprobe 900RR is
properly connected to the ring.

If the ring activity LED still
fails to light

Turn the agent off and on by
unplugging and replugging the
power supply. Check that the
ring activity LED comes on
momentarily.

If the ring activity LED
lights momentarily, the
ring activity LED portion of
testing has passed.

Replace the DECpacketprobe
900RR.

If the ring activity LED
fails to light.

Replace the DECpacketprobe
900RR.

Table 4–2 Problem Solving a DECpacketprobe 900RR in a DEChub 900
Backplane
If . . .

Then . . .

Do this . . .

The power LED is off.

The DECpacketprobe
900RR is not receiving
+5 V.

Check the power LED on the
DEChub 900 power supply.

If the power LED on the
DEChub 900 is off, there is
a problem with the DEChub
900 power supply.

See the problem solving
procedures in the owner’s manual
for the DEChub 900.
(continued on next page)

Problem Solving 4–3

Table 4–2 (Cont.) Problem Solving a DECpacketprobe 900RR in a DEChub 900
Backplane
If . . .

The ring activity LED
is off.

Then . . .

Do this . . .

If the power LED on the
DEChub 900 power supply
is on, are other component
power LEDs off? If other
components are on, the
DECpacketprobe 900RR
has a power problem.

Try reseating the DECpacketprobe
900RR in either the same slot or
the other slot.

If the power LED on the
DEChub 900 power supply
is on, are other component
power LEDs off? If other
components are off, the
DEChub 900 has a power
problem.

See the problem solving
procedures in the owner’s manual
for the DEChub 900.

If the power LED turns on
when reseated in the same
slot, the DECpacketprobe
900RR was not properly
seated.

Make sure that the
DECpacketprobe 900RR is
properly seated in the slot.

If the power LED turns on
when reseated in another
slot, the problem is with the
DEChub 900.

See the problem solving
procedures in the owner’s manual
for the DEChub 900.

If the DECpacketprobe
900RR does not turn on
in a known good slot, the
DECpacketprobe 900RR is
defective.

Replace the DECpacketprobe
900RR.

The DECpacketprobe
900RR or any other unit
in the DEChub 900 may not
be connected to an active
ring.

Connect the DECpacketprobe
900RR to a known active ring.

(continued on next page)

4–4 Problem Solving

Table 4–2 (Cont.) Problem Solving a DECpacketprobe 900RR in a DEChub 900
Backplane
If . . .

Then . . .

Do this . . .

If the DECpacketprobe
900RR is connected to a
known active ring and
the port LED is off, the
DECpacketprobe 900RR is
defective.

Replace the DECpacketprobe
900RR.

Problem Solving 4–5

Part III
RMON–MIB Reference

5
Remote Network Monitoring
Management Information Base
This chapter includes a detailed description of the functions and acknowledgment
objects that have been defined by the Internet Engineering Task Force (IETF).
This information was derived from a draft memo produced by the Remote
Monitoring Working Group of the IETF dated November 1991, and that was
submitted to the RFC editor as an experimental extension to the SNMP MIB.

5.1 Overview of SNMP and Dot Notation
Over the last few years, SNMP has become the protocol of choice for the
management of internet work resources. As its name implies, it has the
advantage of simplicity and great flexibility for a wide variety of applications.
The addition of the RMON–MIB subgroup under SNMP has resulted in a
standard framework for performing network diagnostics. For an overview
of SNMP and its use in network management, see The Simple Book: An
Introduction to Management of TCP/IP-based Internets, Marshall T. Rose,
Prentice Hall, Englewood Cliffs, NJ, 1991.
SNMP is an application-layered protocol, running over UDP that sits on top of IP
in the TCP/IP protocol stack. It was developed in the late 1980s by a committee
of the Internet Activities Board and has undergone revisions and enhancements
since that time. SNMP is a protocol that network management stations use
to poll network devices that are equipped with ‘‘agents’’ that collect and store
information in a Management Information Base (MIB). Agents send information
to the network management station when requested and otherwise act on the
direction of the centralized control.

Remote Network Monitoring Management Information Base 5–1

SNMP has four operations:
•

Get — Used to retrieve specific management information.

•

Get-next — Used to retrieve management information relative to the
argument included in the command.

•

Set — Used to manipulate information and establish base values.

•

Trap — Used to report specified events.

The above commands are performed on data objects that are uniquely identified
by an Object Identifier. An Object Identifier is a sequence of decimal integer
values where each value is separated by a ‘‘dot.’’ Each decimal value, defined in
Table 5–1, represents a branch along a decision tree where the final step may be
considered a leaf. Therefore, each element of a MIB has its own unique address
using dot notation and also a textual description.
The prefix for an Object Identifier for an RMON instance is
1.3.6.1.2.1.16.
Within RMON–MIB, the groups are identified as described in Table 5–2. Using
the construction in Table 5–2, the Object Identifiers for a few typical objects are
as follows:
1.3.6.1.2.1.16.1.1.1.3.1
1.3.6.1.2.1.16.1.1.1.4.1

etherStatsDropEvents.1
etherStatsOctets.1

1.3.6.1.2.1.16.1.1.1.20.1
1.3.6.1.2.1.16.6.1.1.6.3

etherStatsOwner.1
matrixControlStatus.3

The following chapters, derived from the RMON–MIB standard document, can be
better understood in the context of the above description of the Object Identifier.
Each variable in the MIB is shown with its relative position for the entry using
the notation { xxxxxxEntry n }. For example:
etherStatsDropEvents is { etherStatsEntry 3 }
etherStatsOctets is { etherStatsEntry 4 }
matrixControlStatus is { matrixControEntry 6 }
In addition, the following chapters include the formal textual description for each
object in the RMON–MIB.

5–2 Remote Network Monitoring Management Information Base

Table 5–1 Decimal Definitions for the Object Identifier Prefix
Decimal
Position

Description

iso (1) — International Standards Organization

identified-organization (3) — A defined organization as opposed to other
standards groups

dod (6) — Controlling body for TCP/IP

internet (1) — For internet applications

management (2) — A network management function

mib_2 (1) — Management Information Base
Note: MIB2 is a superset of MIB1.

rmon (16) — Remote monitoring

Table 5–2 Decimal Definitions for Groups in RMON–MIB
Decimal
Position

Description

Consists of the following items:
statistics (1)
history (2)
alarm (3)
hosts (4)
hostTopN (5)
matrix (6)
filter (7)
capture (8)
event (9)
tokenRing (10)

Table (1) to (n) corresponding to control entries.

Entry (1) to (n) is the number of entries in the corresponding table.

Variable (1) to (n) depending on the group.

Instance (1) to (n) is a unique number for each instance of a control entry
for this object.

Remote Network Monitoring Management Information Base 5–3

5.2 The Network Management Framework
The Internet-Standard Network Management Framework consists of the
following components:
•

RFC 1155 defines the Structure of Management Information (SMI). These are
the mechanisms used for describing and naming objects for the purpose of
management. RFC 1212 defines a more concise description mechanism that
is wholly consistent with the SMI.

•

RFC 1156 defines MIBI. This is the core set of managed objects for the
Internet suite of protocols. RFC 1213 defines MIBII, an evolution of MIBIbased on implementation experience and new operational requirements.

•

RFC 1157 defines the SNMP. This is the protocol used for network access to
managed objects. The Framework permits new objects to be defined for the
purpose of experimentation and evaluation.

5.3 Managed Objects
Managed objects are accessed by way of a virtual information store, termed the
Management Information Base, or MIB. Objects in the MIB are defined using
the subset of Abstract Syntax Notation One (ASN.1) [7] defined in the SMI. In
particular, each object has a name, a syntax, and an encoding.
The name is an object identifier, an administratively assigned name, that specifies
an object type. The object type together with an object instance serves to uniquely
identify a specific instance of the object. A textual string is used, termed the
Object Descriptor, to also refer to the object type.
The syntax of an object type defines the abstract data structure corresponding to
that object type. The ASN.1 language is used for this purpose. However, the SMI
[3] purposely restricts the ASN.1 constructs that may be used. These restrictions
are made for simplicity.
The encoding of an object type is how that object type is represented using the
object type’s syntax. Implicitly tied to the notion of an object type’s syntax and
encoding is how the object type is represented when being transmitted on the
network.
The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the
additional requirements imposed by the SNMP. The object types contained in the
RMON–MIB module are defined using the conventions defined in their SMI, as
amended by the extensions specified in [9,10].

5–4 Remote Network Monitoring Management Information Base

5.4 Overview of Remote Network Monitoring
Remote network monitoring devices are instruments that exist for the purpose
of managing a network. Often, these remote probes are standalone devices and
devote significant internal resources for the sole purpose of managing a network.
An organization may employ many of these devices (one per network segment)
to manage its internet. In addition, these devices may be used for a network
management service provider to access a client network, often geographically
remote.

5.4.1 Remote Network Monitoring Goals
Remote Network Monitoring goals include the following:
•

Off-line Operation — Sometimes there are conditions when a management
station will not be in constant contact with its remote monitoring devices.
This is sometimes by design in an attempt to lower communications costs
(especially when communicating over a WAN or dialup link), or by accident as
network failures affect the communications between the management station
and the probe.
For this reason, this MIB allows a probe to be configured to perform
diagnostics and to collect statistics continuously, even when communication
with the management station may not be possible or efficient. The probe
may then attempt to notify the management station when an exceptional
condition occurs. Fault, performance, and configuration information may be
continuously accumulated and communicated to the management station
conveniently and efficiently, even in circumstances where communication
between management station and probe is not continuous.

•

Pre-emptive Monitoring — Given the resources available on the monitor, it is
potentially helpful for it to run diagnostics continuously and to log network
performance. The monitor is always available at the onset of any failure.
It can notify the management station of the failure and can store historical
statistic information about the failure. This historical information can be
played back by the management station in an attempt to perform further
diagnosis into the cause of the problem.

•

Problem Detection and Reporting — The monitor can be configured to
recognize conditions, most notably error conditions, and continuously to check
for them. When one of these conditions occurs, the event may be logged, and
management stations may be notified in a number of ways.

Remote Network Monitoring Management Information Base 5–5

•

Value Added Data — Because a remote monitoring device represents a
network resource dedicated exclusively to network management functions,
and because it is located directly on the monitored portion of the network,
the remote network monitoring device has the opportunity to add significant
value to the data it collects. For instance, by highlighting those hosts on
the network that generate the most traffic or errors, the probe can give the
management station precisely the information it needs to solve a class of
problems.

•

Multiple Managers — An organization may have multiple management
stations for different units of the organization, for different functions (for
example, engineering and operations), and in an attempt to provide disaster
recovery. Because environments with multiple management stations are
common, the remote network monitoring device has to deal with more than
its own management station, potentially using its resources concurrently.

5.4.2 Structure of the RMON–MIB
The objects are arranged into the following groups:
•

Statistics

•

History

•

Alarm

•

Host

•

HostTopN

•

Matrix

•

Filter

•

Packet Capture

•

Event

•

Token Ring

These groups are the basic unit of conformance. If a remote monitoring
device implements a group, it must implement all objects in that group. For
example, a managed agent that implements the Host group must implement the
hostControlTable, the hostTable, and the hostTimeTable.
All groups in this MIB are optional. Implementations of this MIB must also
implement the System and Interface groups of MIBII [6]. MIBII may also
mandate the implementation of additional groups.
These groups are defined to provide a means of assigning object identifiers, and to
provide a method for managed agents to know what objects they must implement.
5–6 Remote Network Monitoring Management Information Base

5.4.3 Control of Remote Network Monitoring Devices
Due to the complex nature of the available functions in these devices, the
functions often need user configuration. In many cases, the function requires
parameters to be set up for a data collection operation. The operation can proceed
only after these parameters are fully set up.
Many functional groups in this MIB have one or more control tables in which
to set up control parameters, and one or more data tables in which to place the
results of the operation. The control tables are typically read-write in nature. The
data tables are typically read-only. Because the parameters in the control table
often describe resulting data in the data table, many of the parameters can be
modified only when the control entry is invalid. Thus, the method for modifying
these parameters is to invalidate the control entry, causing its deletion and the
deletion of any associated data entries, and then to create a new control entry
with the proper parameters. Deleting the control entry also gives a convenient
method for reclaiming the resources used by the associated data.
Some objects in this MIB provide a mechanism to execute an action on the remote
monitoring device. These objects may execute an action as a result of a change in
the state of the object. For those objects in this MIB, a request to set an object to
the same value as it currently holds would thus cause no action to occur.
To facilitate control by multiple managers, resources have to be shared among the
managers. These resources are typically the memory and computation resources
that a function requires.

5.4.4 Resource Sharing Among Multiple Management Stations
When multiple management stations want to use functions that compete for
a finite amount of resources on a device, a method to facilitate this sharing of
resources is required. Potential conflicts include the following:
•

Two management stations want to use simultaneously Resources that
together would exceed the capability of the device.

•

A management station uses a significant amount of resources for a long
period of time.

•

A management station uses resources and then crashes, forgetting to free the
resources so others may use them.

A mechanism is provided for each management station initiated function in this
MIB to avoid these conflicts and to help resolve them when they occur. Each
function has a label identifying the initiator (owner) of the function. This label is
set by the initiator to provide for the following possibilities:
•

A management station may recognize resources it owns and no longer needs.

Remote Network Monitoring Management Information Base 5–7

•

A network operator can find the management station that owns the resource
and negotiate for it to be freed.

•

A network operator may decide to unilaterally free resources another network
operator has reserved.

•

Upon initialization, a management station may recognize resources it had
reserved in the past. With this information it may free the resources if it no
longer needs them.

Management stations and probes should support any format of the owner string
dictated by the local policy of the organization. It is suggested that this name
contain one or more of the following:
•

IP address

•

Management station name

•

Network manager’s name

•

Location

•

Phone number

This information will help users share the resources more effectively.
There is often default functionality that the device wants to set up. The resources
associated with this functionality are then owned by the device itself. In this
case, the device sets the relevant owner object to a string starting with ‘‘monitor’’.
Indiscriminate modification of the monitor-owned configuration by network
management stations is discouraged. In fact, a network management station
should only modify these objects under the direction of the administrator of the
probe, often the network administrator.
When a network management station wants to use a function in a monitor, it is
encouraged to first scan the control table of that function to find an instance with
similar parameters to share. This is especially true for those instances owned
by the monitor, that can be assumed to change infrequently. If a management
station decides to share an instance owned by another management station, it
should understand that the management station that owns the instance may
indiscriminately modify or delete it.

5–8 Remote Network Monitoring Management Information Base

5.4.5 Row Addition Among Multiple Management Stations
The addition of new rows is achieved using the method described in [9]. In
this MIB, rows are often added to a table in order to configure a function.
This configuration usually involves parameters that control the operation
of the function. The agent must check these parameters to make sure they
are appropriate given the restrictions defined in this MIB; as well as any
implementation-specific restrictions such as lack of resources. The agent
implementor may be confused as to when to check these parameters and when to
signal to the management station that the parameters are invalid. There are two
opportunities:
•

When the management station sets each parameter object

•

When the management station sets the entry status object to valid

If the latter is chosen, it would be unclear to the management station which of
the several parameters was invalid and caused the badValue error to be emitted.
Thus, wherever possible, the implementor should choose the former as it will
provide more information to the management station.
A problem can arise when multiple management stations attempt to set
configuration information simultaneously using SNMP. When this involves the
addition of a new conceptual row in the same control table, the managers may
collide, attempting to create the same entry. To guard against these collisions,
each such control entry contains a status object with special semantics that help
to arbitrate among the managers. If an attempt is made with the row addition
mechanism to create such a status object and that object already exists, an error
is returned. When more than one manager simultaneously attempts to create the
same conceptual row, only the first will succeed. The others will receive an error.

Remote Network Monitoring Management Information Base 5–9

6
Statistics Group
The Statistics group contains statistics measured by the probe for each monitored
interface on this device. These statistics take the form of free-running counters
that start from zero when a valid entry is created.
This group currently has statistics defined for the Token Ring interface. Each
etherStatsEntry contains statistics for one interface. The probe must create one
entry for each monitored interface on the device.

Statistics Group 6–1

etherStatsTable
{ statistics }
A list of Token Ring statistics entries.
etherStatsEntry
{ etherStatsTable 1 }
A collection of statistics kept for a particular Token Ring interface:
Entry

Description

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

INTEGER

etherStatsIndex
{ etherStatsEntry 1 }
The value of this object uniquely identifies this etherStats entry.

6–2 Statistics Group

etherStatsDataSource
{ etherStatsEntry 2 }
This object identifies the source of the data it is configured to analyze. This
source can be any Token Ring interface on this device. To identify a particular
interface, this object shall identify the instance of the ifIndex object, defined in
[4,6], for the desired interface.
For example, if an entry were to receive data from interface 1, this object would
be set to ifIndex.1.
The statistics in this group reflect all packets on the local network segment
attached to the identified interface.
This object may not be modified if the associated etherStatsStatus object is equal
to valid(1).
etherStatsDropEvents
{ etherStatsEntry 3 }
The total number of events where packets were dropped by the probe due to lack
of resources. Note that this number is not the number of packets dropped. It is
the number of times this condition has been detected.
etherStatsOctets
{ etherStatsEntry 4 }
The total number of octets of data (including those in bad packets) received on
the network (excluding framing bits but including FCS octets).
etherStatsPkts
{ etherStatsEntry 5 }
The total number of packets (including error packets) received.
etherStatsBroadcastPkts
{ etherStatsEntry 6 }
The total number of good packets received that were directed to the broadcast
address.
etherStatsMulticastPkts
{ etherStatsEntry 7 }
The total number of good packets received that were directed to a multicast
address. Note that this number does not include packets directed to the broadcast
address.

Statistics Group 6–3

etherStatsCRCAlignErrors
{ etherStatsEntry 8 }
The total number of packets received that had a length (excluding framing bits
but including FCS octets) of between 64 and 1518 octets, inclusive, but were not
an integral number of octets in length or had a bad Frame Check Sequence (FCS).
etherStatsUndersizePkts
{ etherStatsEntry 9 }
The total number of packets received that were less than 64 octets long (excluding
framing bits but including FCS octets) and were otherwise well formed.
etherStatsOversizePkts
{ etherStatsEntry 10 }
The total number of packets received that were longer than 1518 octets (excluding
framing bits but including FCS octets) and were otherwise well formed.
etherStatsFragments
{ etherStatsEntry 11 }
The total number of packets received that were not an integral number of octets
in length or that had a bad Frame Check Sequence (FCS), and were less than 64
octets in length (excluding framing bits but including FCS octets).
etherStatsJabbers
{ etherStatsEntry 12 }
The total number of packets received that were longer than 1518 octets (excluding
framing bits but including FCS octets), and were not an integral number of octets
in length or had a bad Frame Check Sequence (FCS).
etherStatsCollisions
{ etherStatsEntry 13 }
The best estimate of the total number of collisions on this Token Ring segment.
etherStatsPkts64Octets
{ etherStatsEntry 14 }
The total number of packets (including error packets) received that were 64 octets
in length (excluding framing bits but including FCS octets).

6–4 Statistics Group

etherStatsPkts65to127Octets
{ etherStatsEntry 15 }
The total number of packets (including error packets) received that were between
65 and 127 octets in length inclusive (excluding framing bits but including FCS
octets).
etherStatsPkts128to255Octets
{ etherStatsEntry 16 }
The total number of packets (including error packets) received that were between
128 and 255 octets in length inclusive (excluding framing bits but including FCS
octets).
etherStatsPkts256to511Octets
{ etherStatsEntry 17 }
The total number of packets (including error packets) received that were between
256 and 511 octets in length inclusive (excluding framing bits but including FCS
octets).
etherStatsPkts512to1023Octets
{ etherStatsEntry 18 }
The total number of packets (including error packets) received that were between
512 and 1023 octets in length inclusive (excluding framing bits but including FCS
octets).
etherStatsPkts1024to1518Octets
{ etherStatsEntry 19 }
The total number of packets (including error packets) received that were between
1024 and 1518 octets in length inclusive (excluding framing bits but including
FCS octets).
etherStatsOwner
{ etherStatsEntry 20 }
The entity that configured this entry and is using the resources assigned to it.
etherStatsStatus
{ etherStatsEntry 21 }
The status of this etherStats entry.

Statistics Group 6–5

7
History Group
The History group records periodic statistical samples from a network and stores
them for later retrieval. The historyControl table stores configuration entries
that each define an interface, polling period, and other parameters. Once samples
are taken, their data is stored in an entry in a media-specific table. Each such
entry defines one sample, and is associated with the historyControlEntry that
caused the sample to be taken. The media-specific table for Token Ring networks
is defined as etherHistoryTable.
If the probe keeps track of the time of day, it should start the first sample of
the history at such a time that when the next hour of the day begins, a sample
is started at that instant. This tends to make more user-friendly reports, and
enables comparison of reports from different probes that have relatively accurate
time of day.
The monitor is encouraged to add two history control entries per monitored
interface upon initialization that describe a short term and a long term polling
period. Suggested parameters are 30 seconds for the short term polling period
and 30 minutes for the long term polling period.

History Group 7–1

HistoryControl
historyControlTable
{ history 1 }
A list of history control entries.
historyControlEntry
{ historyControlTable 1 }
A list of parameters that set up a periodic sampling of statistics:
Entry

Description

historyControlIndex

INTEGER (1 . . . 65535)

historyControlDataSource

OBJECT IDENTIFIER

historyControlBucketsRequested

INTEGER (1 . . . 65535)

historyControlBucketsGranted

INTEGER (1 . . . 65535)

historyControlInterval

INTEGER (1 . . . 3600)

historyControlOwner

OwnerString

historyControlStatus

INTEGER

historyControlIndex
{ historyControlEntry 1 }
An index that uniquely identifies an entry in the historyControl table. Each such
entry defines a set of samples at a particular interval for an interface on the
device.
historyControlDataSource
{ historyControlEntry 2 }
This object identifies the source of the data for which historical data was collected
and placed in a media-specific table on behalf of this historyControlEntry. This
source can be any interface on this device. To identify a particular interface, this
object shall identify the instance of the ifIndex object for the desired interface.
For example, if an entry were to receive data from interface 1, this object would
be set to ifIndex.1.
The statistics in this group reflect all packets on the local network segment
attached to the identified interface.
This object may not be modified if the associated historyControlStatus object is
equal to valid(1).

7–2 History Group

historyControlBucketsRequested
{ historyControlEntry 3 }
The requested number of discrete time intervals where data is to be saved in the
part of the media-specific table associated with this historyControl entry.
When this object is created or modified, the probe should set historyControlBucketsGranted as closely to this object as is possible for the particular probe
implementation and available resources.
The default value for historyControlBuckets is 50.
historyControlBucketsGranted
{ historyControlEntry 4 }
The number of discrete sampling intervals where data shall be saved in the part
of the media-specific table associated with this historyControl entry.
When the associated historyControlBucketsRequested object is created or
modified, the probe should set this object as closely to the requested value as
is possible for the particular probe implementation and available resources.
The probe must not lower this value except as a result of a modification to the
associated historyControlBucketsRequested object.
There will be times when the actual number of buckets associated with this entry
is less than the value of this object. In this case, at the end of each sampling
interval, a new bucket will be added to the media-specific table.
When the number of buckets reaches the value of this object and a new bucket
is to be added to the media-specific table, the oldest bucket associated with this
historyControlEntry shall be deleted by the agent so that the new bucket can be
added.
When the value of this object changes to a value less than the current
value, entries are deleted from the media-specific table associated with this
historyControlEntry. Enough of the oldest of these entries shall be deleted by the
agent so that their number remains less than or equal to the new value of this
object.
When the value of this object changes to a value greater than the current value,
the number of associated media-specific entries may be allowed to grow.

History Group 7–3

historyControlInterval
{ historyControlEntry 5 }
The interval in seconds where the data is sampled for each bucket in the part of
the media-specific table associated with this historyControl entry. This interval
can be set to any number of seconds between 1 and 3600 (1 hour).
Because the counters in a bucket may overflow at their maximum value with no
indication, a prudent manager will take into account the possibility of overflow
in any of the associated counters. It is important to consider the minimum time
in which any counter could overflow on a particular media type and set the
historyControlInterval object to a value less than this interval. This is typically
most important for the ‘‘octets’’ counter in any media-specific table. For example,
on an Token Ring network, the etherHistoryOctets counter could overflow in
about one hour at the Token Ring’s maximum utilization.
This object may not be modified if the associated historyControlStatus object is
equal to valid(1).
The default value for historyControlInterval is 1800 (30 minutes).
historyControlOwner
{ historyControlEntry 6 }
The entity that configured this entry and is therefore using the resources assigned
to it.
historyControlStatus
{ historyControlEntry 7 }
The status of this historyControl entry. Each instance of the media-specific table
associated with this historyControlEntry will be deleted by the agent if this
historyControlEntry is not equal to valid(1).

7–4 History Group

EtherHistory
etherHistoryTable
{ history 2 }
A list of Token Ring history entries.
etherHistoryEntry
{ etherHistoryTable 1 }
An historical sample of Token Ring statistics on a particular Token Ring
interface. This sample is associated with the historyControlEntry that set up
the parameters for a regular collection of these samples:
Entry

Description

etherHistoryIndex

INTEGER (1 . . . 65535)

etherHistorySampleIndex

INTEGER

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
{ etherHistoryEntry 1 }
The history of which this entry is a part. The history identified by a particular
value of this index is the same history as identified by the same value of
historyControlIndex.

History Group 7–5

etherHistorySampleIndex
{ etherHistoryEntry 2 }
An index that uniquely identifies the particular sample this entry represents
among all samples associated with the same historyControlEntry. This index
starts at 1 and increases by one as each new sample is taken.
etherHistoryIntervalStart
{ etherHistoryEntry 3 }
The value of sysUpTime at the start of the interval where this sample was
measured. If the probe keeps track of the time of day, it should start the first
sample of the history at such a time that when the next hour of the day begins,
a sample is started at that instant. Note that following this rule may require the
probe to delay collecting the first sample of the history, as each sample must be of
the same interval. Also note that the sample that is currently being collected is
not accessible in this table until the end of its interval.
etherHistoryDropEvents
{ etherHistoryEntry 4 }
The total number of events where packets were dropped by the probe due to lack
of resources during this interval. Note that this number is not the number of
packets dropped. It is the number of times this condition has been detected.
etherHistoryOctets
{ etherHistoryEntry 5 }
The total number of octets of data (including those in bad packets) received on
the network (excluding framing bits but including FCS octets).
etherHistoryPkts
{ etherHistoryEntry 6 }
The number of packets (including error packets) received during this sampling
interval.
etherHistoryBroadcastPkts
{ etherHistoryEntry 7 }
The number of good packets received during this sampling interval that were
directed to the broadcast address.

7–6 History Group

etherHistoryMulticastPkts
{ etherHistoryEntry 8 }
The number of good packets received during this sampling interval that were
directed to a multicast address. Note that this number does not include packets
addressed to the broadcast address.
etherHistoryCRCAlignErrors
{ etherHistoryEntry 9 }
The number of packets received during this sampling interval that had a length
(excluding framing bits but including FCS octets) between 64 and 1518 octets,
inclusive, but were not an integral number of octets in length or had a bad Frame
Check Sequence (FCS).
etherHistoryUndersizePkts
{ etherHistoryEntry 10 }
The number of packets received during this interval that were less than 64 octets
long (excluding framing bits but including FCS octets) and were otherwise well
formed.
etherHistoryOversizePkts
{ etherHistoryEntry 11 }
The number of packets received during this interval that were longer than 1518
octets (excluding framing bits but including FCS octets) but were otherwise well
formed.
etherHistoryFragments
{ etherHistoryEntry 12 }
The total number of packets received during this sampling interval that were
not an integral number of octets in length or that had a bad Frame Check
Sequence (FCS), and were less than 64 octets in length (excluding framing bits
but including FCS octets).
etherHistoryJabbers
{ etherHistoryEntry 13 }
The number of packets received during this interval that were longer than 1518
octets (excluding framing bits but including FCS octets), and were not an integral
number of octets in length or had a bad Frame Check Sequence (FCS).

History Group 7–7

etherHistoryCollisions
{ etherHistoryEntry 14 }
The best estimate of the total number of collisions on this Token Ring segment
during this interval.
etherHistoryUtilization
{ etherHistoryEntry 15 }
The best estimate of the mean physical layer network utilization on this interface
during this interval, in hundredths of a percent.

7–8 History Group

8
Alarm Group
The Alarm group requires the implementation of the Event group.
The Alarm group periodically takes statistical samples from variables in the
probe and compares them to configured thresholds. The alarm table stores
configuration entries that define each of the following parameters:
•

Variable

•

Polling period

•

Threshold

If a sample is found to cross the threshold values, an event is generated. Only
variables that resolve to an ASN.1 primitive type of INTEGER (INTEGER,
Counter, Gauge, or TimeTicks) may be monitored in this way.
This function has a hysteresis mechanism to limit the generation of events. This
mechanism generates one event as a threshold is crossed in the appropriate
direction. No more events are generated for that threshold until the opposite
threshold is crossed.
In the case of sampling a deltaValue, a probe may implement this mechanism
with more precision if it takes a delta sample twice per period. Each time it
takes a sample, it compares the sum of the latest two samples to the threshold.
This allows the detection of threshold crossings that span the sampling boundary.
Note that this does not require any special configuration of the threshold value.
It is suggested that probes implement this more precise algorithm.

Alarm Group 8–1

alarmTable
{ alarm 1 }
A list of alarm entries.
alarmEntry
{ alarmTable 1 }
A list of parameters that set up a periodic checking for alarm conditions:
Entry

Description

alarmIndex

INTEGER (1 . . . 65535)

alarmInterval

INTEGER

alarmVariable

OBJECT IDENTIFIER

alarmSampleType

INTEGER

alarmValue

INTEGER

alarmStartupAlarm

INTEGER

alarmRisingThreshold

INTEGER

alarmFallingThreshold

INTEGER

alarmRisingEventIndex

INTEGER (1 . . . 65535)

alarmFallingEventIndex

INTEGER (1 . . . 65535)

alarmOwner

OwnerString

alarmStatus

INTEGER

alarmIndex
{ alarmEntry 1 }
An index that uniquely identifies an entry in the alarm table. Each such entry
defines a diagnostic sample at a particular interval for an object on the device.
alarmInterval
{ alarmEntry 2 }
The interval in seconds where the data is sampled and compared with the rising
and falling thresholds. When setting this variable, care should be given to ensure
that the variable being monitored will not exceed 2^31 1 and roll over the
alarmValue object during the interval.
This object may not be modified if the associated alarmStatus object is equal to
valid(1).

8–2 Alarm Group

alarmVariable
{ alarmEntry 3 }
The object identifier of the particular variable to be sampled. Only variables that
resolve to an ASN.1 primitive type of INTEGER (INTEGER, Counter, Gauge,
or TimeTicks) may be sampled. SNMP access control is articulated entirely in
terms of the contents of MIB views. No access control mechanism exists that
can restrict the value of this object to identify only those objects that exist in a
particular MIB view. There is thus no acceptable means of restricting the read
access that could be obtained through the alarm mechanism. The probe must
only grant write access to this object in those views that have read access to all
objects on the probe.
During a set operation, if the supplied variable name is not available in the
selected MIB view, a badValue error must be returned. If at any time the variable
name of an established alarmEntry is no longer available in the selected MIB
view, the probe must change the status of this alarmEntry to invalid(4).
This object may not be modified if the associated alarmStatus object is equal to
valid(1).
alarmSampleType
{ alarmEntry 4 }
The method of sampling the selected variable and calculating the value to be
compared against the thresholds. If the value of this object is absoluteValue(1),
the value of the selected variable will be compared directly with the thresholds
at the end of the sampling interval. If the value of this object is deltaValue(2),
the value of the selected variable at the last sample will be subtracted from the
current value, and the difference compared with the thresholds.
This object may not be modified if the associated alarmStatus object is equal to
valid(1).
alarmValue
{ alarmEntry 5 }
The value of the statistic during the last sampling period. The value during the
current sampling period is not made available until the period is completed.

Alarm Group 8–3

alarmStartupAlarm
{ alarmEntry 6 }
The alarm that may be sent when this entry is first set to valid.
If . . .

And . . .

Then . . .

The first sample after this
entry becomes valid is
greater than or equal to
the risingThreshold

AlarmStartupAlarm is
equal to risingAlarm(1) or
risingOrFallingAlarm(3)

A single rising alarm will be
generated.

The first sample after this
entry becomes valid is
less than or equal to the
fallingThreshold

AlarmStartupAlarm is
equal to fallingAlarm(2) or
risingOrFallingAlarm(3)

A single falling alarm will be
generated.

This object may not be modified if the associated alarmStatus object is equal to
valid(1).
alarmRisingThreshold
{ alarmEntry 7 }
A threshold for the sampled statistic.
If . . .

And . . .

Then . . .

The current sampled
value is greater than or
equal to this threshold

The value at the last
sampling interval was less
than this threshold

A single event will be
generated.

The first sample after this
entry becomes valid is
greater than or equal to
this threshold

The associated alarmStartupAlarm is equal
to risingAlarm(1) or
risingOrFallingAlarm(3)

A single event will also be
generated.

After a rising event is generated, another such event will not be generated until
the sampled value falls below this threshold and reaches the alarmFallingThreshold.
This object may not be modified if the associated alarmStatus object is equal to
valid(1).

8–4 Alarm Group

alarmFallingThreshold
{ alarmEntry 8 }
A threshold for the sampled statistic.
If . . .

And . . .

Then . . .

The current sampled
value is less than or equal
to this threshold

The value at the last
sampling interval
was greater than this
threshold

A single event will be
generated.

The first sample after this
entry becomes valid is
less than or equal to this
threshold

The associated alarmStartupAlarm is equal
to fallingAlarm(2) or
risingOrFallingAlarm(3)

A single event will also be
generated.

After a falling event is generated, another such event will not be generated until
the sampled value rises above this threshold and reaches the alarmRisingThreshold.
This object may not be modified if the associated alarmStatus object is equal to
valid(1).
alarmRisingEventIndex
{ alarmEntry 9 }
The index of the eventEntry that is used when a rising threshold is crossed. The
eventEntry identified by a particular value of this index is the same as identified
by the same value of the eventIndex object. If there is no corresponding entry in
the eventTable, then no association exists. In particular, if this value is zero, no
associated event will be generated, as zero is not a valid event index.
This object may not be modified if the associated alarmStatus object is equal to
valid(1).
alarmFallingEventIndex
{ alarmEntry 10 }
The index of the eventEntry that is used when a falling threshold is crossed. The
eventEntry identified by a particular value of this index is the same as identified
by the same value of the eventIndex object. If there is no corresponding entry in
the eventTable, then no association exists. In particular, if this value is zero, no
associated event will be generated, as zero is not a valid event index.
This object may not be modified if the associated alarmStatus object is equal to
valid(1).

Alarm Group 8–5

alarmOwner
{ alarmEntry 11 }
The entity that configured this entry and is using the resources assigned to it.
alarmStatus
{ alarmEntry 12 }
The status of this alarm entry.

8–6 Alarm Group

9
Host Group
The Host group discovers new hosts on the network by keeping a list of source
and destination MAC addresses seen in good packets. For each of these
addresses, the Host group keeps a set of statistics. The hostControlTable controls
which interfaces this function is performed on, and contains some information
about the process. On behalf of each hostControlEntry, data is collected on
an interface and placed in both the hostTable and the hostTimeTable. If the
monitoring device finds itself short of resources, it may delete entries as needed.
It is suggested that the device delete the least recently used entries first. The
hostTable contains entries for each address discovered on a particular interface.
Each entry contains statistical data about that host. This table is indexed by the
MAC address of the host, through which a random access may be achieved.
The hostTimeTable contains data in the same format as the hostTable, and must
contain the same set of hosts, but is indexed using hostTimeCreationOrder rather
than hostAddress. The hostTimeCreationOrder is an integer that reflects the
relative order in which a particular entry was discovered and inserted into the
table. As this order (index) is among those entries currently in the table, the
index for a particular entry may change if an (earlier) entry is deleted. Thus, the
association between hostTimeCreationOrder and hostTimeEntry may be broken
at any time.
The hostTimeTable has two important uses. The first is the fast download of this
potentially large table. Because the index of this table runs from 1 to the size of
the table, inclusive, its values are predictable. This allows very efficient packing
of variables into SNMP PDUs and allows a table transfer to have multiple
packets outstanding. These benefits increase transfer rates tremendously.
The second use of the hostTimeTable is the efficient discovery by the management
station of new entries added to the table. After the management station has
downloaded the entire table, it knows that new entries will be added immediately
after the end of the current table. It can thus detect new entries there and
retrieve them easily.

Host Group 9–1

Because the association between hostTimeCreationOrder and hostTimeEntry
may be broken at any time, the management station must monitor the related
hostControlLastDeleteTime object. When the management station thus detects
a deletion, it must assume that any such associations have been broken, and
invalidate any it has stored locally. This includes restarting any download of
the hostTimeTable that may have been in progress, as well as rediscovering the
end of the hostTimeTable so that it may detect new entries. If the management
station does not detect the broken association, it may continue to refer to
a particular host by its creationOrder while unwittingly retrieving the data
associated with another host entirely. If this happens while downloading the host
table, the management station may fail to download all of the entries in the table.

hostControlTable
{ hosts 1 }
A list of host table control entries.
hostControlEntry
{ hostControlTable 1 }
A list of parameters that set up the discovery of hosts on a particular interface
and the collection of statistics about these hosts:
Entry

Description

hostControlIndex

INTEGER (1 . . . 65535)

hostControlDataSource

OBJECT IDENTIFIER

hostControlTableSize

INTEGER

hostControlLastDeleteTime

TimeTicks

hostControlOwner

OwnerString

hostControlStatus

INTEGER

hostControlIndex
{ hostControlEntry 1 }
An index that uniquely identifies an entry in the hostControl table. Each entry
defines a function that discovers hosts on a particular interface and places
statistics about them in the hostTable and the hostTimeTable on behalf of this
hostControlEntry.

9–2 Host Group

hostControlDataSource
{ hostControlEntry 2 }
This object identifies the source of the data for this instance of the host function.
This source can be any interface on this device. To identify a particular interface,
this object shall identify the instance of the ifIndex object for the desired
interface. For example, if an entry were to receive data from interface 1, this
object would be set to ifIndex.1.
The statistics in this group reflect all packets on the local network segment
attached to the identified interface.
This object may not be modified if the associated hostControlStatus object is equal
to valid(1).
hostControlTableSize
{ hostControlEntry 3 }
The number of hostEntries in the hostTable and the hostTimeTable associated
with this hostControlEntry.
hostControlLastDeleteTime
{ hostControlEntry 4 }
The value of sysUpTime when the last entry was deleted from the portion of the
hostTable associated with this hostControlEntry. If no deletions have occurred,
this value shall be zero.
hostControlOwner
{ hostControlEntry 5 }
The entity that configured this entry and is using the resources assigned to it.
hostControlStatus
{ hostControlEntry 6 }
The status of this hostControl entry.
If this object is not equal to valid(1), all associated entries in the hostTable,
hostTimeTable, and the hostTopNTable shall be deleted by the agent.
hostTable
{ hosts 2 }
A list of host entries.

Host Group 9–3

hostEntry
{ hostTable 1 }
A collection of statistics for a particular host that has been discovered on an
interface of this device:
Entry

Description

hostAddress

OCTET STRING

hostCreationOrder

INTEGER (1 . . . 65535)

hostIndex

INTEGER (1 . . . 65535)

hostInPkts

Counter

hostOutPkts

Counter

hostInOctets

Counter

hostOutOctets

Counter

hostOutErrors

Counter

hostOutBroadcastPkts

Counter

hostOutMulticastPkts

Counter

hostAddress
{ hostEntry 1 }
The physical address of this host.
hostCreationOrder
{ hostEntry 2 }
An index that defines the relative ordering of the creation time of hosts captured
for a particular hostControlEntry. This index shall be between 1 and n, where n
is the value of the associated hostControlTableSize.
The ordering of the indexes is based on the order of each entry’s insertion into the
table, where entries added earlier have a lower index value than entries added
later.
It is important to note that the order for a particular entry may change as
an (earlier) entry is deleted from the table. Because this order may change,
management stations should make use of the hostControlLastDeleteTime
variable in the hostControlEntry associated with the relevant portion of the
hostTable. By observing this variable, the management station may detect the
circumstances where a previous association between a value of hostCreationOrder
and a hostEntry may no longer hold.

9–4 Host Group

hostIndex
{ hostEntry 3 }
The set of collected host statistics of which this entry is a part. The set of
hosts identified by a particular value of this index is associated with the
hostControlEntry as identified by the same value of hostControlIndex.
hostInPkts
{ hostEntry 4 }
The number of packets without errors transmitted to this address since it was
added to the hostTable.
hostOutPkts
{ hostEntry 5 }
The number of packets including errors transmitted by this address since it was
added to the hostTable.
hostInOctets
{ hostEntry 6 }
The number of octets transmitted to this address since it was added to the
hostTable (excluding framing bits but including FCS octets), except for those
octets in packets that contained errors.
hostOutOctets
{ hostEntry 7 }
The number of octets transmitted by this address since it was added to the
hostTable (excluding framing bits but including FCS octets), including those
octets in packets that contained errors.
hostOutErrors
{ hostEntry 8 }
The number of error packets transmitted by this address since this host was
added to the hostTable.
hostOutBroadcastPkts
{ hostEntry 9 }
The number of good packets transmitted by this address that were directed to the
broadcast address since this host was added to the hostTable.

Host Group 9–5

hostOutMulticastPkts
{ hostEntry 10 }
The number of good packets transmitted by this address that were directed to
a multicast address since this host was added to the hostTable. Note that this
number does not include packets directed to the broadcast address.
hostTimeTable
{ hosts 3 }
A list of time-ordered host table entries.
hostTimeEntry
{ hostTimeTable 1 }
A collection of statistics for a particular host that has been discovered on an
interface of this device. This collection includes the relative ordering of the
creation time of this object:
Entry

Description

hostTimeAddress

OCTET STRING

hostTimeCreationOrder

INTEGER (1 . . . 65535)

hostTimeIndex

INTEGER (1 . . . 65535)

hostTimeInPkts

Counter

hostTimeOutPkts

Counter

hostTimeInOctets

Counter

hostTimeOutOctets

Counter

hostTimeOutErrors

Counter

hostTimeOutBroadcastPkts

Counter

hostTimeOutMulticastPkts

Counter

hostTimeAddress
{ hostTimeEntry 1 }
The physical address of this host.

9–6 Host Group

hostTimeCreationOrder
{ hostTimeEntry 2 }
An index that uniquely identifies an entry in the hostTime table among those
entries associated with the same hostControlEntry. This index shall be between 1
and n, where n is the value of the associated hostControlTableSize.
The ordering of the indexes is based on the order of each entry’s insertion into the
table, where entries added earlier have a lower index value than entries added
later. Thus, the management station has the ability to learn of new entries added
to this table without downloading the entire table.
It is important to note that the index for a particular entry may change as
an (earlier) entry is deleted from the table. Because this order may change,
management stations should make use of the hostControlLastDeleteTime
variable in the hostControlEntry associated with the relevant portion of the
hostTimeTable. By observing this variable, the management station may detect
the circumstances where a download of the table may have missed entries, and
where a previous association between a value of hostTimeCreationOrder and a
hostTimeEntry may no longer hold.
hostTimeIndex
{ hostTimeEntry 3 }
The set of collected host statistics of which this entry is a part. The set of
hosts identified by a particular value of this index is associated with the
hostControlEntry as identified by the same value of hostControlIndex.
hostTimeInPkts
{ hostTimeEntry 4 }
The number of packets without errors transmitted to this address since it was
added to the hostTimeTable.
hostTimeOutPkts
{ hostTimeEntry 5 }
The number of packets including errors transmitted by this address since it was
added to the hostTimeTable.
hostTimeInOctets
{ hostTimeEntry 6 }
The number of octets transmitted to this address since it was added to the
hostTimeTable (excluding framing bits but including FCS octets), except for those
octets in packets that contained errors.

Host Group 9–7

hostTimeOutOctets
{ hostTimeEntry 7 }
The number of octets transmitted by this address since it was added to the
hostTimeTable (excluding framing bits but including FCS octets), including those
octets in packets that contained errors.
hostTimeOutErrors
{ hostTimeEntry 8 }
The number of error packets transmitted by this address since this host was
added to the hostTimeTable.
hostTimeOutBroadcastPkts
{ hostTimeEntry 9 }
The number of good packets transmitted by this address that were directed to the
broadcast address since this host was added to the hostTimeTable.
hostTimeOutMulticastPkts
{ hostTimeEntry 10 }
The number of good packets transmitted by this address that were directed to a
multicast address since this host was added to the hostTimeTable. Note that this
number does not include packets directed to the broadcast address.

9–8 Host Group

10
Host Top N Group
The Host Top N group requires the implementation of the Host group.
The Host Top N group is used to prepare reports that describe the hosts that are
at the top of a list that has been ordered by one of their statistics. The available
statistics are samples of one of their base statistics, over an interval specified by
the management station. Thus, these statistics are rate based. The management
station also selects how many such hosts are reported.
The hostTopNControlTable is used to initiate the generation of such a report. The
management station may select the parameters of such a report. For example:
•

Which interface

•

Which statistic

•

How many hosts

•

The start time of the sampling

•

The stop time of the sampling

When the report is prepared, entries are created in the hostTopNTable associated
with the relevant hostTopNControlEntry. These entries are static for each report
after it has been prepared.

Host Top N Group 10–1

hostTopNControlTable
{ hostTopN 1 }
A list of top N host control entries.
hostTopNControlEntry
{ hostTopNControlTable 1 }
A set of parameters that control the creation of a report of the top N hosts
according to several metrics:
Entry

Description

hostTopNControlIndex

INTEGER (1 . . . 65535)

hostTopNHostIndex

INTEGER (1 . . . 65535)

hostTopNRateBase

INTEGER

hostTopNTimeRemaining

INTEGER

hostTopNDuration

INTEGER

hostTopNRequestedSize

INTEGER

hostTopNGrantedSize

INTEGER

hostTopNStartTime

TimeTicks

hostTopNOwner

OwnerString

hostTopNStatus

INTEGER

hostTopNControlIndex
{ hostTopNControlEntry 1 }
An index that uniquely identifies an entry in the hostTopNControl table. Each
entry defines one top N report prepared for one interface.
hostTopNHostIndex
{ hostTopNControlEntry 2 }
The host table where a top N report will be prepared on behalf of this entry. The
host table identified by a particular value of this index is associated with the
same host table as identified by the same value of hostIndex.
This object may not be modified if the associated hostTopNStatus object is equal
to valid(1).

10–2 Host Top N Group

hostTopNRateBase
{ hostTopNControlEntry 3 }
hostTopNInPkts(1)
hostTopNOutPkts(2)
hostTopNInOctets(3)
hostTopNOutOctets(4)
hostTopNOutErrors(5)
hostTopNOutBroadcastPkts(6)
hostTopNOutMulticastPkts(7)
The variable for each host on which the hostTopNRate variable is based.
This object may not be modified if the associated hostTopNStatus object is equal
to valid(1).
hostTopNTimeRemaining
{ hostTopNControlEntry 4 }
The number of seconds left in the report currently being collected. When this
object is modified by the management station, a new collection is started, possibly
aborting a currently running report. The new value is used as the requested
duration of this report, which is loaded into the associated hostTopNDuration
object.
When this object is set to a nonzero value, any associated hostTopNEntries shall
be made inaccessible by the monitor. While the value of this object is nonzero,
it decrements by one per second until it reaches zero. During this time, all
associated hostTopNEntries shall remain inaccessible. At the time that this
object decrements to zero, the report is made accessible in the hostTopNTable.
Thus, the hostTopNTable needs to be created only at the end of the collection
interval.
The default value of hostTopNTimeRemaining is 0 (zero).
hostTopNDuration
{ hostTopNControlEntry 5 }
The number of seconds this report has collected during the last sampling interval.
If this report is currently being collected, the number of seconds this report is
being collected during this sampling interval.
When the associated hostTopNTimeRemaining object is set, this object shall be
set by the probe to the same value and shall not be modified until the next time
the hostTopNTimeRemaining is set.
This value shall be zero if no reports have been requested for this hostTopNControlEntry. The default value of hostTopNDuration is 0 (zero).

Host Top N Group 10–3

hostTopNRequestedSize
{ hostTopNControlEntry 6 }
The maximum number of hosts requested for the top N table.
When this object is created or modified, the probe should set hostTopNGrantedSize as closely to this object as is possible for the particular probe implementation
and available resources.
The default value for hostTopNRequestedSize is 10.
hostTopNGrantedSize
{ hostTopNControlEntry 7 }
The maximum number of hosts in the top N table.
When the associated hostTopNRequestedSize object is created or modified, the
probe should set this object as closely to the requested value as is possible for
the particular implementation and available resources. The probe must not lower
this value except as a result of a set to the associated hostTopNRequestedSize
object.
Hosts with the highest value of hostTopNRate shall be placed in this table in
decreasing order of this rate until there is no more room or until there are no
more hosts.
hostTopNStartTime
{ hostTopNControlEntry 8 }
The value of sysUpTime when this top N report was last started. In other words,
this is the time that the associated hostTopNTimeRemaining object was modified
to start the requested report.
hostTopNOwner
{ hostTopNControlEntry 9 }
The entity that configured this entry and is using the resources assigned to it.
hostTopNStatus
{ hostTopNControlEntry 10 }
The status of this hostTopNControl entry.
If this object is not equal to valid(1), all associated hostTopNEntries shall be
deleted by the agent.

10–4 Host Top N Group

hostTopNTable
{ hostTopN 2 }
A list of top N host entries.
hostTopNEntry
{ hostTopNTable 1 }
A set of statistics for a host that is part of a top N report:
Entry

Description

hostTopNReport

INTEGER (1 . . . 65535)

hostTopNIndex

INTEGER (1 . . . 65535)

hostTopNAddress

OCTET STRING

hostTopNRate

INTEGER

hostTopNReport
{ hostTopNEntry 1 }
This object identifies the top N report of which this entry is a part. The set of
hosts identified by a particular value of this object is part of the same report as
identified by the same value of the hostTopNControlIndex object.
hostTopNIndex
{ hostTopNEntry 2 }
An index that uniquely identifies an entry in the hostTopNTable among those in
the same report. This index is between 1 and n, where n is the number of entries
in this table.
Increasing values of hostTopNIndex shall be assigned to entries with decreasing
values of hostTopNRate until index N is assigned to the entry with the lowest
value of hostTopNRate or there are no more hostTopNEntries.
hostTopNAddress
{ hostTopNEntry 3 }
The physical address of this host.
hostTopNRate
{ hostTopNEntry 4 }
The amount of change in the selected variable during this sampling interval. The
selected variable is this host’s instance of the object selected by hostTopNRateBase.

Host Top N Group 10–5

11
Matrix Group
The Matrix group consists of the matrixControlTable, matrixSDTable, and
the matrixDSTable. These tables store statistics for a particular conversation
between two addresses. As the device detects a new conversation, including those
to a non-unicast address, it creates a new entry in both of the matrix tables. It
must only create new entries based on information received in good packets.
If the monitoring device finds itself short of resources, it may delete entries as
needed. It is suggested that the device delete the least recently used entries first.

Matrix Group 11–1

matrixControlTable
{ matrix 1 }
A list of information entries for the traffic matrix on each interface.
matrixControlEntry
{ matrixControlTable 1 }
Information about a traffic matrix on a particular interface:
Entry

Description

matrixControlIndex

INTEGER (1 . . . 65535)

matrixControlDataSource

OBJECT IDENTIFIER

matrixControlTableSize

INTEGER

matrixControlLastDeleteTime

TimeTick

matrixControlOwner

OwnerString

matrixControlStatus

INTEGER

matrixControlIndex
{ matrixControlEntry 1 }
An index that uniquely identifies an entry in the matrixControl table. Each such
entry defines a function that discovers conversations on a particular interface
and places statistics about them in the matrixSDTable and the matrixDSTable on
behalf of this matrixControlEntry.
matrixControlDataSource
{ matrixControlEntry 2 }
This object identifies the source of the data from which this entry creates a traffic
matrix. This source can be any interface on this device. To identify a particular
interface, this object shall identify the instance of the ifIndex object for the
desired interface. For example, if an entry were to receive data from interface 1,
this object would be set to ifIndex.1.
The statistics in this group reflect all packets on the local network segment
attached to the identified interface.
This object may not be modified if the associated matrixControlStatus object is
equal to valid(1).

11–2 Matrix Group

matrixControlTableSize
{ matrixControlEntry 3 }
The number of matrixSDEntries in the matrixSDTable for this interface. This
must also be the value of the number of entries in the matrixDSTable for this
interface.
matrixControlLastDeleteTime
{ matrixControlEntry 4 }
The value of sysUpTime when the last entry was deleted from the portion of the
matrixSDTable or matrixDSTable associated with this matrixControlEntry. If no
deletions have occurred, this value shall be zero.
matrixControlOwner
{ matrixControlEntry 5 }
The entity that configured this entry and is therefore using the resources assigned
to it.
matrixControlStatus
{ matrixControlEntry 6 }
The status of this matrixControl entry. If this object is not equal to valid(1), all
associated entries in the matrixSDTable and the matrixDSTable shall be deleted
by the agent.
matrixSDTable
{ matrix 2 }
A list of traffic matrix entries indexed by source and destination MAC address.
matrixSDEntry
{ matrixSDTable 1 }
A collection of statistics for communications between two addresses on a
particular interface:
Entry

Description

matrixSDSourceAddress

OCTET STRING

matrixSDDestAddress

OCTET STRING

matrixSDIndex

INTEGER (1 . . . 65535)

matrixSDPkts

Counter

matrixSDOctets

Counter

matrixSDErrors

Counter

Matrix Group 11–3

matrixSDSourceAddress
{ matrixSDEntry 1 }
The source physical address.
matrixSDDestAddress
{ matrixSDEntry 2 }
The destination physical address.
matrixSDIndex
{ matrixSDEntry 3 }
The set of collected matrix statistics of which this entry is a part. The set of
matrix statistics identified by a particular value of this index is associated
with the same matrixControlEntry as identified by the same value of
matrixControlIndex.
matrixSDPkts
{ matrixSDEntry 4 }
The number of packets transmitted from the source address to the destination
address (this number includes error packets).
matrixSDOctets
{ matrixSDEntry 5 }
The number of octets (excluding framing bits but including FCS octets) contained
in all packets transmitted from the source address to the destination address.
matrixSDErrors
{ matrixSDEntry 6 }
The number of error packets transmitted from the source address to the
destination address.
Traffic matrix tables from destination to source always goes through destination.
matrixDSTable
{ matrix 3 }
A list of traffic matrix entries indexed by destination and source MAC address.

11–4 Matrix Group

matrixDSEntry
{ matrixDSTable 1 }
A collection of statistics for communications between two addresses on a
particular interface:
Entry

Description

matrixDSSourceAddress

OCTET STRING

matrixDSDestAddress

OCTET STRING

matrixDSIndex

INTEGER (1 . . . 65535)

matrixDSPkts

Counter

matrixDSOctets

Counter

matrixDSErrors

Counter

matrixDSSourceAddress
{ matrixDSEntry 1 }
The source physical address.
matrixDSDestAddress
{ matrixDSEntry 2 }
The destination physical address.
matrixDSIndex
{ matrixDSEntry 3 }
The set of collected matrix statistics of which this entry is a part. The set of
matrix statistics identified by a particular value of this index is associated
with the same matrixControlEntry as identified by the same value of
matrixControlIndex.
matrixDSPkts
{ matrixDSEntry 4 }
The number of packets transmitted from the source address to the destination
address (this number includes error packets).
matrixDSOctets
{ matrixDSEntry 5 }
The number of octets (excluding framing bits but including FCS octets) contained
in all packets transmitted from the source address to the destination address.

Matrix Group 11–5

matrixDSErrors
{ matrixDSEntry 6 }
The number of error packets transmitted from the source address to the
destination address.

11–6 Matrix Group

12
Filter Group
The Filter group allows packets to be captured with an arbitrary filter expression.
A logical data and event stream or ‘‘channel’’ is formed by the packets that match
the filter expression.
This filter mechanism allows the creation of an arbitrary logical expression with
which to filter packets. Each filter associated with a channel is ORed with the
others. Within a filter, any bits checked in the data and status are ANDed with
respect to other bits in the same filter. The NotMask also allows for checking
for inequality. Finally, the channelAcceptType object allows for inversion of the
whole equation.
The channel can be turned on or off, and can also generate events when packets
pass through it.

Filter Group 12–1

filterTable
{ filter 1 }
A list of packet filter entries.
filterEntry
{ filterTable 1 }
A set of parameters for a packet filter applied on a particular interface:
Entry

Description

filterIndex

INTEGER (1 . . . 65535)

filterChannelIndex

INTEGER (1 . . . 65535)

filterPktDataOffset

INTEGER

filterPktData

OCTET STRING

filterPktDataMask

OCTET STRING

filterPktDataNotMask

OCTET STRING

filterPktStatus

INTEGER

filterPktStatusMask

INTEGER

filterPktStatusNotMask

INTEGER

filterOwner

OwnerString

filterStatus

INTEGER

filterIndex
{ filterEntry 1 }
An index that uniquely identifies an entry in the filter table. Each entry defines
one filter that is to be applied to every packet received on an interface.
filterChannelIndex
{ filterEntry 2 }
This object identifies the channel of which this filter is a part. The filters
identified by a particular value of this object are associated with the same channel
as identified by the same value of the channelIndex object.

12–2 Filter Group

filterPktDataOffset
{ filterEntry 3 }
The offset from the beginning of each packet where a match of packet data will
be attempted. This offset is measured from the point in the physical layer packet
after the framing bits, if any. For example, in an Token Ring frame, this point is
at the beginning of the destination MAC address.
This object may not be modified if the associated filterStatus object is equal to
valid(1).
The default value for filterPktDataOffset is 0 (zero).
filterPktData
{ filterEntry 4 }
The data that is to be matched with the input packet.
For each packet received, this filter and the accompanying filterPktDataMask
and filterPktDataNotMask will be adjusted for the offset. The only bits relevant
to this match algorithm are those that have the corresponding filterPktDataMask
bit equal to one. The following three rules are then applied to every packet:
Rule

If . . .

And . . .

Then . . .

The packet is too short

Does not have data
corresponding to part of
the filterPktData

The packet will fail this
data match.

The bit from the packet
is not equal to the
corresponding bit from
the filterPktData

For each relevant bit
from the packet with
the corresponding
filterPktDataNotMask
bit set to zero

The packet will fail this
data match.

For every relevant
bit from the packet
with the corresponding
filterPktDataNotMask
bit set to one

The bit from the
packet is equal to the
corresponding bit from
the filterPktData

The packet will fail this
data match.

Any packets that have not failed any of the three matches above have passed this
data match. This object may not be modified if the associated filterStatus object
is equal to valid(1).

Filter Group 12–3

filterPktDataMask
{ filterEntry 5 }
The mask that is applied to the match process. After adjusting this mask for
the offset, only those bits in the received packet that correspond to bits set in
this mask are relevant for further processing by the match algorithm. The offset
is applied to filterPktDataMask in the same way it is applied to the filter. For
the purposes of the matching algorithm, if the associated filterPktData object is
longer than this mask, this mask is conceptually extended with 1 bits until it
reaches the length of the filterPktData object.
This object may not be modified if the associated filterStatus object is equal to
valid(1).
filterPktDataNotMask
{ filterEntry 6 }
The inversion mask that is applied to the match process. After adjusting this
mask for the offset, those relevant bits in the received packet that correspond
to bits cleared in this mask must all be equal to their corresponding bits in the
filterPktData object for the packet to be accepted. In addition, at least one of
those relevant bits in the received packet that correspond to bits set in this mask
must be different to its corresponding bit in the filterPktData object.
For the purposes of the matching algorithm, if the associated filterPktData object
is longer than this mask, this mask is conceptually extended with 0 bits until it
reaches the length of the filterPktData object.
This object may not be modified if the associated filterStatus object is equal to
valid(1).
filterPktStatus
{ filterEntry 7 }
The status that is to be matched with the input packet. The only bits relevant to
this match algorithm are those that have the corresponding filterPktStatusMask
bit equal to one.
The following two rules are then applied to every packet:
1. For each relevant bit from the packet status with the corresponding
filterPktStatusNotMask bit set to zero, if the bit from the packet status is
not equal to the corresponding bit from the filterPktStatus, then the packet
will fail this status match.

12–4 Filter Group

2. If for every relevant bit from the packet status with the corresponding
filterPktStatusNotMask bit set to one, the bit from the packet status is
equal to the corresponding bit from the filterPktStatus, then the packet will
fail this status match.
Any packets that have not failed one of the two matches above have passed this
status match.
The value of the packet status is a sum. This sum initially takes the value zero.
Then, for each error (E) that has been discovered in this packet, 2 raised to a
value representing E is added to the sum. The errors and the bits that represent
them are dependent on the media type of the interface that this channel is
receiving packets from.
The errors defined for a packet captured off of an Token Ring interface are as
follows:
0 — Packet is longer than 1518 octets
1 — Packet is shorter than 64 octets
2 — Packet experienced a CRC or Alignment error
For example, an Token Ring fragment would have a value of 6 (2^1 + 2^2).
As this MIB is expanded to new media types, this object will have other mediaspecific errors defined.
For the purposes of this status matching algorithm, if the packet status is longer
than this object, filterPktStatus is conceptually extended with 0 bits until it
reaches the size of the packet status.
This object may not be modified if the associated filterStatus object is equal to
valid(1).
filterPktStatusMask
{ filterEntry 8 }
The mask that is applied to the status match process. Only those bits in the
received packet that correspond to bits set in this mask are relevant for further
processing by the status match algorithm. For the purposes of the matching
algorithm, if the associated filterPktStatus object is longer than this mask,
this mask is conceptually extended with 1 bits until it reaches the size of the
filterPktStatus. In addition, if a packet status is longer than this mask, this
mask is conceptually extended with 0 bits until it reaches the size of the packet
status.
This object may not be modified if the associated filterStatus object is equal to
valid(1).

Filter Group 12–5

filterPktStatusNotMask
{ filterEntry 9 }
The inversion mask that is applied to the status match process. Those relevant
bits in the received packet status that correspond to bits cleared in this mask
must all be equal to their corresponding bits in the filterPktStatus object for
the packet to be accepted. In addition, at least one of those relevant bits in the
received packet status that correspond to bits set in this mask must be different
to its corresponding bit in the filterPktStatus object for the packet to be accepted.
For the purposes of the matching algorithm, if the associated filterPktStatus
object or a packet status is longer than this mask, this mask is conceptually extended with 0 bits until it reaches the longer of the lengths of the filterPktStatus
object or the packet status.
This object may not be modified if the associated filterStatus object is equal to
valid(1).
filterOwner
{ filterEntry 10 }
The entity that configured this entry and is using the resources assigned to it.
filterStatus
{ filterEntry 11 }
The status of this filter entry.
channelTable
{ filter 2 }
A list of packet channel entries.
channelEntry
{ channelTable 1 }
A set of parameters for a packet channel applied on a particular interface:
Entry

Description

channelIndex

INTEGER (1 . . . 65535)

channelIfIndex

INTEGER (1 . . . 65535)

channelAcceptType

INTEGER

channelDataControl

INTEGER

channelTurnOnEventIndex

INTEGER (0 . . . 65535)

12–6 Filter Group

Entry

Description

channelTurnOffEventIndex

INTEGER (0 . . . 65535)

channelEventIndex

INTEGER (0 . . . 65535)

channelEventStatus

INTEGER

channelMatches

Counter

channelDescription

DisplayString (SIZE (0 . . . 127))

channelOwner

OwnerString

channelStatus

INTEGER

channelIndex
{ channelEntry 1 }
An index that uniquely identifies an entry in the channel table. Each entry
defines one channel as a logical data and event stream.
channelIfIndex
{ channelEntry 2 }
The value of this object uniquely identifies the interface on this remote network
monitoring device to which the associated filters are applied to allow data into
this channel. The interface identified by a particular value of this object is the
same interface as identified by the same value of the ifIndex object. The filters in
this group are applied to all packets on the local network segment attached to the
identified interface.
This object may not be modified if the associated channelStatus object is equal to
valid(1).
channelAcceptType
{ channelEntry 3 }
This object controls the action of the filters associated with this channel. If this
object is equal to acceptMatched(1), packets will be accepted to this channel
if they are accepted by both the packet data and packet status matches of an
associated filter. If this object is equal to acceptFailed(2), packets will be accepted
to this channel only if they fail either the packet data match or the packet status
match of each of the associated filters.
This object may not be modified if the associated channelStatus object is equal to
valid(1).

Filter Group 12–7

channelDataControl
{ channelEntry 4 }
This object controls the flow of data through this channel. If this object is on(1),
data, status, and events flow through this channel. If this object is off(2), data,
status, and events will not flow through this channel.
The default value for channelDataControl is off.
channelTurnOnEventIndex
{ channelEntry 5 }
The value of this object identifies the event that is configured to turn the
associated channelDataControl from OFF to ON when the event is generated.
The event identified by a particular value of this object is the same event as
identified by the same value of the eventIndex object. If there is no corresponding
entry in the eventTable, then no association exists. In fact, if no event is intended
for this channel, channelTurnOnEventIndex must be set to zero, a nonexistent
event index.
This object may not be modified if the associated channelStatus object is equal to
valid(1).
channelTurnOffEventIndex
{ channelEntry 6 }
The value of this object identifies the event that is configured to turn the
associated channelDataControl from ON to OFF when the event is generated.
The event identified by a particular value of this object is the same event as
identified by the same value of the eventIndex object. If there is no corresponding
entry in the eventTable, then no association exists. In fact, if no event is intended
for this channel, channelTurnOffEventIndex must be set to zero, a nonexistent
event index.
This object may not be modified if the associated channelStatus object is equal to
valid(1).
channelEventIndex
{ channelEntry 7 }
The value of this object identifies the event that is configured to be generated
when the associated channelDataControl is ON and a packet is matched. The
event identified by a particular value of this object is the same event as identified
by the same value of the eventIndex object. If there is no corresponding entry in
the eventTable, then no association exists. In fact, if no event is intended for this
channel, channelEventIndex must be set to zero, a nonexistent event index.

12–8 Filter Group

This object may not be modified if the associated channelStatus object is equal to
valid(1).
channelEventStatus
{ channelEntry 8 }
The event status of this channel.
If this channel is configured to generate events when packets are matched, a
means of controlling the flow of those events is often needed. When this object
is equal to eventReady(1), a single event may be generated, after which this
object will be set by the probe to eventFired(2). While in the eventFired(2) state,
no events will be generated until the object is modified to eventReady(1) (or
eventAlwaysReady(3)). The management station can thus easily respond to a
notification of an event by reenabling this object.
If the management station wants to disable this flow control and allow events to
be generated at will, this object may be set to eventAlwaysReady(3).
Note
Disabling the flow control is not recommended as it can result in high
network traffic or other performance problems.

The default value for channelEventStatus is eventReady.
channelMatches
{ channelEntry 9 }
The number of times this channel has matched a packet. Note that this object is
updated even when channelDataControl is set to OFF.
channelDescription
{ channelEntry 10 }
A comment describing this channel.
channelOwner
{ channelEntry 11 }
The entity that configured this entry and is using the resources assigned to it.
channelStatus
{ channelEntry 12 }
The status of this channel entry.

Filter Group 12–9

13
Packet Capture Group
The Packet Capture group requires implementation of the Filter group.
The Packet Capture group allows packets to be captured each time a filter is
matched. The bufferControlTable controls the captured packets output from a
channel that is associated with it. The captured packets are placed in entries in
the captureBufferTable. These entries are associated with the bufferControlEntry
on whose behalf they were stored.

Packet Capture Group 13–1

bufferControlTable
{ capture 1 }
A list of buffer control entries.
bufferControlEntry
{ bufferControlTable 1 }
A set of parameters that control the collection of a stream of packets that have
matched filters:
Entry

Description

bufferControlIndex

INTEGER (1 . . . 65535)

bufferControlChannelIndex

INTEGER (1 . . . 65535)

bufferControlFullStatus

INTEGER

bufferControlFullAction

INTEGER

bufferControlCaptureSliceSize

INTEGER

bufferControlDownloadSliceSize

INTEGER

bufferControlDownloadOffset

INTEGER

bufferControlMaxOctetsRequested

INTEGER

bufferControlMaxOctetsGranted

INTEGER

bufferControlCapturedPackets

INTEGER

bufferControlTurnOnTime

TimeTicks

bufferControlOwner

OwnerString

bufferControlStatus

INTEGER

bufferControlIndex
{ bufferControlEntry 1 }
An index that uniquely identifies an entry in the bufferControl table. The value
of this index shall never be zero. Each entry defines one set of packets that is
captured and controlled by one or more filters.
bufferControlChannelIndex
{ bufferControlEntry 2 }
An index that identifies the channel that is the source of packets for this
bufferControl table. The channel identified by a particular value of this index
is the same as identified by the same value of the channelIndex object.
This object may not be modified if the associated bufferControlStatus object is
equal to valid(1).
13–2 Packet Capture Group

bufferControlFullStatus
{ bufferControlEntry 3 }
This object shows whether the buffer has room to accept new packets or if it is
full.
If . . .

And . . .

Then . . .

The status is spaceAvailable(1)

–

The buffer is accepting new
packets normally.

The status is full(2)

The associated bufferControlFullAction object is
wrapWhenFull

The buffer is accepting new
packets by deleting enough of
the oldest packets to make room
for new ones as they arrive.

The status is full(2)

The bufferControlFullAction object is
lockWhenFull

The buffer has stopped
collecting packets.

When this object is set to full(2), the probe must not later set it to spaceAvailable(1) except in the case of a significant gain in resources such as an increase of
bufferControlOctetsGranted. In particular, the wrap-mode action of deleting old
packets to make room for newly arrived packets must not affect the value of this
object.
bufferControlFullAction
{ bufferControlEntry 4 }
Controls the action of the buffer when it reaches the full status. When in the
lockWhenFull(1) state a packet is added to the buffer that fills the buffer, the
bufferControlFullStatus will be set to full(2) and this buffer will stop capturing
packets.

Packet Capture Group 13–3

bufferControlCaptureSliceSize
{ bufferControlEntry 5 }
The maximum number of octets of each packet that will be saved in this capture
buffer. For example:
If . . .

And . . .

Then . . .

A 1500 octet packet is
received by the probe

This object is set to 500

Only 500 octets of the packet
will be stored in the associated
capture buffer.

This variable is set to 0

–

The capture buffer will save as
many octets as is possible.

This object may not be modified if the associated bufferControlStatus object is
equal to valid(1).
The default value for bufferControlCaptureSize is 100.
bufferControlDownloadSliceSize
{ bufferControlEntry 6 }
The maximum number of octets of each packet in this capture buffer that will be
returned in an SNMP retrieval of that packet. For example:
If . . .

And . . .

Then . . .

500 octets of a packet
have been stored in the
associated capture buffer,
the associated bufferControlDownloadOffset is
0

This object is set to 100

The captureBufferPacket object
that contains the packet will
contain only the first 100 octets
of the packet.

A prudent manager will take into account possible interoperability or
fragmentation problems that may occur if the download slice size is set too
large. In particular, conformant SNMP implementations are not required to
accept messages whose length exceeds 484 octets, although they are encouraged
to support larger datagrams whenever feasible.
The default value for bufferControlDownloadSliceSize is 100.

13–4 Packet Capture Group

bufferControlDownloadOffset
{ bufferControlEntry 7 }
The offset of the first octet of each packet in this capture buffer that will be
returned in an SNMP retrieval of that packet. For example:
If . . .

And . . .

Then . . .

500 octets of a packet
have been stored in the
associated capture buffer

This object is set to 100

The captureBufferPacket object
that contains the packet will
contain bytes starting 100
octets into the packet.

The default value for bufferControlDownloadOfset is 0 (zero).
bufferControlMaxOctetsRequested
{ bufferControlEntry 8 }
The requested maximum number of octets to be saved in this captureBuffer,
including any implementation-specific overhead. If this variable is set to –1, the
capture buffer will save as many octets as is possible.
When this object is created or modified, the probe should set bufferControlMaxOctetsGranted as closely to this object as is possible for the particular probe
implementation and available resources. However, if the object has the special
value of –1, the probe must set bufferControlMaxOctetsGranted to –1.
The default value for bufferControlMaxOctetsRequested is –1.
bufferControlMaxOctetsGranted
{ bufferControlEntry 9 }
The maximum number of octets that can be saved in this captureBuffer, including
overhead. If this variable is –1, the capture buffer will save as many octets as
possible.
When the bufferControlMaxOctetsRequested object is created or modified, the
probe should set this object as closely to the requested value as is possible for the
particular probe implementation and available resources. However, if the request
object has the special value of –1, the probe must set this object to –1. The probe
must not lower this value except as a result of a modification to the associated
bufferControlMaxOctetsRequested object.
When this maximum number of octets is reached and a new packet is to be
added to this capture buffer and the corresponding bufferControlFullAction is set
to wrapWhenFull(2), enough of the oldest packets associated with this capture
buffer shall be deleted by the agent so that the new packet can be added. If the
corresponding bufferControlFullAction is set to lockWhenFull(1), the new packet
Packet Capture Group 13–5

shall be discarded. In either case, the probe must set bufferControlFullStatus to
full(2).
When the value of this object changes to a value less than the current
value, entries are deleted from the captureBufferTable associated with this
bufferControlEntry. Enough of the oldest of these captureBufferEntries shall be
deleted by the agent so that the number of octets used remains less than or equal
to the new value of this object.
When the value of this object changes to a value greater than the current value,
the number of associated captureBufferEntries may be allowed to grow.
bufferControlCapturedPackets
{ bufferControlEntry 10 }
The number of packets currently in this captureBuffer.
bufferControlTurnOnTime
{ bufferControlEntry 11 }
The value of sysUpTime when this capture buffer was first turned on.
bufferControlOwner
{ bufferControlEntry 12 }
The entity that configured this entry and is using the resources assigned to it.
bufferControlStatus
{ bufferControlEntry 13 }
The status of this buffer control entry.
captureBufferTable
{ capture 2 }
A list of packets captured off of a channel.
captureBufferEntry
{ captureBufferTable 1 }
A packet captured off of an attached network:
Entry

Description

captureBufferControlIndex

INTEGER (1 . . . 65535)

captureBufferIndex

INTEGER

captureBufferPacketID

INTEGER

13–6 Packet Capture Group

Entry

Description

captureBufferPacketData

OCTET STRING

captureBufferPacketLength

INTEGER

captureBufferPacketTime

INTEGER

captureBufferPacketStatus

INTEGER

captureBufferControlIndex
{ captureBufferEntry 1 }
The index of the bufferControlEntry with which this packet is associated.
captureBufferIndex
{ captureBufferEntry 2 }
An index that uniquely identifies an entry in the captureBuffer table associated
with a particular bufferControlEntry. This index will start at 1 and increase by
one for each new packet added with the same captureBufferControlIndex.
captureBufferPacketID
{ captureBufferEntry 3 }
An index that describes the order of packets that are received on a particular
interface. The packetID of a packet captured on an interface is defined to be
greater than the packetIDs of all packets captured previously on the same
interface. As the captureBufferPacketID object has a maximum positive value of
2^31 1, any captureBufferPacketID object shall have the value of the associated
packet’s packetID mod 2^31.
captureBufferPacketData
{ captureBufferEntry 4 }
The data inside the packet. It starts at the beginning of the packet plus any
offset specified in the associated bufferControlDownloadOffset, including any link
level headers.
The length of the data in this object is . . .

Minus . . .

The minimum length of the captured packet

The offset

The length of the associated bufferControlCaptureSliceSize

The offset

And the associated
bufferControlDownloadSliceSize.

If this minimum is less than zero, this object shall have a length of zero.

Packet Capture Group 13–7

captureBufferPacketLength
{ captureBufferEntry 5 }
The actual length (off the wire) of the packet stored in this entry, including FCS
octets.
captureBufferPacketTime
{ captureBufferEntry 6 }
The number of milliseconds that had passed since this capture buffer was first
turned on when this packet was captured.
captureBufferPacketStatus
{ captureBufferEntry 7 }
A value which indicates the error status of this packet.
The value of this object is defined in the same way as filterPacketStatus. The
value is a sum. This sum initially takes the value zero. Then, for each error (E)
that has been discovered in this packet, 2 raised to a value representing E is
added to the sum.
The errors defined for a packet captured off of an Token Ring interface are as
follows:
0

Packet is longer than 1518 octets

Packet is shorter than 64 octets

Packet experienced a CRC or Alignment error

First packet in this capture buffer after it was detected that some packets were not
processed correctly

For example, an Token Ring fragment would have a value of 6 (2^1 + 2^2).
As this MIB is expanded to new media types, this object will have other mediaspecific errors defined.

13–8 Packet Capture Group

14
Event Group
The Event group controls the generation and notification of events from this
device. Each entry in the eventTable describes the parameters of the event that
can be triggered. Each event entry is fired by an associated condition located
elsewhere in the MIB. An event entry may also be associated with a function
elsewhere in the MIB that will be executed when the event is generated. For
example, a channel may be turned on or off by the firing of an event.
Each eventEntry may optionally specify that a log entry be created on its behalf
whenever the event occurs. Each entry may also specify that notification should
occur by way of SNMP trap messages. In this case, the community for the trap
message is given in the associated eventCommunity object. The enterprise and
specific trap fields of the trap are determined by the condition that triggered the
event. Three traps are defined in PROBEwatch: risingAlarm, fallingAlarm, and
packetMatch. If the eventTable is triggered by a condition specified elsewhere,
the enterprise and specific trap fields must be specified for traps generated for
that condition.

Event Group 14–1

eventTable
{ event 1 }
A list of events to be generated.
eventEntry
{ eventTable 1 }
A set of parameters that describe an event to be generated when certain
conditions are met:
Entry

Description

eventIndex

INTEGER (1 . . . 65535)

eventDescription

DisplayString (SIZE (0 . . . 127))

eventType

INTEGER

eventCommunity

OCTET STRING (SIZE (0 . . . 127))

eventLastTimeSent

TimeTicks

eventOwner

OwnerString

eventStatus

INTEGER

eventIndex
{ eventEntry 1 }
An index that uniquely identifies an entry in the event table. Each entry defines
one event that is to be generated when the appropriate conditions occur.
eventDescription
{ eventEntry 2 }
A comment describing this event entry.
eventType
{ eventEntry 3 }
The type of notification that the probe will make about this event. In the case of
log, an entry is made in the log table for each event. In the case of snmp-trap, an
SNMP trap is sent to one or more management stations.
eventCommunity
{ eventEntry 4 }
If an SNMP trap is to be sent, it will be sent to the SNMP community specified
by this octet string. In the future, this table will be extended to include the party
security mechanism. This object shall be set to a string of length zero if that
mechanism is to be used to specify the destination of the trap.
14–2 Event Group

eventLastTimeSent
{ eventEntry 5 }
The value of sysUpTime at the time this event entry last generated an event. If
this entry has not generated any events, this value will be zero.
eventOwner
{ eventEntry 6 }
The entity that configured this entry and is using the resources assigned to it.
If this object contains a string starting with ‘‘monitor’’ and has associated entries
in the log table, all connected management stations should retrieve those log
entries, as they may have significance to all management stations connected to
this device.
eventStatus
{ eventEntry 7 }
The status of this event entry.
If this object is not equal to valid(1), all associated log entries shall be deleted by
the agent.
logTable
{ event 2 }
A list of events that have been logged.
logEntry
{ logTable 1 }
A set of data describing an event that has been logged:
Entry

Description

logEventIndex

INTEGER (1 . . . 65535)

logIndex

INTEGER

logDescription

DisplayString (SIZE (0 . . . 255))

logEventIndex
{ logEntry 1 }
The event entry that generated this log entry. The log identified by a particular
value of this index is associated with the same eventEntry as identified by the
same value of eventIndex.

Event Group 14–3

logIndex
{ logEntry 2 }
An index that uniquely identifies an entry in the log table among those generated
by the same eventEntries. These indexes are assigned beginning with 1 and
increase by one with each new log entry. The association between values of
logIndex and logEntries is fixed for the lifetime of each logEntry. The agent may
choose to delete the oldest instances of logEntry as required because of lack of
memory. It is an implementation-specific matter as to when this deletion may
occur.
logTime
{ logEntry 3 }
The value of sysUpTime when this log entry was created.
logDescription
{ logEntry 4 }
An implementation dependent description of the event that activated this log
entry.

14–4 Event Group

15
Token Ring Group
15.1 The Token Ring Mac-Layer Statistics Group
tokenRingMLStatsTable
{ statistics 2 }
A list of Mac-Layer Token Ring statistics entries.
tokenRingMLStatsEntry
{ tokenRingMLStatsTable 1 }
A collection of Mac-Layer statistics kept for a particular Token Ring interface.
Entry

Description

tokenRingMLStatsIndex

INTEGER

tokenRingMLStatsDataSource

OBJECT IDENTIFIER

tokenRingMLStatsDropEvents

Counter

tokenRingMLStatsMacOctets

Counter

tokenRingMLStatsMacPkts

Counter

tokenRingMLStatsRingPurgeEvents

Counter

tokenRingMLStatsRingPurgePkts

Counter

tokenRingMLStatsBeaconEvents

Counter

tokenRingMLStatsBeaconTime

TimeInterval

tokenRingMLStatsBeaconPkts

Counter

tokenRingMLStatsClaimTokenEvents

Counter

tokenRingMLStatsClaimTokenPkts

Counter

tokenRingMLStatsNAUNChanges

Counter

tokenRingMLStatsLineErrors

Counter

tokenRingMLStatsInternalErrors

Counter

Token Ring Group 15–1

Entry

Description

tokenRingMLStatsBurstErrors

Counter

tokenRingMLStatsACErrors

Counter

tokenRingMLStatsAbortErrors

Counter

tokenRingMLStatsLostFrameErrors

Counter

tokenRingMLStatsCongestionErrors

Counter

tokenRingMLStatsFrameCopiedErrors

Counter

tokenRingMLStatsFrequencyErrors

Counter

tokenRingMLStatsTokenErrors

Counter

tokenRingMLStatsSoftErrorReports

Counter

tokenRingMLStatsRingPollEvents

Counter

tokenRingMLStatsOwner

OwnerString

tokenRingMLStatsStatus

EntryStatus

tokenRingMLStatsIndex
{ tokenRingMLStatsEntry 1 }
The value of this object uniquely identifies this tokenRingMLStats entry.
tokenRingMLStatsDataSource
{ tokenRingMLStatsEntry 2 }
This object identifies the source of the data that this tokenRingMLStats entry is
configured to analyze. This source can be any tokenRing interface on this device.
In order to identify a particular interface, this object shall identify the instance of
the ifIndex object, defined in MIB-II [3], for the desired interface. For example,
if an entry were to receive data from interface #1, this object would be set to
ifIndex.1.
The statistics in this group reflect all error reports on the local network segment
attached to the identified interface.
This object may not be modified if the associated tokenRingMLStatsStatus object
is equal to valid(1).
tokenRingMLStatsDropEvents
{ tokenRingMLStatsEntry 3 }
The total number of events in which packets were dropped by the probe due to
lack of resources. Note that this number is not necessarily the number of packets
dropped; it is just the number of times this condition has been detected. This
value is the same as the corresponding tokenRingPStatsDropEvents.

15–2 Token Ring Group

tokenRingMLStatsMacOctets
{ tokenRingMLStatsEntry 4 }
The total number of octets of data in MAC packets (excluding those that were not
good frames) received on the network (excluding framing bits but including FCS
octets).
tokenRingMLStatsMacPkts
{ tokenRingMLStatsEntry 5 }
The total number of MAC packets (excluding packets that were not good frames)
received.
tokenRingMLStatsRingPurgeEvents
{ tokenRingMLStatsEntry 6 }
The total number of times that the ring enters the ring purge state from normal
ring state. The ring purge state that comes in response to the claim token or
beacon state is not counted.
tokenRingMLStatsRingPurgePkts
{ tokenRingMLStatsEntry 7 }
The total number of ring purge MAC packets detected by probe.
tokenRingMLStatsBeaconEvents
{ tokenRingMLStatsEntry 8 }
The total number of times that the ring enters a beaconing state (beaconFrameStreamingState, beaconBitStreamingState, beaconSetRecoveryModeState,
or beaconRingSignalLossState) from a non-beaconing state. Note that a change of
the source address of the beacon packet does not constitute a new beacon event.
tokenRingMLStatsBeaconTime
{ tokenRingMLStatsEntry 9 }
The total amount of time that the ring has been in the beaconing state.
tokenRingMLStatsBeaconPkts
{ tokenRingMLStatsEntry 10 }
The total number of beacon MAC packets detected by the probe.
tokenRingMLStatsClaimTokenEvents
{ tokenRingMLStatsEntry 11 }
The total number of times that the ring enters the claim token state from normal
ring state or ring purge state. The claim token state that comes in response to a
beacon state is not counted.

Token Ring Group 15–3

tokenRingMLStatsClaimTokenPkts
{ tokenRingMLStatsEntry 12 }
The total number of claim token MAC packets detected by the probe.
tokenRingMLStatsNAUNChanges
{ tokenRingMLStatsEntry 13 }
The total number of NAUN changes detected by the probe.
tokenRingMLStatsLineErrors
{ tokenRingMLStatsEntry 14 }
The total number of line errors reported in error reporting packets detected by
the probe.
tokenRingMLStatsInternalErrors
{ tokenRingMLStatsEntry 15 }
The total number of adapter internal errors reported in error reporting packets
detected by the probe.
tokenRingMLStatsBurstErrors
{ tokenRingMLStatsEntry 16 }
The total number of burst errors reported in error reporting packets detected by
the probe.
tokenRingMLStatsACErrors
{ tokenRingMLStatsEntry 17 }
The total number of AC (Address Copied) errors reported in error reporting
packets detected by the probe.
tokenRingMLStatsAbortErrors
{ tokenRingMLStatsEntry 18 }
The total number of abort delimiters reported in error reporting packets detected
by the probe.
tokenRingMLStatsLostFrameErrors
{ tokenRingMLStatsEntry 19 }
The total number of lost frame errors reported in error reporting packets detected
by the probe.

15–4 Token Ring Group

tokenRingMLStatsCongestionErrors
{ tokenRingMLStatsEntry 20 }
The total number of receive congestion errors reported in error reporting packets
detected by the probe.
tokenRingMLStatsFrameCopiedErrors
{ tokenRingMLStatsEntry 21 }
The total number of frame copied errors reported in error reporting packets
detected by the probe.
tokenRingMLStatsFrequencyErrors
{ tokenRingMLStatsEntry 22 }
The total number of frequency errors reported in error reporting packets detected
by the probe.
tokenRingMLStatsTokenErrors
{ tokenRingMLStatsEntry 23 }
The total number of token errors reported in error reporting packets detected by
the probe.
tokenRingMLStatsSoftErrorReports
{ tokenRingMLStatsEntry 24 }
The total number of soft error report frames detected by the probe.
tokenRingMLStatsRingPollEvents
{ tokenRingMLStatsEntry 25 }
The total number of ring poll events detected by the probe (that is, the number of
ring polls initiated by the active monitor that were detected).
tokenRingMLStatsOwner
{ tokenRingMLStatsEntry 26 }
The entity that configured this entry and is therefore using the resources assigned
to it.
tokenRingMLStatsStatus
{ tokenRingMLStatsEntry 27 }
The status of this tokenRingMLStats entry.

Token Ring Group 15–5

15.2 The Token Ring Promiscuous Statistics Group
tokenRingPStatsTable
{ statistics 3 }
A list of promiscuous Token Ring statistics entries.
tokenRingPStatsEntry
{ tokenRingPStatsTable 1 }
A collection of promiscuous statistics kept for non-MAC packets on a particular
Token Ring interface.
Entry

Description

tokenRingPStatsIndex

INTEGER

tokenRingPStatsDataSource

OBJECT IDENTIFIER

tokenRingPStatsDropEvents

Counter

tokenRingPStatsDataOctets

Counter

tokenRingPStatsDataPkts

Counter

tokenRingPStatsDataBroadcastPkts

Counter

tokenRingPStatsDataMulticastPkts

Counter

tokenRingPStatsDataPkts18to63Octets

Counter

tokenRingPStatsDataPkts64to127Octets

Counter

tokenRingPStatsDataPkts128to255Octets

Counter

tokenRingPStatsDataPkts256to511Octets

Counter

tokenRingPStatsDataPkts512to1023Octets

Counter

tokenRingPStatsDataPkts1024to2047Octets

Counter

tokenRingPStatsDataPkts2048to4095Octets

Counter

tokenRingPStatsDataPkts4096to8191Octets

Counter

tokenRingPStatsDataPkts8192to18000Octets

Counter

tokenRingPStatsDataPktsGreaterThan18000Octets

Counter

tokenRingPStatsOwner

OwnerString

tokenRingPStatsStatus

EntryStatus

tokenRingPStatsIndex
{ tokenRingPStatsEntry 1 }
The value of this object uniquely identifies this tokenRingPStats entry.

15–6 Token Ring Group

tokenRingPStatsDataSource
{ tokenRingPStatsEntry 2 }
This object identifies the source of the data that this tokenRingPStats entry is
configured to analyze. This source can be any tokenRing interface on this device.
In order to identify a particular interface, this object shall identify the instance of
the ifIndex object, defined in MIB-II [3], for the desired interface. For example,
if an entry were to receive data from interface #1, this object would be set to
ifIndex.1.
The statistics in this group reflect all non-MAC packets on the local network
segment attached to the identified interface.
This object may not be modified if the associated tokenRingPStatsStatus object is
equal to valid(1).
tokenRingPStatsDropEvents
{ tokenRingPStatsEntry 3 }
The total number of events in which packets were dropped by the probe due to
lack of resources. Note that this number is not necessarily the number of packets
dropped; it is just the number of times this condition has been detected. This
value is the same as the corresponding tokenRingMLStatsDropEvents
tokenRingPStatsDataOctets
{ tokenRingPStatsEntry 4 }
The total number of octets of data in good frames received on the network
(excluding framing bits but including FCS octets) in non-MAC packets.
tokenRingPStatsDataPkts
{ tokenRingPStatsEntry 5 }
The total number of non-MAC packets in good frames. received.
tokenRingPStatsDataBroadcastPkts
{ tokenRingPStatsEntry 6 }
The total number of good non-MAC frames received that were directed to an LLC
broadcast address (0xFFFFFFFFFFFF or 0xC000FFFFFFFF).
tokenRingPStatsDataMulticastPkts
{ tokenRingPStatsEntry 7 }
The total number of good non-MAC frames received that were directed to a local
or global multicast or functional address. Note that this number does not include
packets directed to the broadcast address.

Token Ring Group 15–7

tokenRingPStatsDataPkts18to63Octets
{ tokenRingPStatsEntry 8 }
The total number of good non-MAC frames received that were between 18 and 63
octets in length inclusive, excluding framing bits but including FCS octets.
tokenRingPStatsDataPkts64to127Octets
{ tokenRingPStatsEntry 9 }
The total number of good non-MAC frames received that were between 64 and
127 octets in length inclusive, excluding framing bits but including FCS octets.
tokenRingPStatsDataPkts128to255Octets
{ tokenRingPStatsEntry 10 }
The total number of good non-MAC frames received that were between 128 and
255 octets in length inclusive, excluding framing bits but including FCS octets.
tokenRingPStatsDataPkts256to511Octets
{ tokenRingPStatsEntry 11 }
The total number of good non-MAC frames received that were between 256 and
511 octets in length inclusive, excluding framing bits but including FCS octets.
tokenRingPStatsDataPkts512to1023Octets
{ tokenRingPStatsEntry 12 }
The total number of good non-MAC frames received that were between 512 and
1023 octets in length inclusive, excluding framing bits but including FCS octets.
tokenRingPStatsDataPkts1024to2047Octets
{ tokenRingPStatsEntry 13 }
The total number of good non-MAC frames received that were between 1024 and
2047 octets in length inclusive, excluding framing bits but including FCS octets.
tokenRingPStatsDataPkts2048to4095Octets
{ tokenRingPStatsEntry 14 }
The total number of good non-MAC frames received that were between 2048 and
4095 octets in length inclusive, excluding framing bits but including FCS octets.
tokenRingPStatsDataPkts4096to8191Octets
{ tokenRingPStatsEntry 15 }
The total number of good non-MAC frames received that were between 4096 and
8191 octets in length inclusive, excluding framing bits but including FCS octets.

15–8 Token Ring Group

tokenRingPStatsDataPkts8192to18000Octets
{ tokenRingPStatsEntry 16 }
The total number of good non-MAC frames received that were between 8192 and
18000 octets in length inclusive, excluding framing bits but including FCS octets.
tokenRingPStatsDataPktsGreaterThan18000Octets
{ tokenRingPStatsEntry 17 }
The total number of good non-MAC frames received that were greater than 18000
octets in length, excluding framing bits but including FCS octets.
tokenRingPStatsOwner
{ tokenRingPStatsEntry 18 }
The entity that configured this entry and is therefore using the resources assigned
to it.
tokenRingPStatsStatus
{ tokenRingPStatsEntry 19 }
The status of this tokenRingPStats entry.

15.3 The Token Ring Mac-Layer History Group
Implementation of this group requires implementation of the historyControl
group from RFC1271.
tokenRingMLHistoryTable
{ history 3 }
A list of Mac-Layer Token Ring statistics entries.
tokenRingMLHistoryEntry
{ tokenRingMLHistoryTable 1 }
A collection of Mac-Layer statistics kept for a particular Token Ring interface.
Entry

Description

tokenRingMLHistoryIndex

INTEGER

tokenRingMLHistorySampleIndex

INTEGER

tokenRingMLHistoryIntervalStart

TimeTicks

tokenRingMLHistoryDropEvents

Counter

tokenRingMLHistoryMacOctets

Counter

Token Ring Group 15–9

Entry

Description

tokenRingMLHistoryMacPkts

Counter

tokenRingMLHistoryRingPurgeEvents

Counter

tokenRingMLHistoryRingPurgePkts

Counter

tokenRingMLHistoryBeaconEvents

Counter

tokenRingMLHistoryBeaconTime

TimeInterval

tokenRingMLHistoryBeaconPkts

Counter

tokenRingMLHistoryClaimTokenEvents

Counter

tokenRingMLHistoryClaimTokenPkts

Counter

tokenRingMLHistoryNAUNChanges

Counter

tokenRingMLHistoryLineErrors

Counter

tokenRingMLHistoryInternalErrors

Counter

tokenRingMLHistoryBurstErrors

Counter

tokenRingMLHistoryACErrors

Counter

tokenRingMLHistoryAbortErrors

Counter

tokenRingMLHistoryLostFrameErrors

Counter

tokenRingMLHistoryCongestionErrors

Counter

tokenRingMLHistoryFrameCopiedErrors

Counter

tokenRingMLHistoryFrequencyErrors

Counter

tokenRingMLHistoryTokenErrors

Counter

tokenRingMLHistorySoftErrorReports

Counter

tokenRingMLHistoryRingPollEvents

Counter

tokenRingMLHistoryActiveStations

INTEGER

tokenRingMLHistoryIndex
{ tokenRingMLHistoryEntry 1 }
The history of which this entry is a part. The history identified by a particular
value of this index is the same history as identified by the same value of
historyControlIndex.
tokenRingMLHistorySampleIndex
{ tokenRingMLHistoryEntry 2 }
An index that uniquely identifies the particular Mac-Layer sample this
entry represents among all Mac-Layer samples associated with the same
historyControlEntry. This index starts at 1 and increases by one as each new
sample is taken.
15–10 Token Ring Group

tokenRingMLHistoryIntervalStart
{ tokenRingMLHistoryEntry 3 }
The value of sysUpTime at the start of the interval over which this sample was
measured. If the probe keeps track of the time of day, it should start the first
sample of the history at a time such that when the next hour of the day begins,
a sample is started at that instant. Note that following this rule may require the
probe to delay collecting the first sample of the history, as each sample must be of
the same interval. Also note that the sample which is currently being collected is
not accessible in this table until the end of its interval.
tokenRingMLHistoryDropEvents
{ tokenRingMLHistoryEntry 4 }
The total number of events in which packets were dropped by the probe due to
lack of resources during this sampling interval. Note that this number is not
necessarily the number of packets dropped, it is just the number of times this
condition has been detected.
tokenRingMLHistoryMacOctets
{ tokenRingMLHistoryEntry 5 }
The total number of octets of data in MAC packets (excluding those that were not
good frames) received on the network during this sampling interval (excluding
framing bits but including FCS octets).
tokenRingMLHistoryMacPkts
{ tokenRingMLHistoryEntry 6 }
The total number of MAC packets (excluding those that were not good frames)
received during this sampling interval.
tokenRingMLHistoryRingPurgeEvents
{ tokenRingMLHistoryEntry 7 }
The total number of times that the ring entered the ring purge state from normal
ring state during this sampling interval. The ring purge state that comes from
the claim token or beacon state is not counted.
tokenRingMLHistoryRingPurgePkts
{ tokenRingMLHistoryEntry 8 }
The total number of Ring Purge MAC packets detected by the probe during this
sampling interval.

Token Ring Group 15–11

tokenRingMLHistoryBeaconEvents
{ tokenRingMLHistoryEntry 9 }
The total number of times that the ring enters a beaconing state (beaconFrameStreamingState, beaconBitStreamingState, beaconSetRecoveryModeState,
or beaconRingSignalLossState) during this sampling interval. Note that a change
of the source address of the beacon packet does not constitute a new beacon event.
tokenRingMLHistoryBeaconTime
{ tokenRingMLHistoryEntry 10 }
The amount of time that the ring has been in the beaconing state during this
sampling interval.
tokenRingMLHistoryBeaconPkts
{ tokenRingMLHistoryEntry 11 }
The total number of beacon MAC packets detected by the probe during this
sampling interval.
tokenRingMLHistoryClaimTokenEvents
{ tokenRingMLHistoryEntry 12 }
The total number of times that the ring enters the claim token state from normal
ring state or ring purge state during this sampling interval. The claim token
state that comes from the beacon state is not counted.
tokenRingMLHistoryClaimTokenPkts
{ tokenRingMLHistoryEntry 13 }
The total number of claim token MAC packets detected by the probe during this
sampling interval.
tokenRingMLHistoryNAUNChanges
{ tokenRingMLHistoryEntry 14 }
The total number of NAUN changes detected by the probe during this sampling
interval.
tokenRingMLHistoryLineErrors
{ tokenRingMLHistoryEntry 15 }
The total number of line errors reported in error reporting packets detected by
the probe during this sampling interval.

15–12 Token Ring Group

tokenRingMLHistoryInternalErrors
{ tokenRingMLHistoryEntry 16 }
The total number of adapter internal errors reported in error reporting packets
detected by the probe during this sampling interval.
tokenRingMLHistoryBurstErrors
{ tokenRingMLHistoryEntry 17 }
The total number of burst errors reported in error reporting packets detected by
the probe during this sampling interval.
tokenRingMLHistoryACErrors
{ tokenRingMLHistoryEntry 18 }
The total number of AC (Address Copied) errors reported in error reporting
packets detected by the probe during this sampling interval.
tokenRingMLHistoryAbortErrors
{ tokenRingMLHistoryEntry 19 }
The total number of abort delimiters reported in error reporting packets detected
by the probe during this sampling interval.
tokenRingMLHistoryLostFrameErrors
{ tokenRingMLHistoryEntry 20 }
The total number of lost frame errors reported in error reporting packets detected
by the probe during this sampling interval.
tokenRingMLHistoryCongestionErrors
{ tokenRingMLHistoryEntry 21 }
The total number of receive congestion errors reported in error reporting packets
detected by the probe during this sampling interval.
tokenRingMLHistoryFrameCopiedErrors
{ tokenRingMLHistoryEntry 22 }
The total number of frame copied errors reported in error reporting packets
detected by the probe during this sampling interval.
tokenRingMLHistoryFrequencyErrors
{ tokenRingMLHistoryEntry 23 }
The total number of frequency errors reported in error reporting packets detected
by the probe during this sampling interval.

Token Ring Group 15–13

tokenRingMLHistoryTokenErrors
{ tokenRingMLHistoryEntry 24 }
The total number of token errors reported in error reporting packets detected by
the probe during this sampling interval.
tokenRingMLHistorySoftErrorReports
{ tokenRingMLHistoryEntry 25 }
The total number of soft error report frames detected by the probe during this
sampling interval.
tokenRingMLHistoryRingPollEvents
{ tokenRingMLHistoryEntry 26 }
The total number of ring poll events detected by the probe during this sampling
interval.
tokenRingMLHistoryActiveStations
{ tokenRingMLHistoryEntry 27}
The maximum number of active stations on the ring detected by the probe during
this sampling interval.

15.4 The Token Ring Promiscuous History Group
Implementation of this group requires the implementation of the historyControl
group from RFC1271.
tokenRingPHistoryTable
{ history 4 }
A list of promiscuous Token Ring statistics entries.
tokenRingPHistoryEntry
A collection of promiscuous statistics kept for a particular Token Ring interface.
Entry

Description

tokenRingPHistoryIndex

INTEGER

tokenRingPHistorySampleIndex

INTEGER

tokenRingPHistoryIntervalStart

TimeTicks

tokenRingPHistoryDropEvents

Counter

tokenRingPHistoryDataOctets

Counter

15–14 Token Ring Group

Entry

Description

tokenRingPHistoryDataPkts

Counter

tokenRingPHistoryDataBroadcastPkts

Counter

tokenRingPHistoryDataMulticastPkts

Counter

tokenRingPHistoryDataPkts18to63Octets

Counter

tokenRingPHistoryDataPkts64to127Octets

Counter

tokenRingPHistoryDataPkts128to255Octets

Counter

tokenRingPHistoryDataPkts256to511Octets

Counter

tokenRingPHistoryDataPkts512to1023Octets

Counter

tokenRingPHistoryDataPkts1024to2047Octets

Counter

tokenRingPHistoryDataPkts2048to4095Octets

Counter

tokenRingPHistoryDataPkts4096to8191Octets

Counter

tokenRingPHistoryDataPkts8192to18000Octets

Counter

tokenRingPHistoryDataPktsGreaterThan18000Octets

Counter

tokenRingPHistoryIndex
{ tokenRingPHistoryEntry 1 }
The history of which this entry is a part. The history identified by a particular
value of this index is the same history as identified by the same value of
historyControlIndex.
tokenRingPHistorySampleIndex
{ tokenRingPHistoryEntry 2 }
An index that uniquely identifies the particular sample this entry represents
among all samples associated with the same historyControlEntry. This index
starts at 1 and increases by one as each new sample is taken.
tokenRingPHistoryIntervalStart
{ tokenRingPHistoryEntry 3 }
The value of sysUpTime at the start of the interval over which this sample was
measured. If the probe keeps track of the time of day, it should start the first
sample of the history at a time such that when the next hour of the day begins,
a sample is started at that instant. Note that following this rule may require the
probe to delay collecting the first sample of the history, as each sample must be of
the same interval. Also note that the sample which is currently being collected is
not accessible in this table until the end of its interval.

Token Ring Group 15–15

tokenRingPHistoryDropEvents
{ tokenRingPHistoryEntry 4 }
The total number of events in which packets were dropped by the probe due to
lack of resources during this sampling interval. Note that this number is not
necessarily the number of packets dropped, it is just the number of times this
condition has been detected.
tokenRingPHistoryDataOctets
{ tokenRingPHistoryEntry 5 }
The total number of octets of data in good frames received on the network
(excluding framing bits but including FCS octets) in non-MAC packets during this
sampling interval.
tokenRingPHistoryDataPkts
{ tokenRingPHistoryEntry 6 }
The total number of good non-MAC frames received during this sampling interval.
tokenRingPHistoryDataBroadcastPkts
{ tokenRingPHistoryEntry 7 }
The total number of good non-MAC frames received during this sampling
interval that were directed to an LLC broadcast address (0xFFFFFFFFFFFF
or 0xC000FFFFFFFF).
tokenRingPHistoryDataMulticastPkts
{ tokenRingPHistoryEntry 8 }
The total number of good non-MAC frames received during this sampling interval
that were directed to a local or global multicast or functional address. Note that
this number does not include packets directed to the broadcast address.
tokenRingPHistoryDataPkts18to63Octets
{ tokenRingPHistoryEntry 9 }
The total number of good non-MAC frames received during this sampling interval
that were between 18 and 63 octets in length inclusive, excluding framing bits
but including FCS octets.
tokenRingPHistoryDataPkts64to127Octets
{ tokenRingPHistoryEntry 10 }
The total number of good non-MAC frames received during this sampling interval
that were between 64 and 127 octets in length inclusive, excluding framing bits
but including FCS octets.

15–16 Token Ring Group

tokenRingPHistoryDataPkts128to255Octets
{ tokenRingPHistoryEntry 11 }
The total number of good non-MAC frames received during this sampling interval
that were between 128 and 255 octets in length inclusive, excluding framing bits
but including FCS octets.
tokenRingPHistoryDataPkts256to511Octets
{ tokenRingPHistoryEntry 12 }
The total number of good non-MAC frames received during this sampling interval
that were between 256 and 511 octets in length inclusive, excluding framing bits
but including FCS octets.
tokenRingPHistoryDataPkts512to1023Octets
{ tokenRingPHistoryEntry 13 }
The total number of good non-MAC frames received during this sampling interval
that were between 512 and 1023 octets in length inclusive, excluding framing bits
but including FCS octets.
tokenRingPHistoryDataPkts1024to2047Octets
{ tokenRingPHistoryEntry 14 }
The total number of good non-MAC frames received during this sampling interval
that were between 1024 and 2047 octets in length inclusive, excluding framing
bits but including FCS octets.
tokenRingPHistoryDataPkts2048to4095Octets
{ tokenRingPHistoryEntry 15 }
The total number of good non-MAC frames received during this sampling interval
that were between 2048 and 4095 octets in length inclusive, excluding framing
bits but including FCS octets.
tokenRingPHistoryDataPkts4096to8191Octets
{ tokenRingPHistoryEntry 16 }
The total number of good non-MAC frames received during this sampling interval
that were between 4096 and 8191 octets in length inclusive, excluding framing
bits but including FCS octets.
tokenRingPHistoryDataPkts8192to18000Octets
{ tokenRingPHistoryEntry 17 }
The total number of good non-MAC frames received during this sampling interval
that were between 8192 and 18000 octets in length inclusive, excluding framing
bits but including FCS octets.

Token Ring Group 15–17

tokenRingPHistoryDataPktsGreaterThan18000Octets
{ tokenRingPHistoryEntry 18 }
The total number of good non-MAC frames received during this sampling
interval that were greater than 18000 octets in length, excluding framing bits
but including FCS octets.

15.5 The Token Ring Ring Station Group
Although the ringStationTable stores entries only for those stations physically
attached to the local ring and the number of stations attached to a ring is limited,
a probe may still need to free resources when resources grow tight. In such a
situation, it is suggested that the probe free only inactive stations, and to first
free the stations that have been inactive for the longest time.
ringStationControlTable
{ tokenRing 1 }
A list of ringStation table control entries.
ringStationControlEntry
A list of parameters that set up the discovery of stations on a particular interface
and the collection of statistics about these stations.
Entry

Description

ringStationControlIfIndex

INTEGER

ringStationControlTableSize

INTEGER

ringStationControlActiveStations

INTEGER

ringStationControlRingState

INTEGER

ringStationControlBeaconSender

MacAddress

ringStationControlBeaconNAUN

MacAddress

ringStationControlActiveMonitor

MacAddress

ringStationControlOrderChanges

Counter

ringStationControlOwner

OwnerString

ringStationControlStatus

EntryStatus

15–18 Token Ring Group

ringStationControlIfIndex
{ ringStationControlEntry 1 }
The value of this object uniquely identifies the interface on this remote network
monitoring device from which ringStation data is collected. The interface
identified by a particular value of this object is the same interface as identified by
the same value of the ifIndex object, defined in MIB- II [3].
ringStationControlTableSize
{ ringStationControlEntry 2 }
The number of ringStationEntries in the ringStationTable associated with this
ringStationControlEntry.
ringStationControlActiveStations
{ ringStationControlEntry 3 }
The number of active ringStationEntries in the ringStationTable associated with
this ringStationControlEntry.
ringStationControlRingState
{ ringStationControlEntry 4 }
•

normalOperation(1),

•

ringPurgeState(2),

•

claimTokenState(3),

•

beaconFrameStreamingState(4),

•

beaconBitStreamingState(5),

•

beaconRingSignalLossState(6),

•

beaconSetRecoveryModeState(7)

The current status of this ring.
ringStationControlBeaconSender
{ ringStationControlEntry 5 }
The address of the sender of the last beacon frame received by the probe on this
ring. If no beacon frames have been received, this object shall be equal to six
octets of zero.

Token Ring Group 15–19

ringStationControlBeaconNAUN
{ ringStationControlEntry 6 }
The address of the NAUN in the last beacon frame received by the probe on this
ring. If no beacon frames have been received, this object shall be equal to six
octets of zero.
ringStationControlActiveMonitor
{ ringStationControlEntry 7 }
The address of the Active Monitor on this segment. If this address is unknown,
this object shall be equal to six octets of zero.
ringStationControlOrderChanges
{ ringStationControlEntry 8 }
The number of add and delete events in the ringStationOrderTable optionally
associated with this ringStationControlEntry.
ringStationControlOwner
{ ringStationControlEntry 9 }
The entity that configured this entry and is therefore using the resources assigned
to it.
ringStationControlStatus
{ ringStationControlEntry 10 }
The status of this ringStationControl entry.
If this object is not equal to valid(1), all associated entries in the ringStationTable
shall be deleted by the agent.
ringStationTable
{ tokenRing 2 }
A list of ring station entries. An entry will exist for each station that is now or
has previously been detected as physically present on this ring.
ringStationEntry
A collection of statistics for a particular station that has been discovered on a ring
monitored by this device.
Entry

Description

ringStationIfIndex

INTEGER

15–20 Token Ring Group

Entry

Description

ringStationMacAddress

MacAddress

ringStationLastNAUN

MacAddress

ringStationStationStatus

INTEGER

ringStationLastEnterTime

TimeTicks

ringStationLastExitTime

TimeTicks

ringStationDuplicateAddresses

Counter

ringStationInLineErrors

Counter

ringStationOutLineErrors

Counter

ringStationInternalErrors

Counter

ringStationInBurstErrors

Counter

ringStationOutBurstErrors

Counter

ringStationACErrors

Counter

ringStationAbortErrors

Counter

ringStationLostFrameErrors

Counter

ringStationCongestionErrors

Counter

ringStationFrameCopiedErrors

Counter

ringStationFrequencyErrors

Counter

ringStationTokenErrors

Counter

ringStationInBeaconErrors

Counter

ringStationOutBeaconErrors

Counter

ringStationInsertions

Counter

ringStationIfIndex
{ ringStationEntry 1 }
The value of this object uniquely identifies the interface on this remote network
monitoring device on which this station was detected. The interface identified by
a particular value of this object is the same interface as identified by the same
value of the ifIndex object, defined in MIB-II [3].
ringStationMacAddress
{ ringStationEntry 2 }
The physical address of this station.

Token Ring Group 15–21

ringStationLastNAUN
{ ringStationEntry 3 }
The physical address of last known NAUN of this station.
ringStationStationStatus
{ ringStationEntry 4 }
•

active(1)

•

inactive(2)

•

forcedRemoval(3)

The status of this station on the ring.
ringStationLastEnterTime
{ ringStationEntry 5 }
The value of sysUpTime at the time this station last entered the ring. If the time
is unknown, this value shall be zero.
ringStationLastExitTime
{ ringStationEntry 6 }
The value of sysUpTime at the time the probe detected that this station last
exited the ring. If the time is unknown, this value shall be zero.
ringStationDuplicateAddresses
{ ringStationEntry 7 }
The number of times this station experienced a duplicate address error.
ringStationInLineErrors
{ ringStationEntry 8 }
The total number of line errors reported by this station in error reporting packets
detected by the probe.
ringStationOutLineErrors
{ ringStationEntry 9 }
The total number of line errors reported in error reporting packets sent by the
nearest active downstream neighbor of this station and detected by the probe.
ringStationInternalErrors
{ ringStationEntry 10 }
The total number of adapter internal errors reported by this station in error
reporting packets detected by the probe.

15–22 Token Ring Group

ringStationInBurstErrors
{ ringStationEntry 11 }
The total number of burst errors reported by this station in error reporting
packets detected by the probe.
ringStationOutBurstErrors
{ ringStationEntry 12 }
The total number of burst errors reported in error reporting packets sent by the
nearest active downstream neighbor of this station and detected by the probe.
ringStationACErrors
{ ringStationEntry 13 }
The total number of AC (Address Copied) errors reported in error reporting
packets sent by the nearest active downstream neighbor of this station and
detected by the probe.
ringStationAbortErrors
{ ringStationEntry 14 }
The total number of abort delimiters reported by this station in error reporting
packets detected by the probe.
ringStationLostFrameErrors
{ ringStationEntry 15 }
The total number of lost frame errors reported by this station in error reporting
packets detected by the probe.
ringStationCongestionErrors
{ ringStationEntry 16 }
The total number of receive congestion errors reported by this station in error
reporting packets detected by the probe.
ringStationFrameCopiedErrors
{ ringStationEntry 17 }
The total number of frame copied errors reported by this station in error reporting
packets detected by the probe.
ringStationFrequencyErrors
{ ringStationEntry 18 }
The total number of frequency errors reported by this station in error reporting
packets detected by the probe.

Token Ring Group 15–23

ringStationTokenErrors
{ ringStationEntry 19 }
The total number of token errors reported by this station in error reporting
frames detected by the probe.
ringStationInBeaconErrors
{ ringStationEntry 20 }
The total number of beacon frames sent by this station and detected by the probe.
ringStationOutBeaconErrors
{ ringStationEntry 21 }
The total number of beacon frames detected by the probe that name this station
as the NAUN.
ringStationInsertions
{ ringStationEntry 22 }
The number of times the probe detected this station inserting onto the ring.

15.6 The Token Ring Ring Station Order Group
ringStationOrderTable
{ tokenRing 3 }
A list of ring station entries for stations in the ring poll, ordered by their ringorder.
ringStationOrderEntry
{ ringStationOrderTable 1 }
A collection of statistics for a particular station that is active on a ring monitored
by this device. This table will contain information for every interface that has a
ringStationControlStatus equal to valid.
Entry

Descriptiom

ringStationOrderIfIndex

INTEGER

ringStationOrderOrderIndex

INTEGER

ringStationOrderMacAddress

MacAddress

ringStationOrderIfIndex
{ ringStationOrderEntry 1 }

15–24 Token Ring Group

The value of this object uniquely identifies the interface on this remote network
monitoring device on which this station was detected. The interface identified by
a particular value of this object is the same interface as identified by the same
value of the ifIndex object, defined in MIB-II [3].
ringStationOrderOrderIndex
{ ringStationOrderEntry 2 }
This index denotes the location of this station with respect to other stations on
the ring. This index is one more than the number of hops downstream that this
station is from the rmon probe. The rmon probe itself gets the value one.
ringStationOrderMacAddress
{ ringStationOrderEntry 3 }
The physical address of this station.

15.7 The Token Ring Ring Station Config Group
ringStationConfigControlTable
{ tokenRing 4 }
A list of ring station configuration control entries.
ringStationConfigControlEntry
{ ringStationConfigControlTable 1 }
This entry controls active management of stations by the probe. One entry exists
in this table for each active station in the ringStationTable.
Entry

Descriptiom

ringStationConfigControlIfIndex

INTEGER

ringStationConfigControlMacAddress

MacAddress

ringStationConfigControlRemove

INTEGER

ringStationConfigControlUpdateStats

INTEGER

ringStationConfigControlIfIndex
{ ringStationConfigControlEntry 1 }
The value of this object uniquely identifies the interface on this remote network
monitoring device on which this station was detected. The interface identified by
a particular value of this object is the same interface as identified by the same
value of the ifIndex object, defined in MIB-II [3].

Token Ring Group 15–25

ringStationConfigControlMacAddress
{ ringStationConfigControlEntry 2 }
The physical address of this station.
ringStationConfigControlRemove
{ ringStationConfigControlEntry 3 }
•

stable(1)

•

removing(2)

Setting this object to ‘removing(2)’ causes a Remove Station MAC frame to be
sent. The agent will set this object to ‘stable(1)’ after processing the request.
ringStationConfigControlUpdateStats
{ ringStationConfigControlEntry 4 }
•

stable(1)

•

updating(2)

Setting this object to ‘updating(2)’ causes the configuration information associate
with this entry to be updated. The agent will set this object to ‘stable(1)’ after
processing the request.

15.8 The ringStationConfig Table
ringStationConfigTable
{ tokenRing 5 }
A list of configuration entries for stations on a ring monitored by this probe.
ringStationConfigEntry
A collection of statistics for a particular station that has been discovered on a ring
monitored by this probe.
Entry

Descriptiom

ringStationConfigIfIndex

INTEGER

ringStationConfigMacAddress

MacAddress

ringStationConfigUpdateTime

TimeTicks

ringStationConfigLocation

OCTET STRING

ringStationConfigMicrocode

OCTET STRING

ringStationConfigGroupAddress

OCTET STRING

15–26 Token Ring Group

Entry

Descriptiom

ringStationConfigFunctionalAddress

OCTET STRING

ringStationConfigIfIndex
{ ringStationConfigEntry 1 }
The value of this object uniquely identifies the interface on this remote network
monitoring device on which this station was detected. The interface identified by
a particular value of this object is the same interface as identified by the same
value of the ifIndex object, defined in MIB-II [3].
ringStationConfigMacAddress
{ ringStationConfigEntry 2 }
The physical address of this station.
ringStationConfigUpdateTime
{ ringStationConfigEntry 3 }
The value of sysUpTime at the time this configuration information was last
updated (completely).
ringStationConfigLocation
{ ringStationConfigEntry 4 }
The assigned physical location of this station.
ringStationConfigMicrocode
{ ringStationConfigEntry 5 }
The microcode EC level of this station.
ringStationConfigGroupAddress
{ ringStationConfigEntry 6 }
The low-order 4 octets of the group address recognized by this station.
ringStationConfigFunctionalAddress
{ ringStationConfigEntry 7 }
the functional addresses recognized by this station.

15.9 The Token Ring Source Routing group
sourceRoutingStatsTable
{ tokenRing 6 }
A list of source routing statistics entries.

Token Ring Group 15–27

sourceRoutingStatsEntry
{ sourceRoutingStatsTable 1 }
A collection of source routing statistics kept for a particular Token Ring interface.
Entry

Descriptiom

sourceRoutingStatsIfIndex

INTEGER

sourceRoutingStatsRingNumber

INTEGER

sourceRoutingStatsInFrames

Counter

sourceRoutingStatsOutFrames

Counter

sourceRoutingStatsThroughFrames

Counter

sourceRoutingStatsAllRoutesBroadcastFrames

Counter

sourceRoutingStatsSingleRouteBroadcastFrames

Counter

sourceRoutingStatsInOctets

Counter

sourceRoutingStatsOutOctets

Counter

sourceRoutingStatsThroughOctets

Counter

sourceRoutingStatsAllRoutesBroadcastOctets

Counter

sourceRoutingStatsSingleRoutesBroadcastOctets

Counter

sourceRoutingStatsLocalLLCFrames

Counter

sourceRoutingStats1HopFrames

Counter

sourceRoutingStats2HopsFrames

Counter

sourceRoutingStats3HopsFrames

Counter

sourceRoutingStats4HopsFrames

Counter

sourceRoutingStats5HopsFrames

Counter

sourceRoutingStats6HopsFrames

Counter

sourceRoutingStats7HopsFrames

Counter

sourceRoutingStats8HopsFrames

Counter

sourceRoutingStatsMoreThan8HopsFrames

Counter

sourceRoutingStatsOwner

OwnerString

sourceRoutingStatsStatus

EntryStatus

sourceRoutingStatsIfIndex
{ sourceRoutingStatsEntry 1 }

15–28 Token Ring Group

The value of this object uniquely identifies the interface on this remote network
monitoring device on which source routing statistics will be detected. The
interface identified by a particular value of this object is the same interface
as identified by the same value of the ifIndex object, defined in MIB-II [3].
sourceRoutingStatsRingNumber
{ sourceRoutingStatsEntry 2 }
The ring number of the ring monitored by this entry. When any object in this
entry is created, the probe will attempt to discover the ring number. Only after
the ring number is discovered will this object be created. After creating an object
in this entry, the management station should poll this object to detect when it
is created. Only after this object is created can the management station set the
sourceRoutingStatsStatus entry to valid(1).
sourceRoutingStatsInFrames
{ sourceRoutingStatsEntry 3 }
The count of frames sent into this ring from another ring.
sourceRoutingStatsOutFrames
{ sourceRoutingStatsEntry 4 }
The count of frames sent from this ring to another ring.
sourceRoutingStatsThroughFrames
{ sourceRoutingStatsEntry 5 }
The count of frames sent from another ring, through this ring, to another ring.
sourceRoutingStatsAllRoutesBroadcastFrames
{ sourceRoutingStatsEntry 6 }
The total number of good frames received that were All Routes Broadcast.
sourceRoutingStatsSingleRouteBroadcastFrames
{ sourceRoutingStatsEntry 7 }
The total number of good frames received that were Single Route Broadcast.
sourceRoutingStatsInOctets
{ sourceRoutingStatsEntry 8 }
The count of octets in good frames sent into this ring from another ring.
sourceRoutingStatsOutOctets
{ sourceRoutingStatsEntry 9 }
The count of octets in good frames sent from this ring to another ring.

Token Ring Group 15–29

sourceRoutingStatsThroughOctets
{ sourceRoutingStatsEntry 10 }
The count of octets in good frames sent another ring, through this ring, to another
ring.
sourceRoutingStatsAllRoutesBroadcastOctets
{ sourceRoutingStatsEntry 11 }
The total number of octets in good frames received that were All Routes
Broadcast.
sourceRoutingStatsSingleRoutesBroadcastOctets
{ sourceRoutingStatsEntry 12 }
The total number of octets in good frames received that were Single Route
Broadcast.
sourceRoutingStatsLocalLLCFrames
{ sourceRoutingStatsEntry 13 }
The total number of frames received who had no RIF field (or had a RIF field that
only included the local ring’s number) and were not All Route Broadcast Frames.
sourceRoutingStats1HopFrames
{ sourceRoutingStatsEntry 14 }
The total number of frames received whose route had 1 hop, were not All Route
Broadcast Frames, and whose source or destination were on this ring (that is
frames that had a RIF field and had this ring number in the first or last entry of
the RIF field).
sourceRoutingStats2HopsFrames
{ sourceRoutingStatsEntry 15 }
The total number of frames received whose route had 2 hops, were not All Route
Broadcast Frames, and whose source or destination were on this ring (that is
frames that had a RIF field and had this ring number in the first or last entry of
the RIF field).
sourceRoutingStats3HopsFrames
{ sourceRoutingStatsEntry 16 }
The total number of frames received whose route had 3 hops, were not All Route
Broadcast Frames, and whose source or destination were on this ring (that is
frames that had a RIF field and had this ring number in the first or last entry of
the RIF field).

15–30 Token Ring Group

sourceRoutingStats4HopsFrames
{ sourceRoutingStatsEntry 17 }
The total number of frames received whose route had 4 hops, were not All Route
Broadcast Frames, and whose source or destination were on this ring (that is
frames that had a RIF field and had this ring number in the first or last entry of
the RIF field).
sourceRoutingStats5HopsFrames
{ sourceRoutingStatsEntry 18 }
The total number of frames received whose route had 5 hops, were not All Route
Broadcast Frames, and whose source or destination were on this ring (that is
frames that had a RIF field and had this ring number in the first or last entry of
the RIF field).
sourceRoutingStats6HopsFrames
{ sourceRoutingStatsEntry 19 }
The total number of frames received whose route had 6 hops, were not All Route
Broadcast Frames, and whose source or destination were on this ring (that is
frames that had a RIF field and had this ring number in the first or last entry of
the RIF field).
sourceRoutingStats7HopsFrames
{ sourceRoutingStatsEntry 20 }
The total number of frames received whose route had 7 hops, were not All Route
Broadcast Frames, and whose source or destination were on this ring (that is
frames that had a RIF field and had this ring number in the first or last entry of
the RIF field).
sourceRoutingStats8HopsFrames
{ sourceRoutingStatsEntry 21 }
The total number of frames received whose route had 8 hops, were not All Route
Broadcast Frames, and whose source or destination were on this ring (that is
frames that had a RIF field and had this ring number in the first or last entry of
the RIF field).
sourceRoutingStatsMoreThan8HopsFrames
{ sourceRoutingStatsEntry 22 }
The total number of frames received whose route had more than 8 hops, were not
All Route Broadcast Frames, and whose source or destination were on this ring
(that is frames that had a RIF field and had this ring number in the first or last
entry of the RIF field).

Token Ring Group 15–31

sourceRoutingStatsOwner
{ sourceRoutingStatsEntry 23 }
The entity that configured this entry and is therefore using the resources assigned
to it.
sourceRoutingStatsStatus
{ sourceRoutingStatsEntry 24 }
The status of this sourceRoutingStats entry.

15–32 Token Ring Group

A
Specifications and Parts
This appendix provides the following specifications for DECpacketprobe 900RR:
•

Physical dimensions

•

Environmental specifications

•

Electrical specifications

•

Console connector pin-out

The appendix also lists the replacement parts for DECpacketprobe 900RR.

A.1 Dimensions
The following table lists the physical dimensions of DECpacketprobe 900RR:
Dimension

Measurement

Height

29.2 cm (1.4 in)

Width

3.2 cm (11.0 in)

Depth

11.2 cm (4.4 in) (13.5 cm (5.3 in) in standalone)

Weight

0.77 kg (1.7 lb)

Specifications and Parts A–1

A.2 Environmental Specifications
The DECpacketprobe 900RR is designed to operate in an office environment or
equipment room environment, such as telephone closets or satellite equipment
rooms. It is not intended to operate in a sealed environment.

A.2.1 Operating Environment
The following table provides the operating environment specifications:
Condition

Value

Temperature

5°C to 50°C (41°F to 122°F)

Maximum rate of change

20°C/hr (36°F/hr)

Relative humidity

10% to 95% (noncondensing)

Wet-bulb temperature

32°C (90°F) maximum

Dew point

2°C (36°F) minimum

Altitude

Sea level to 4900 m (16000 ft)

Forced Convection
Cooled

A minimum of 10 cm (4 inches) of space must be provided on
both ends of the unit for adequate air flow.

A.2.2 Shipping Environment
The following table provides the shipping environment specifications:
Condition

Value

Temperature

–40°C to 66°C (–40°F to 151°F)

Relative humidity

10% to 95% (noncondensing)

Altitude

Sea level to 4.9 km (16,000 ft)

A.3 Acoustical Specifications
The following tables provide acoustical specifications for the DECpacketprobe
900RR in English and German.

A–2 Specifications and Parts

Table A–1 Acoustics
Acoustics - Preliminary declared values per ISO 9296 and ISO 7779:
Sound Power Level
LwAd, B

Sound Pressure Level
LpAm, dBA
(bystander positions)

Product

Idle/Opreate

DTRMN

4.5

DTRMN +
H7827

4.5

Current values for specific configurations are available from Digital
representatives. 1 B = 10 dBA.)
Table A–2 Schallemissionswerte
Schallemissionswerte - Werteangaben nach ISO 9296 und ISO 7779/DIN EN27779:
Schalleistungspegel
LwAd, B

Schalldruckpegel
LpAm, dBA
(Zuschauerpositionen)

Produkt

Leerlauf/Betrieb

DTRMN

4,5

DTRMN +
H7827

4,5

Aktuelle Werte für spezielle Ausrüstungsstufen sind über die Digital Equipment
Vertretungen erhältlich. 1 B = 10 dBA.

A.4 Electrical Specifications
The standalone DECpacketprobe 900RR has a separate self-contained power
supply and a power cord.

Specifications and Parts A–3

A.4.1 Power Supply (H7827–BA)
The following table provides the power supply specifications:
Specification

Value

Voltage

88 Vac to 264 Vac (nominal 240 Vac)

AC cord length

6 ft

Current at 88 volts

0.70 A

Current at 176 volts

0.42 A

Frequency

50 Hz to 60 Hz

Power

23 W

Output voltage 1

5.1 Vdc

Output voltage 2

12.1 Vdc

DC cord length

6.0 ft

Output current

2.5 A

A.4.2 Input Voltage
The following table provides the input voltage specifications:
Specification

Value

Input voltages

4.75 to 5.25 Vdc

Input current

1.2 A

A–4 Specifications and Parts

A.5 Console Connector Pin-Out (RS–232/DB9)
The following table provides the console connector pin-out:
Pin

Signal

Used/Not Used

DCD

Used

DTR

Used

GND

Used

DSR

Used

RTS

Used

CTS

Used

Not used

A.6 Replacement Parts
The following table lists the replacement parts and order numbers for
DECpacketprobe 900RR:
Replacement Part

Order Number

DECpacketprobe 900RR

DTRMN–MA

Power supply, 110/220 Vac

H7827–BA

Back cover

H0342–AA

9 pin D–sub to MMJ connector

H8571-J

Specifications and Parts A–5

B
Documentation and Ordering
Information
This appendix lists documentation that is related to DECpacketprobe 900RR. It
also provides ordering information.

B.1 Related Documentation
You can order the following documents from Digital:
Document Title

Order Number

DEChub 900 Owner’s Manual

EK–DH2MS–OM

PROBEwatch for ULTRIX User’s Guide

AA–Q0GAA–TE

PROBEwatch for Windows User Manual

AA–Q24FA–TE

B.2 Ordering Information
You can order replacement parts and documentation by mail, phone, or
electronically.
Need Help?
If you need help deciding which documentation best meets your needs, please call
1–800–DIGITAL (1–800–344–4825) and press 2 for technical assistance.
Electronic Orders
To place an order through your account at the Electronic Store, dial
1–800–234–1998, using a modem set to 2400 or 9600 baud. You must use a VT
terminal or terminal emulator set at 8 bits, no parity. If you need help, call
1–800–DIGITAL (1–800–344–4825) and ask for an Electronic Store specialist.

Documentation and Ordering Information B–1

Telephone or Direct Mail Orders
If you are from . . .

Call . . .

Or write . . .

U.S.A.

DECdirect
Phone: 800–DIGITAL
(800–344–4825)
FAX: (603) 884–5597

Digital Equipment Corporation
P.O. Box CS2008
Nashua, NH 03061

Puerto Rico

Phone: (809) 781–0505
FAX: (809) 749–8377

Digital Equipment Caribbean, Inc.
3 Digital Plaza, 1st Street
Suite 200
Metro Office Park
San Juan, Puerto Rico 00920

Canada

Phone: 800–267–6215
FAX: (613) 592–1946

Digital Equipment of Canada Ltd.
100 Herzberg Road
Kanata, Ontario, Canada K2K 2A6
Attn: DECdirect Sales

International

—

Local Digital subsidiary or approved
distributor

Digital Personnel
You can order documentation by electronic mail. Contact the following
organizations for instructions:
If you need . . .

Call . . .

Contact . . .

Software documentation1

DTN: 241–3023
(508) 874–3023

Software Supply Business
Digital Equipment Corporation
1 Digital Drive
Westminster, MA 01473

Hardware documentation

DTN: 234–4325
(508) 351–4325
FAX: (508) 351–4467

Publishing & Circulation Services
Digital Equipment Corporation
NRO2–2/I5
444 Whitney Street
Northboro, MA 01532

1 Call to request an Internal Software Order Form (EN–01740–07).

B–2 Documentation and Ordering Information

Index
A
Agent
managed, 1–2
unmanaged, 2–1
variables, 3–4
Air flow, operating, A–2
Alarm group, 8–1
Altitude
operating, A–2
shipping, A–2

B
Back cover
See Cover
Backplane
connector, 1–9
DEChub 900, 1–2
Backplane configuration
installation, 2–5 to 2–6
problem solving, 4–3
Bootp, 3–7

C
Communities
description of, 1–7
naming community strings, 1–7
configuration
bootp, 3–7
Configuration, 3–1
SLIP, 3–8
SNMP, 3–6

Connecting cables, 2–4
Connection
ring, 3–7
Connection, sample, 1–3
Connectors
backplane, 1–9
description of, 1–9
diagram of, 1–8
power, 1–9
Console
action objects, 3–4
actions, 3–4
help screen, 3–4
main screen, 3–3
starting a session, 3–2
Cover
description of, 1–9
diagram of, 1–8
removal of, 2–2
replacement part, A–5

D
DB9 pin-out, A–5
DC OK indicator, 1–9
DEChub 900, 1–2
Decimal definitions
for object identifier prefix, 5–3
for RMON–MIB object identifier, 5–3
DECpacketprobe 900RR
community strings, 1–7
how it works, 1–2
input current, A–4
input voltage, A–4
replacement parts, A–5

Index–1

Description, 1–2
Dew point, operating, A–2
Dimensions, A–1
Documentation
ordering, B–1
related, B–1
Dot notation, overview of, 5–1
DropEvents statistic, 4–2

LEDs
See also Indicators
description of, 1–9
diagram of, 1–8

Environmental specifications
operating, A–2
shipping, A–2
EtherHistory, 7–5
EtherStats, 6–2
Event group, 14–1

Managed objects, 5–4
Matrix group, 11–1
Multiple management stations
potential conflicts, 5–7
resource sharing, 5–7
row addition, 5–9

Inventory, 2–1

Features, 1–1
Filter group, 12–1

Network
IEEE 802.5, 1–2
management framework, 5–4

H
HistoryControl, 7–2
History group, 7–1
Host group, 9–1
Host Top N group, 10–1
Hot swap, 2–5

I
IEEE 802.5, 1–2
Indicators
DC OK, 1–9
ring activity, 1–9
selftest, 1–9
Input current, A–4
Input voltage, A–4
Installation, 2–1
backplane configuration, 2–5 to 2–6
standalone unit, 2–1
tabletop, 2–1
wallmount, 2–2 to 2–4

Index–2

O
Operating environment, specifications for,
A–2

P
Packet Capture group, 13–1
Parts, replacement, A–5
Performance, influences on, 4–1
Pin-out
DB9, A–5
RS–232, A–5
Power
connector, 1–9
120 Vac, 2–1
240 Vac, 2–1
Power supply, 2–1
current, A–4
frequency, A–4
output current, A–4
output voltage, A–4

Power supply (cont’d)
power consumption, A–4
replacement part, A–5
specifications for, A–3
voltage, A–4
Powerup, 2–7
Problem solving, 4–2
backplane configuration, 4–3 to 4–5
performance conditions, 4–1
standalone unit, 4–2 to 4–3
Protocol
analysis, 4–1
monitoring, 4–1

R
Relative humidity
operating, A–2
shipping, A–2
Remote network monitoring
control of devices, 5–7
goals
multiple managers, 5–6
offline operation, 5–5
pre-emptive monitoring, 5–5
problem detection and reporting,
5–5
value added data, 5–5
management information base, 5–1
overview, 5–5
Removing the back cover, 2–2
Replacement parts
ordering, B–1
order numbers, A–5
Reset, 2–7
RFC
1155, 5–4
1156, 5–4
1157, 5–4
Ring
activity display, 1–9
RMON–MIB, 1–4
groups, 1–4
Structure, 5–6

RS–232 pin-out, A–5

S
Sample connection, 1–3
Shipping environment, specifications for,
A–2
SLIP, 3–8
SNMP
Get, 5–2
Get-next, 5–2
overview of dot notation, 5–1
Set, 5–2
Trap, 5–2
Specifications, A–1 to A–4
dimensions, A–1
environmental, A–2
power supply, A–3
Standalone unit
installation, 2–1, 2–2 to 2–4
problem solving, 4–2
Standards, 1–4

T
Tabletop installation, 2–1
Temperature
operating, A–2
maximum rate of change, A–2
shipping, A–2

W
Wallmount installation, standalone, 2–2
to 2–4
Weight, A–1

Index–3