[Docs] [txt|pdf] [draft-ietf-hubm...] [Tracker] [Diff1] [Diff2]
Obsoleted by: 2108 DRAFT STANDARD
Network Working Group D. McMaster
Request for Comments: 1516 SynOptics Communications, Inc.
Obsoletes: 1368 K. McCloghrie
Hughes LAN Systems, Inc.
September 1993
Definitions of Managed Objects
for IEEE 802.3 Repeater Devices
Status of this Memo
This RFC specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" for the standardization state and status
of this protocol. Distribution of this memo is unlimited.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing IEEE 802.3 10
Mb/second baseband repeaters, sometimes referred to as "hubs."
Table of Contents
1. The Network Management Framework ...................... 2
1.1 Object Definitions ................................... 2
2. Overview .............................................. 2
2.1 Terminology .......................................... 3
2.1.1 Repeaters, Hubs and Concentrators .................. 3
2.1.2 Repeaters, Ports, and MAUs ......................... 3
2.1.3 Ports and Groups ................................... 5
2.1.4 Internal Ports and MAUs ............................ 6
2.2 Supporting Functions ................................. 7
2.3 Structure of MIB ..................................... 9
2.3.1 The Basic Group Definitions ........................ 10
2.3.2 The Monitor Group Definitions ...................... 10
2.3.3 The Address Tracking Group Definitions ............ 10
2.4 Relationship to Other MIBs ........................... 10
2.4.1 Relationship to the 'system' group ................. 10
2.4.2 Relationship to the 'interfaces' group ............. 10
2.5 Textual Conventions .................................. 11
3. Definitions ........................................... 11
3.1 MIB Groups in the Repeater MIB ....................... 12
3.2 The Basic Group Definitions .......................... 13
3.3 The Monitor Group Definitions ........................ 23
McMaster & McCloghrie [Page 1]
RFC 1516 802.3 Repeater MIB September 1993
3.4 The Address Tracking Group Definitions ............... 34
3.5 Traps for use by Repeaters ........................... 36
4. Changes from RFC 1368 ................................. 38
5. Acknowledgments ....................................... 39
6. References ............................................ 39
7. Security Considerations ............................... 40
8. Authors' Addresses .................................... 40
1. The Network Management Framework
The Internet-standard Network Management Framework consists of
three components. They are:
o STD 16, RFC 1155 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.
STD 16, RFC 1212 defines a more concise description mechanism,
which is wholly consistent with the SMI.
o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
for the Internet suite of protocols.
o STD 15, RFC 1157 which defines the SNMP, the protocol used for
network access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
1.1. Object Definitions
Managed objects are accessed via 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)
defined in the SMI. In particular, each object object type is named
by an OBJECT IDENTIFIER, an administratively assigned name. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the descriptor, to
refer to the object type.
2. Overview
Instances of the object types defined in this memo represent
attributes of an IEEE 802.3 (Ethernet-like) repeater, as defined by
Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE
802.3/ISO 8802-3 CSMA/CD standard [7].
These Repeater MIB objects may be used to manage non-standard
repeater-like devices, but defining objects to describe
McMaster & McCloghrie [Page 2]
RFC 1516 802.3 Repeater MIB September 1993
implementation-specific properties of non-standard repeater-like
devices is outside the scope of this memo.
The definitions presented here are based on the IEEE draft standard
P802.3K, "Layer Management for 10 Mb/s Baseband Repeaters" [8].
Implementors of these MIB objects should note that [8] explicitly
describes when, where, and how various repeater attributes are
measured. The IEEE document also describes the effects of repeater
actions that may be invoked by manipulating instances of the MIB
objects defined here.
The counters in this document are defined to be the same as those
counters in the IEEE 802.3 Repeater Management draft, with the
intention that the same instrumentation can be used to implement both
the IEEE and IETF management standards.
2.1. Terminology
2.1.1. Repeaters, Hubs and Concentrators
In late 1988, the IEEE 802.3 Hub Management task force was chartered
to define managed objects for both 802.3 repeaters and the proposed
10BASE-FA synchronous active stars. The term "hub" was used to cover
both repeaters and active stars.
In March, 1991, the active star proposal was dropped from the
10BASE-F draft. Subsequently the 802.3 group changed the name of the
task force to be the IEEE 802.3 Repeater Management Task Force, and
likewise renamed their draft.
The use of the term "hub" has led to some confusion, as the terms
"hub," "intelligent hub," and "concentrator" are often used to
indicate a modular chassis with plug-in modules that provide
generalized LAN/WAN connectivity, often with a mix of 802.3 repeater,
token ring, and FDDI connectivity, internetworked by bridges,
routers, and terminal servers.
To be clear that this work covers the management of IEEE 802.3
repeaters only, the editors of this MIB definitions document chose to
call this a "Repeater MIB" instead of a "Hub MIB."
2.1.2. Repeaters, Ports, and MAUs
The following text roughly defines the terms "repeater," "port," and
"MAU" as used in the context of this memo. This text is imprecise
and omits many technical details. For a more complete and precise
definition of these terms, refer to Section 9 of [7].
McMaster & McCloghrie [Page 3]
RFC 1516 802.3 Repeater MIB September 1993
An IEEE 802.3 repeater connects "Ethernet-like" media segments
together to extend the network length and topology beyond what can be
achieved with a single coax segment. It can be pictured as a star
structure with two or more input/output ports. The diagram below
illustrates a 6-port repeater:
^ ^
| |
\ \ / /
\ \ / /
_____\ v /_____
-> ______ ______ ->
/ ^ \
/ / \ \
/ / \ \
| |
v v
Figure 1. Repeater Unit
All the stations on the media segments connected to a given
repeater's ports participate in a single collision domain. A packet
transmitted by any of these stations is seen by all of these
stations.
Data coming in on any port in the repeater is transmitted out through
each of the remaining n-1 ports. If data comes in to the repeater on
two or more ports simultaneously or the repeater detects a collision
on the incoming port, the repeater transmits a jamming signal out on
all ports for the duration of the collision.
A repeater is a bit-wise store-and-forward device. It is
differentiated from a bridge (a frame store-and-forward device) in
that it is primarily concerned with carrier sense and data bits, and
does not make data-handling decisions based on the legality or
contents of a packet. A repeater retransmits data bits as they are
received. Its data FIFO holds only enough bits to make sure that the
FIFO does not underflow when the data rate of incoming bits is
slightly slower than the repeater's transmission rate.
A repeater is not an end-station on the network, and does not count
toward the overall limit of 1024 stations. A repeater has no MAC
address associated with it, and therefore packets may not be
addressed to the repeater or to its ports. (Packets may be addressed
to the MAC address of a management entity that is monitoring a
repeater. This management entity may or may not be connected to the
network through one of the repeater's ports. How the management
entity obtains information about the activity on the repeater is an
McMaster & McCloghrie [Page 4]
RFC 1516 802.3 Repeater MIB September 1993
implementation issue, and is not discussed in this memo.)
A repeater is connected to the network with Medium Attachment Units
(MAUs), and sometimes through Attachment Unit Interfaces (AUIs) as
well. ("MAUs" are also known as transceivers, and an "AUI" is the
same as a 15-pin Ethernet or DIX connector.)
The 802.3 standard defines a "repeater set" as the "repeater unit"
plus its associated MAUs (and AUIs if present). The "repeater unit"
is defined as the portion of the repeater set that is inboard of the
physical media interfaces. The MAUs may be physically separate from
the repeater unit, or they may be integrated into the same physical
package.
(MAU) (MAU)
\ \ / /
\ \ / /
_____\ v /_____
(MAU) ______ ______ (MAU)
/ ^ \
/ / \ \
/ / \ \
(MAU) (MAU)
Figure 2. Repeater Set
The most commonly-used MAUs are the 10BASE-5 (AUI to thick "yellow"
coax), 10BASE-2 (BNC to thin coax), 10BASE-T (unshielded twisted-
pair), and FOIRL (asynchronous fiber optic inter-repeater link, which
is being combined into the 10BASE-F standard as 10BASE-FL). The
draft 10BASE-F standard also includes the definition for a new
synchronous fiber optic attachment, known as 10BASE-FB.
It should be stressed that the repeater MIB being defined by the IEEE
covers only the repeater unit management - it does not include
management of the MAUs that form the repeater set. The IEEE
recognizes that MAU management should be the same for MAUs connected
to end-stations (DTEs) as it is for MAUs connected to repeaters.
This memo follows the same strategy; the definition of management
information for MAUs is being addressed in a separate memo.
2.1.3. Ports and Groups
Repeaters are often implemented in modular "concentrators," where a
card cage holds several field-replaceable cards. Several cards may
form a single repeater unit, with each card containing one or more of
the repeater's ports. Because of this modular architecture, users
typically identify these repeater ports with a card number plus the
McMaster & McCloghrie [Page 5]
RFC 1516 802.3 Repeater MIB September 1993
port number relative to the card, e.g., Card 3, Port 11.
To support this modular numbering scheme, this document follows the
example of the IEEE Repeater Management draft [8], allowing an
implementor to separate the ports in a repeater into "groups", if
desired. For example, an implementor might choose to represent
field-replaceable units as groups of ports so that the port numbering
would match the modular hardware implementation.
This group mapping is recommended but optional. An implementor may
choose to put all of a modular repeater's ports into a single group,
or to divide the ports into groups that do not match physical
divisions.
The object rptrGroupCapacity, which has a maximum value of 1024,
indicates the maximum number of groups that a given repeater may
contain. The value of rptrGroupCapacity must remain constant from
one management restart to the next.
Each group within the repeater is uniquely identified by a group
number in the range 1..rptrGroupCapacity. Groups may come and go
without causing a management reset, and may be sparsely numbered
within the repeater. For example, in a 12- card cage, cards 3, 5, 6,
and 7 may together form a single repeater, and the implementor may
choose to number them as groups 3, 5, 6, and 7, respectively.
The object rptrGroupPortCapacity, which also has a maximum value of
1024, indicates the maximum number of ports that a given group may
contain. The value of rptrGroupPortCapacity must not change for a
given group. However, a group may be deleted from the repeater and
replaced with a group containing a different number of ports. The
value of rptrGroupLastOperStatusChange will indicate that a change
took place.
Each port within the repeater is uniquely identified by a combination
of group number and port number, where port number is an integer in
the range 1..rptrGroupPortCapacity. As with groups within a
repeater, ports within a group may be sparsely numbered. Likewise,
ports may come and go within a group without causing a management
reset.
2.1.4. Internal Ports and MAUs
Repeater ports may be thought of as sources of traffic into the
repeater. In addition to the externally visible ports mentioned
above, such as those with 10BASE-T MAUs, or AUI ports with external
transceivers, some implementations may have internal ports that are
not obvious to the end-user but are nevertheless sources of traffic
McMaster & McCloghrie [Page 6]
RFC 1516 802.3 Repeater MIB September 1993
into the repeater. Examples include internal management ports,
through which an agent communicates, and ports connecting to a
backplane internal to the implementation.
Some implementations may not manage all of a repeater's ports. For
managed ports, there must be entries in the port table; unmanaged
ports will not show up in the table.
It is the decision of the implementor to select the appropriate
group(s) in which to place internal ports. GroupCapacity for a given
group always reflects the number of MANAGED ports in that group.
If some ports are unmanaged such that not all packet sources are
represented by managed ports, then the sum of the input counters for
the repeater will not equal the actual output of the repeater.
2.2. Supporting Functions
The IEEE 802.3 Hub Management draft [8] defines the following seven
functions and seven signals used to describe precisely when port
counters are incremented. The relationship between the functions and
signals is shown in Figure 3.
The CollisionEvent, ActivityDuration, CarrierEvent, FramingError,
OctetCount, FCSError, and SourceAddress output signals defined here
are not retrievable MIB objects, but rather are concepts used in
defining the MIB objects. The inputs are defined in Section 9 of the
IEEE 802.3 standard [7].
McMaster & McCloghrie [Page 7]
RFC 1516 802.3 Repeater MIB September 1993
+---------+
|Collision|--------------------->CollisionEvent
CollIn(X)+>|Event |
| |Funct | +--------+
| +---------+ |Activity|
| +-------+ |Timing |->ActivityDuration
+>|Carrier| +---->|Funct |
|Event | | +--------+
DataIn(X)->|Funct |+-----+---------------->CarrierEvent
+-------+|
| +-------+
+>|Framing|------------>FramingError
|Funct | +-------+
decodedData---------->| |+>|Octet |
+-------+| |Count |->OctetCount
| |Funct |
| +-------+
| +-------+
Octet | |Cyclic |
Stream +>|Redund.|
| |Check |->FCSError
| |Funct |
| +-------+
| +-------+
| |Source |
+>|Address|->SourceAddress
|Funct |
+-------+
Figure 3. Port Functions Relationship
Collision Event Function: The collision event function asserts the
CollisionEvent signal when the CollIn(X) variable has the value
SQE. The CollisionEvent signal remains asserted until the assertion
of any CarrierEvent signal due to the reception of the following
event.
Carrier Event Function: The carrier event function asserts the
CarrierEvent signal when the repeater exits the IDLE state, Fig 9-2
[7], and the port has been determined to be port N. It deasserts
the CarrierEvent signal when, for a duration of at least Carrier
Recovery Time (Ref: 9.5.6.5 [7]), both the DataIn(N) variable has
the value II and the CollIn(N) variable has the value -SQE. The
value N is the port assigned at the time of transition from the IDLE
state.
Framing Function: The framing function recognizes the boundaries of
an incoming frame by monitoring the CarrierEvent signal and the
McMaster & McCloghrie [Page 8]
RFC 1516 802.3 Repeater MIB September 1993
decoded data stream. Data bits are accepted while the CarrierEvent
signal is asserted. The framing function strips preamble and start
of frame delimiter from the received data stream. The remaining
bits are aligned along octet boundaries. If there is not an
integral number of octets, then FramingError shall be asserted. The
FramingError signal is cleared upon the assertion of the
CarrierEvent signal due to the reception of the following event.
Activity Timing Function: The activity timing function measures the
duration of the assertion of the CarrierEvent signal. This duration
value must be adjusted by removing the value of Carrier Recovery
Time (Ref: 9.5.6.5 [7]) to obtain the true duration of activity on
the network. The output of the Activity Timing function is the
ActivityDuration value, which represents the duration of the
CarrierEvent signal as expressed in units of bit times.
Octet Counting Function: The octet counting function counts the
number of complete octets received from the output of the framing
function. The output of the octet counting function is the
OctetCount value. The OctetCount value is reset to zero upon the
assertion of the CarrierEvent signal due to the reception of the
following event.
Cyclic Redundancy Check Function: The cyclic redundancy check
function verifies that the sequence of octets output by the framing
function contains a valid frame check sequence field. The frame
check sequence field is the last four octets received from the
output of the framing function. The algorithm for generating an FCS
from the octet stream is specified in 3.2.8 [7]. If the FCS
generated according to this algorithm is not the same as the last
four octets received from the framing function then the FCSError
signal is asserted. The FCSError signal is cleared upon the
assertion of the CarrierEvent signal due to the reception of the
following event.
Source Address Function: The source address function extracts
octets from the stream output by the framing function. The seventh
through twelfth octets shall be extracted from the octet stream and
output as the SourceAddress variable. The SourceAddress variable is
set to an invalid state upon the assertion of the CarrierEvent
signal due to the reception of the following event.
2.3. Structure of MIB
Objects in this MIB are arranged into MIB groups. Each MIB group is
organized as a set of related objects.
McMaster & McCloghrie [Page 9]
RFC 1516 802.3 Repeater MIB September 1993
2.3.1. The Basic Group Definitions
This mandatory group contains the objects which are applicable to
all repeaters. It contains status, parameter and control objects
for the repeater as a whole, the port groups within the repeater, as
well as for the individual ports themselves.
2.3.2. The Monitor Group Definitions
This optional group contains monitoring statistics for the repeater
as a whole and for individual ports.
2.3.3. The Address Tracking Group Definitions
This optional group contains objects for tracking the MAC addresses
of the DTEs attached to the ports of the repeater.
2.4. Relationship to Other MIBs
It is assumed that a repeater implementing this MIB will also
implement (at least) the 'system' group defined in MIB-II [3].
2.4.1. Relationship to the 'system' group
In MIB-II, the 'system' group is defined as being mandatory for all
systems such that each managed entity contains one instance of each
object in the 'system' group. Thus, those objects apply to the
entity even if the entity's sole functionality is management of a
repeater.
2.4.2. Relationship to the 'interfaces' group
In MIB-II, the 'interfaces' group is defined as being mandatory for
all systems and contains information on an entity's interfaces,
where each interface is thought of as being attached to a
the Internet suite of protocols.)
This Repeater MIB uses the notion of ports on a repeater. The
concept of a MIB-II interface has NO specific relationship to a
repeater's port. Therefore, the 'interfaces' group applies only to
the one (or more) network interfaces on which the entity managing
the repeater sends and receives management protocol operations, and
does not apply to the repeater's ports.
This is consistent with the physical-layer nature of a repeater. A
repeater is a bitwise store-and-forward device. It recognizes
activity and bits, but does not process incoming data based on any
packet-related information (such as checksum or addresses). A
McMaster & McCloghrie [Page 10]
RFC 1516 802.3 Repeater MIB September 1993
repeater has no MAC address, no MAC implementation, and does not
pass packets up to higher-level protocol entities for processing.
(When a network management entity is observing the repeater, it may
appear as though the repeater is passing packets to a higher-level
protocol entity. However, this is only a means of implementing
management, and this passing of management information is not part
of the repeater functionality.)
2.5. Textual Conventions
The datatype MacAddress is used as a textual convention in this
document. This textual convention has NO effect on either the
syntax nor the semantics of any managed object. Objects defined
using this convention are always encoded by means of the rules that
define their primitive type. Hence, no changes to the SMI or the
SNMP are necessary to accommodate this textual convention which is
adopted merely for the convenience of readers.
3. Definitions
SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter, TimeTicks, Gauge
FROM RFC1155-SMI
DisplayString FROM RFC1213-MIB
TRAP-TYPE FROM RFC-1215
OBJECT-TYPE FROM RFC-1212;
snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }
-- All representations of MAC addresses in this MIB Module use,
-- as a textual convention (i.e., this convention does not affect
-- their encoding), the data type:
MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet address in
-- the "canonical" order
-- defined by IEEE 802.1a, i.e., as if it were transmitted least
-- significant bit first.
-- References
--
-- The following references are used throughout this MIB:
--
McMaster & McCloghrie [Page 11]
RFC 1516 802.3 Repeater MIB September 1993
-- [IEEE 802.3 Std]
-- refers to IEEE 802.3/ISO 8802-3 Information processing
-- systems - Local area networks - Part 3: Carrier sense
-- multiple access with collision detection (CSMA/CD)
-- access method and physical layer specifications
-- (2nd edition, September 21, 1990).
--
-- [IEEE 802.3 Rptr Mgt]
-- refers to IEEE P802.3K, 'Layer Management for 10 Mb/s
-- Baseband Repeaters, Section 19,' Draft Supplement to
-- ANSI/IEEE 802.3, (Draft 8, April 9, 1992)
-- MIB Groups
--
-- The rptrBasicPackage group is mandatory.
-- The rptrMonitorPackage and rptrAddrTrackPackage
-- groups are optional.
rptrBasicPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 1 }
rptrMonitorPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 2 }
rptrAddrTrackPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 3 }
-- object identifiers for organizing the information
-- in the groups by repeater, port-group, and port
rptrRptrInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 1 }
rptrGroupInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 2 }
rptrPortInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 3 }
rptrMonitorRptrInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 }
rptrMonitorGroupInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 }
rptrMonitorPortInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }
rptrAddrTrackRptrInfo -- this subtree is currently unused
McMaster & McCloghrie [Page 12]
RFC 1516 802.3 Repeater MIB September 1993
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 }
rptrAddrTrackGroupInfo -- this subtree is currently unused
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 }
rptrAddrTrackPortInfo
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 }
--
-- The BASIC GROUP
--
-- Implementation of the Basic Group is mandatory for all
-- managed repeaters.
--
-- Basic Repeater Information
--
-- Configuration, status, and control objects for the overall
-- repeater
--
rptrGroupCapacity OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrGroupCapacity is the number of groups
that can be contained within the repeater. Within
each managed repeater, the groups are uniquely
numbered in the range from 1 to rptrGroupCapacity.
Some groups may not be present in the repeater, in
which case the actual number of groups present
will be less than rptrGroupCapacity. The number
of groups present will never be greater than
rptrGroupCapacity.
Note: In practice, this will generally be the
number of field-replaceable units (i.e., modules,
cards, or boards) that can fit in the physical
repeater enclosure, and the group numbers will
correspond to numbers marked on the physical
enclosure."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterGroupCapacity."
::= { rptrRptrInfo 1 }
rptrOperStatus OBJECT-TYPE
McMaster & McCloghrie [Page 13]
RFC 1516 802.3 Repeater MIB September 1993
SYNTAX INTEGER {
other(1), -- undefined or unknown status
ok(2), -- no known failures
rptrFailure(3), -- repeater-related failure
groupFailure(4), -- group-related failure
portFailure(5), -- port-related failure
generalFailure(6) -- failure, unspecified type
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrOperStatus object indicates the
operational state of the repeater. The
rptrHealthText object may be consulted for more
specific information about the state of the
repeater's health.
In the case of multiple kinds of failures (e.g.,
repeater failure and port failure), the value of
this attribute shall reflect the highest priority
failure in the following order, listed highest
priority first:
rptrFailure(3)
groupFailure(4)
portFailure(5)
generalFailure(6)."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterHealthState."
::= { rptrRptrInfo 2 }
rptrHealthText OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The health text object is a text string that
provides information relevant to the operational
state of the repeater. Agents may use this string
to provide detailed information on current
failures, including how they were detected, and/or
instructions for problem resolution. The contents
are agent-specific."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterHealthText."
::= { rptrRptrInfo 3 }
McMaster & McCloghrie [Page 14]
RFC 1516 802.3 Repeater MIB September 1993
rptrReset OBJECT-TYPE
SYNTAX INTEGER {
noReset(1),
reset(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to reset(2) causes a
transition to the START state of Fig 9-2 in
section 9 [IEEE 802.3 Std].
Setting this object to noReset(1) has no effect.
The agent will always return the value noReset(1)
when this object is read.
After receiving a request to set this variable to
reset(2), the agent is allowed to delay the reset
for a short period. For example, the implementor
may choose to delay the reset long enough to allow
the SNMP response to be transmitted. In any
event, the SNMP response must be transmitted.
This action does not reset the management counters
defined in this document nor does it affect the
portAdminStatus parameters. Included in this
action is the execution of a disruptive Self-Test
with the following characteristics: a) The nature
of the tests is not specified. b) The test resets
the repeater but without affecting management
information about the repeater. c) The test does
not inject packets onto any segment. d) Packets
received during the test may or may not be
transferred. e) The test does not interfere with
management functions.
After performing this self-test, the agent will
update the repeater health information (including
rptrOperStatus and rptrHealthText), and send a
rptrHealth trap."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
acResetRepeater."
::= { rptrRptrInfo 4 }
rptrNonDisruptTest OBJECT-TYPE
SYNTAX INTEGER {
noSelfTest(1),
McMaster & McCloghrie [Page 15]
RFC 1516 802.3 Repeater MIB September 1993
selfTest(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to selfTest(2) causes the
repeater to perform a agent-specific, non-
disruptive self-test that has the following
characteristics: a) The nature of the tests is
not specified. b) The test does not change the
state of the repeater or management information
about the repeater. c) The test does not inject
packets onto any segment. d) The test does not
prevent the relay of any packets. e) The test
does not interfere with management functions.
After performing this test, the agent will update
the repeater health information (including
rptrOperStatus and rptrHealthText) and send a
rptrHealth trap.
Note that this definition allows returning an
'okay' result after doing a trivial test.
Setting this object to noSelfTest(1) has no
effect. The agent will always return the value
noSelfTest(1) when this object is read."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
acExecuteNonDisruptiveSelfTest."
::= { rptrRptrInfo 5 }
rptrTotalPartitionedPorts OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object returns the total number of ports in
the repeater whose current state meets all three
of the following criteria: rptrPortOperStatus
does not have the value notPresent(3),
rptrPortAdminStatus is enabled(1), and
rptrPortAutoPartitionState is autoPartitioned(2)."
::= { rptrRptrInfo 6 }
McMaster & McCloghrie [Page 16]
RFC 1516 802.3 Repeater MIB September 1993
--
-- The Basic Port Group Table
--
rptrGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of descriptive and status information about
the groups of ports."
::= { rptrGroupInfo 1 }
rptrGroupEntry OBJECT-TYPE
SYNTAX RptrGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing information
about a single group of ports."
INDEX { rptrGroupIndex }
::= { rptrGroupTable 1 }
RptrGroupEntry ::=
SEQUENCE {
rptrGroupIndex
INTEGER,
rptrGroupDescr
DisplayString,
rptrGroupObjectID
OBJECT IDENTIFIER,
rptrGroupOperStatus
INTEGER,
rptrGroupLastOperStatusChange
TimeTicks,
rptrGroupPortCapacity
INTEGER
}
rptrGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group within the
repeater for which this entry contains
information. This value is never greater than
rptrGroupCapacity."
McMaster & McCloghrie [Page 17]
RFC 1516 802.3 Repeater MIB September 1993
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
aGroupID."
::= { rptrGroupEntry 1 }
rptrGroupDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the group. This value
should include the full name and version
identification of the group's hardware type and
indicate how the group is differentiated from
other types of groups in the repeater. Plug-in
Module, Rev A' or 'Barney Rubble 10BASE-T 4-port
SIMM socket Version 2.1' are examples of valid
group descriptions.
It is mandatory that this only contain printable
ASCII characters."
::= { rptrGroupEntry 2 }
rptrGroupObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The vendor's authoritative identification of the
group. This value may be allocated within the SMI
enterprises subtree (1.3.6.1.4.1) and provides a
straight-forward and unambiguous means for
determining what kind of group is being managed.
For example, this object could take the value
1.3.6.1.4.1.4242.1.2.14 if vendor 'Flintstones,
Inc.' was assigned the subtree 1.3.6.1.4.1.4242,
and had assigned the identifier
1.3.6.1.4.1.4242.1.2.14 to its 'Wilma Flintstone
6-Port FOIRL Plug-in Module.'"
::= { rptrGroupEntry 3 }
rptrGroupOperStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
operational(2),
malfunctioning(3),
notPresent(4),
McMaster & McCloghrie [Page 18]
RFC 1516 802.3 Repeater MIB September 1993
underTest(5),
resetInProgress(6)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An object that indicates the operational status
of the group.
A status of notPresent(4) indicates that the group
is temporarily or permanently physically and/or
logically not a part of the repeater. It is an
implementation-specific matter as to whether the
agent effectively removes notPresent entries from
the table.
A status of operational(2) indicates that the
group is functioning, and a status of
malfunctioning(3) indicates that the group is
malfunctioning in some way."
::= { rptrGroupEntry 4 }
rptrGroupLastOperStatusChange OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An object that contains the value of sysUpTime at
the time that the value of the rptrGroupOperStatus
object for this group last changed.
A value of zero indicates that the group's
operational status has not changed since the agent
last restarted."
::= { rptrGroupEntry 5 }
rptrGroupPortCapacity OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrGroupPortCapacity is the number of ports
that can be contained within the group. Valid
range is 1-1024. Within each group, the ports are
uniquely numbered in the range from 1 to
rptrGroupPortCapacity.
Note: In practice, this will generally be the
McMaster & McCloghrie [Page 19]
RFC 1516 802.3 Repeater MIB September 1993
number of ports on a module, card, or board, and
the port numbers will correspond to numbers marked
on the physical embodiment."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
aGroupPortCapacity."
::= { rptrGroupEntry 6 }
--
-- The Basic Port Table
--
rptrPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of descriptive and status information about
the ports."
::= { rptrPortInfo 1 }
rptrPortEntry OBJECT-TYPE
SYNTAX RptrPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing information
about a single port."
INDEX { rptrPortGroupIndex, rptrPortIndex }
::= { rptrPortTable 1 }
RptrPortEntry ::=
SEQUENCE {
rptrPortGroupIndex
INTEGER,
rptrPortIndex
INTEGER,
rptrPortAdminStatus
INTEGER,
rptrPortAutoPartitionState
INTEGER,
rptrPortOperStatus
INTEGER
}
rptrPortGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
McMaster & McCloghrie [Page 20]
RFC 1516 802.3 Repeater MIB September 1993
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrPortEntry 1 }
rptrPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information. This
value can never be greater than
rptrGroupPortCapacity for the associated group."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrPortEntry 2 }
rptrPortAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to disabled(2) disables the
port. A disabled port neither transmits nor
receives. Once disabled, a port must be
explicitly enabled to restore operation. A port
which is disabled when power is lost or when a
reset is exerted shall remain disabled when normal
operation resumes.
The admin status takes precedence over auto-
partition and functionally operates between the
auto-partition mechanism and the AUI/PMA.
Setting this object to enabled(1) enables the port
and exerts a BEGIN on the port's auto-partition
state machine.
(In effect, when a port is disabled, the value of
rptrPortAutoPartitionState for that port is frozen
until the port is next enabled. When the port
McMaster & McCloghrie [Page 21]
RFC 1516 802.3 Repeater MIB September 1993
becomes enabled, the rptrPortAutoPartitionState
becomes notAutoPartitioned(1), regardless of its
pre-disabling state.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortAdminState and 19.2.6.3, acPortAdminControl."
::= { rptrPortEntry 3 }
rptrPortAutoPartitionState OBJECT-TYPE
SYNTAX INTEGER {
notAutoPartitioned(1),
autoPartitioned(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The autoPartitionState flag indicates whether the
port is currently partitioned by the repeater's
auto-partition protection.
The conditions that cause port partitioning are
specified in partition state machine in Section 9
[IEEE 802.3 Std]. They are not differentiated
here."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAutoPartitionState."
::= { rptrPortEntry 4 }
rptrPortOperStatus OBJECT-TYPE
SYNTAX INTEGER {
operational(1),
notOperational(2),
notPresent(3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object indicates the port's operational
status. The notPresent(3) status indicates the
port is physically removed (note this may or may
not be possible depending on the type of port.)
The operational(1) status indicates that the port
is enabled (see rptrPortAdminStatus) and working,
even though it might be auto-partitioned (see
rptrPortAutoPartitionState).
If this object has the value operational(1) and
McMaster & McCloghrie [Page 22]
RFC 1516 802.3 Repeater MIB September 1993
rptrPortAdminStatus is set to disabled(2), it is
expected that this object's value will soon change
to notOperational(2)."
::= { rptrPortEntry 5 }
--
-- The MONITOR GROUP
--
-- Implementation of this group is optional, but within the
-- group all elements are mandatory. If a managed repeater
-- implements any part of this group, the entire group shall
-- be implemented.
--
-- Repeater Monitor Information
--
-- Performance monitoring statistics for the repeater
--
rptrMonitorTransmitCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented every time the
repeater state machine enters the TRANSMIT
COLLISION state from any state other than ONE PORT
LEFT (Ref: Fig 9-2, IEEE 802.3 Std).
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aTransmitCollisions."
::= { rptrMonitorRptrInfo 1 }
--
-- The Group Monitor Table
--
rptrMonitorGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrMonitorGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of performance and error statistics for the
McMaster & McCloghrie [Page 23]
RFC 1516 802.3 Repeater MIB September 1993
groups."
::= { rptrMonitorGroupInfo 1 }
rptrMonitorGroupEntry OBJECT-TYPE
SYNTAX RptrMonitorGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing total
performance and error statistics for a single
group. Regular retrieval of the information in
this table provides a means of tracking the
performance and health of the networked devices
attached to this group's ports.
The counters in this table are redundant in the
sense that they are the summations of information
already available through other objects. However,
these sums provide a considerable optimization of
network management traffic over the otherwise
necessary retrieval of the individual counters
included in each sum."
INDEX { rptrMonitorGroupIndex }
::= { rptrMonitorGroupTable 1 }
RptrMonitorGroupEntry ::=
SEQUENCE {
rptrMonitorGroupIndex
INTEGER,
rptrMonitorGroupTotalFrames
Counter,
rptrMonitorGroupTotalOctets
Counter,
rptrMonitorGroupTotalErrors
Counter
}
rptrMonitorGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group within the
repeater for which this entry contains
information."
::= { rptrMonitorGroupEntry 1 }
rptrMonitorGroupTotalFrames OBJECT-TYPE
McMaster & McCloghrie [Page 24]
RFC 1516 802.3 Repeater MIB September 1993
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of frames of valid frame length
that have been received on the ports in this group
and for which the FCSError and CollisionEvent
signals were not asserted. This counter is the
summation of the values of the
rptrMonitorPortReadableFrames counters for all of
the ports in the group.
This statistic provides one of the parameters
necessary for obtaining the packet error rate.
The approximate minimum time for rollover of this
counter is 80 hours."
::= { rptrMonitorGroupEntry 2 }
rptrMonitorGroupTotalOctets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of octets contained in the valid
frames that have been received on the ports in
this group. This counter is the summation of the
values of the rptrMonitorPortReadableOctets
counters for all of the ports in the group.
This statistic provides an indicator of the total
data transferred. The approximate minimum time
for rollover of this counter is 58 minutes."
::= { rptrMonitorGroupEntry 3 }
rptrMonitorGroupTotalErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of errors which have occurred on
all of the ports in this group. This counter is
the summation of the values of the
rptrMonitorPortTotalErrors counters for all of the
ports in the group."
::= { rptrMonitorGroupEntry 4 }
--
-- The Port Monitor Table
McMaster & McCloghrie [Page 25]
RFC 1516 802.3 Repeater MIB September 1993
--
rptrMonitorPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrMonitorPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of performance and error statistics for the
ports."
::= { rptrMonitorPortInfo 1 }
rptrMonitorPortEntry OBJECT-TYPE
SYNTAX RptrMonitorPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing performance and
error statistics for a single port."
INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex }
::= { rptrMonitorPortTable 1 }
RptrMonitorPortEntry ::=
SEQUENCE {
rptrMonitorPortGroupIndex
INTEGER,
rptrMonitorPortIndex
INTEGER,
rptrMonitorPortReadableFrames
Counter,
rptrMonitorPortReadableOctets
Counter,
rptrMonitorPortFCSErrors
Counter,
rptrMonitorPortAlignmentErrors
Counter,
rptrMonitorPortFrameTooLongs
Counter,
rptrMonitorPortShortEvents
Counter,
rptrMonitorPortRunts
Counter,
rptrMonitorPortCollisions
Counter,
rptrMonitorPortLateEvents
Counter,
rptrMonitorPortVeryLongEvents
Counter,
rptrMonitorPortDataRateMismatches
McMaster & McCloghrie [Page 26]
RFC 1516 802.3 Repeater MIB September 1993
Counter,
rptrMonitorPortAutoPartitions
Counter,
rptrMonitorPortTotalErrors
Counter
}
rptrMonitorPortGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrMonitorPortEntry 1 }
rptrMonitorPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrMonitorPortEntry 2 }
rptrMonitorPortReadableFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object is the number of frames of valid
frame length that have been received on this port.
This counter is incremented by one for each frame
received on this port whose OctetCount is greater
than or equal to minFrameSize and less than or
equal to maxFrameSize (Ref: IEEE 802.3 Std,
4.4.2.1) and for which the FCSError and
CollisionEvent signals are not asserted.
This statistic provides one of the parameters
necessary for obtaining the packet error rate.
The approximate minimum time for rollover of this
counter is 80 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
McMaster & McCloghrie [Page 27]
RFC 1516 802.3 Repeater MIB September 1993
aReadableFrames."
::= { rptrMonitorPortEntry 3 }
rptrMonitorPortReadableOctets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object is the number of octets contained in
valid frames that have been received on this port.
This counter is incremented by OctetCount for each
frame received on this port which has been
determined to be a readable frame (i.e., including
FCS octets but excluding framing bits and dribble
bits).
This statistic provides an indicator of the total
data transferred. The approximate minimum time
for rollover of this counter is 58 minutes."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aReadableOctets."
::= { rptrMonitorPortEntry 4 }
rptrMonitorPortFCSErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port with the FCSError signal
asserted and the FramingError and CollisionEvent
signals deasserted and whose OctetCount is greater
than or equal to minFrameSize and less than or
equal to maxFrameSize (Ref: 4.4.2.1, IEEE 802.3
Std).
The approximate minimum time for rollover of this
counter is 80 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aFrameCheckSequenceErrors."
::= { rptrMonitorPortEntry 5 }
rptrMonitorPortAlignmentErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
McMaster & McCloghrie [Page 28]
RFC 1516 802.3 Repeater MIB September 1993
DESCRIPTION
"This counter is incremented by one for each frame
received on this port with the FCSError and
FramingError signals asserted and CollisionEvent
signal deasserted and whose OctetCount is greater
than or equal to minFrameSize and less than or
equal to maxFrameSize (Ref: IEEE 802.3 Std,
4.4.2.1). If rptrMonitorPortAlignmentErrors is
incremented then the rptrMonitorPortFCSErrors
Counter shall not be incremented for the same
frame.
The approximate minimum time for rollover of this
counter is 80 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAlignmentErrors."
::= { rptrMonitorPortEntry 6 }
rptrMonitorPortFrameTooLongs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port whose OctetCount is greater
than maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 Std).
If rptrMonitorPortFrameTooLongs is incremented
then neither the rptrMonitorPortAlignmentErrors
nor the rptrMonitorPortFCSErrors counter shall be
incremented for the frame.
The approximate minimum time for rollover of this
counter is 61 days."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aFramesTooLong."
::= { rptrMonitorPortEntry 7 }
rptrMonitorPortShortEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port with ActivityDuration
less than ShortEventMaxTime. ShortEventMaxTime is
greater than 74 bit times and less than 82 bit
McMaster & McCloghrie [Page 29]
RFC 1516 802.3 Repeater MIB September 1993
times. ShortEventMaxTime has tolerances included
to provide for circuit losses between a
conformance test point at the AUI and the
measurement point within the state machine.
Note: shortEvents may indicate externally
generated noise hits which will cause the repeater
to transmit Runts to its other ports, or propagate
a collision (which may be late) back to the
transmitting DTE and damaged frames to the rest of
the network.
Implementors may wish to consider selecting the
ShortEventMaxTime towards the lower end of the
allowed tolerance range to accommodate bit losses
suffered through physical channel devices not
budgeted for within this standard.
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aShortEvents."
::= { rptrMonitorPortEntry 8 }
rptrMonitorPortRunts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port that meets one of the
following two conditions. Only one test need be
made. a) The ActivityDuration is greater than
ShortEventMaxTime and less than ValidPacketMinTime
and the CollisionEvent signal is deasserted. b)
The OctetCount is less than 64, the
ActivityDuration is greater than ShortEventMaxTime
and the CollisionEvent signal is deasserted.
ValidPacketMinTime is greater than or equal to 552
bit times and less than 565 bit times.
An event whose length is greater than 74 bit times
but less than 82 bit times shall increment either
the shortEvents counter or the runts counter but
not both. A CarrierEvent greater than or equal to
552 bit times but less than 565 bit times may or
may not be counted as a runt.
McMaster & McCloghrie [Page 30]
RFC 1516 802.3 Repeater MIB September 1993
ValidPacketMinTime has tolerances included to
provide for circuit losses between a conformance
test point at the AUI and the measurement point
within the state machine.
Runts usually indicate collision fragments, a
normal network event. In certain situations
associated with large diameter networks a
percentage of collision fragments may exceed
ValidPacketMinTime.
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, aRunts."
::= { rptrMonitorPortEntry 9 }
rptrMonitorPortCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for any
CarrierEvent signal on any port for which the
CollisionEvent signal on this port is also
asserted.
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aCollisions."
::= { rptrMonitorPortEntry 10 }
rptrMonitorPortLateEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port in which the CollIn(X)
variable transitions to the value SQE (Ref:
9.6.6.2, IEEE 802.3 Std) while the
ActivityDuration is greater than the
LateEventThreshold. Such a CarrierEvent is
counted twice, as both a collision and as a
lateEvent.
McMaster & McCloghrie [Page 31]
RFC 1516 802.3 Repeater MIB September 1993
The LateEventThreshold is greater than 480 bit
times and less than 565 bit times.
LateEventThreshold has tolerances included to
permit an implementation to build a single
threshold to serve as both the LateEventThreshold
and ValidPacketMinTime threshold.
The approximate minimum time for rollover of this
counter is 81 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLateEvents."
::= { rptrMonitorPortEntry 11 }
rptrMonitorPortVeryLongEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port whose ActivityDuration
is greater than the MAU Jabber Lockup Protection
timer TW3 (Ref: 9.6.1 & 9.6.5, IEEE 802.3 Std).
Other counters may be incremented as appropriate."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aVeryLongEvents."
::= { rptrMonitorPortEntry 12 }
rptrMonitorPortDataRateMismatches OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port that meets all of the
following conditions: a) The CollisionEvent
signal is not asserted. b) The ActivityDuration
is greater than ValidPacketMinTime. c) The
frequency (data rate) is detectably mismatched
from the local transmit frequency. The exact
degree of mismatch is vendor specific and is to be
defined by the vendor for conformance testing.
When this event occurs, other counters whose
increment conditions were satisfied may or may not
also be incremented, at the implementor's
discretion. Whether or not the repeater was able
McMaster & McCloghrie [Page 32]
RFC 1516 802.3 Repeater MIB September 1993
to maintain data integrity is beyond the scope of
this standard."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aDataRateMismatches."
::= { rptrMonitorPortEntry 13 }
rptrMonitorPortAutoPartitions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each time
the repeater has automatically partitioned this
port. The conditions that cause port partitioning
are specified in the partition state machine in
Section 9 [IEEE 802.3 Std]. They are not
differentiated here."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAutoPartitions."
::= { rptrMonitorPortEntry 14 }
rptrMonitorPortTotalErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of errors which have occurred on
this port. This counter is the summation of the
values of other error counters (for the same
port), namely:
rptrMonitorPortFCSErrors,
rptrMonitorPortAlignmentErrors,
rptrMonitorPortFrameTooLongs,
rptrMonitorPortShortEvents,
rptrMonitorPortLateEvents,
rptrMonitorPortVeryLongEvents, and
rptrMonitorPortDataRateMismatches.
This counter is redundant in the sense that it is
the summation of information already available
through other objects. However, it is included
specifically because the regular retrieval of this
object as a means of tracking the health of a port
provides a considerable optimization of network
management traffic over the otherwise necessary
McMaster & McCloghrie [Page 33]
RFC 1516 802.3 Repeater MIB September 1993
retrieval of the summed counters."
::= { rptrMonitorPortEntry 15 }
--
-- The ADDRESS TRACKING GROUP
--
-- Implementation of this group is optional; it is appropriate
-- for all systems which have the necessary instrumentation. If a
-- managed repeater implements any part of this group, the entire
-- group shall be implemented.
--
-- The Port Address Tracking Table
--
rptrAddrTrackTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrAddrTrackEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of address mapping information about the
ports."
::= { rptrAddrTrackPortInfo 1 }
rptrAddrTrackEntry OBJECT-TYPE
SYNTAX RptrAddrTrackEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing address mapping
information about a single port."
INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex }
::= { rptrAddrTrackTable 1 }
RptrAddrTrackEntry ::=
SEQUENCE {
rptrAddrTrackGroupIndex
INTEGER,
rptrAddrTrackPortIndex
INTEGER,
rptrAddrTrackLastSourceAddress -- DEPRECATED OBJECT
MacAddress,
rptrAddrTrackSourceAddrChanges
Counter,
rptrAddrTrackNewLastSrcAddress
OCTET STRING
}
McMaster & McCloghrie [Page 34]
RFC 1516 802.3 Repeater MIB September 1993
rptrAddrTrackGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrAddrTrackEntry 1 }
rptrAddrTrackPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrAddrTrackEntry 2 }
rptrAddrTrackLastSourceAddress OBJECT-TYPE
SYNTAX MacAddress
ACCESS read-only
STATUS deprecated
DESCRIPTION
"This object is the SourceAddress of the last
readable frame (i.e., counted by
rptrMonitorPortReadableFrames) received by this
port.
This object has been deprecated because its value
is undefined when no frames have been observed on
this port. The replacement object is
rptrAddrTrackNewLastSrcAddress."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLastSourceAddress."
::= { rptrAddrTrackEntry 3 }
rptrAddrTrackSourceAddrChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each time
that the rptrAddrTrackLastSourceAddress attribute
for this port has changed.
McMaster & McCloghrie [Page 35]
RFC 1516 802.3 Repeater MIB September 1993
This may indicate whether a link is connected to a
single DTE or another multi-user segment.
The approximate minimum time for rollover of this
counter is 81 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aSourceAddressChanges."
::= { rptrAddrTrackEntry 4 }
rptrAddrTrackNewLastSrcAddress OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0 | 6))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object is the SourceAddress of the last
readable frame (i.e., counted by
rptrMonitorPortReadableFrames) received by this
port. If no frames have been received by this
port since the agent began monitoring the port
activity, the agent shall return a string of
length zero."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLastSourceAddress."
::= { rptrAddrTrackEntry 5 }
-- Traps for use by Repeaters
-- Traps are defined using the conventions in RFC 1215 [6].
rptrHealth TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrHealth trap conveys information related
to the operational status of the repeater. This
trap is sent either when the value of
rptrOperStatus changes, or upon completion of a
non-disruptive test.
The rptrHealth trap must contain the
rptrOperStatus object. The agent may optionally
include the rptrHealthText object in the varBind
list. See the rptrOperStatus and rptrHealthText
objects for descriptions of the information that
is sent.
McMaster & McCloghrie [Page 36]
RFC 1516 802.3 Repeater MIB September 1993
The agent must throttle the generation of
consecutive rptrHealth traps so that there is at
least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
hubHealth notification."
::= 1
rptrGroupChange TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrGroupIndex }
DESCRIPTION
"This trap is sent when a change occurs in the
group structure of a repeater. This occurs only
when a group is logically or physically removed
from or added to a repeater. The varBind list
contains the identifier of the group that was
removed or added.
The agent must throttle the generation of
consecutive rptrGroupChange traps for the same
group so that there is at least a five-second gap
between traps of this type. When traps are
throttled, they are dropped, not queued for
sending at a future time. (Note that 'generating'
a trap means sending to all configured
recipients.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
groupMapChange notification."
::= 2
rptrResetEvent TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrResetEvent trap conveys information
related to the operational status of the repeater.
This trap is sent on completion of a repeater
reset action. A repeater reset action is defined
as an a transition to the START state of Fig 9-2
in section 9 [IEEE 802.3 Std], when triggered by a
management command (e.g., an SNMP Set on the
rptrReset object).
McMaster & McCloghrie [Page 37]
RFC 1516 802.3 Repeater MIB September 1993
The agent must throttle the generation of
consecutive rptrResetEvent traps so that there is
at least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)
The rptrResetEvent trap is not sent when the agent
restarts and sends an SNMP coldStart or warmStart
trap. However, it is recommended that a repeater
agent send the rptrOperStatus object as an
optional object with its coldStart and warmStart
trap PDUs.
The rptrOperStatus object must be included in the
varbind list sent with this trap. The agent may
optionally include the rptrHealthText object as
well."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset
notification."
::= 3
END
4. Changes from RFC 1368
(1) Added section 2.1.4, "Internal Ports and MAUs," that defines
internal ports and clarifies how they may or may not be
managed.
(2) Noted that the failure list for rptrOperStatus is ordered
highest priority first.
(3) Clarified rptrReset description to indicate that the agent
may briefly delay the reset action.
(4) For rptrReset, clarified the actions that the agent should
take after performing the reset and self-test.
(5) For rptrNonDisruptTest, similar change to (3).
(6) Clarified that the rptrNonDisruptTest description allows
returning "ok" after doing only a trivial test.
(7) Deprecated rptrAddrTrackLastSourceAddress and defined a
McMaster & McCloghrie [Page 38]
RFC 1516 802.3 Repeater MIB September 1993
replacement object that has a zero-length value until the
first frame is seen on the port.
(8) Clarified that rptrHealth trap is sent after
rptrNonDisruptTest even if repeater health information
doesn't change as a result of the test.
(9) Clarified text on throttling traps.
5. Acknowledgments
This document is the work of the IETF Hub MIB Working Group. It is
based on drafts of the IEEE 802.3 Repeater Management Task Force.
6. References
[1] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, Performance Systems International, Hughes LAN Systems, May
1990.
[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[3] McCloghrie K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets", STD 17,
RFC 1213, Performance Systems International, March 1991.
[4] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
[5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Performance Systems International, Hughes LAN
Systems, March 1991.
[6] Rose, M., Editor, "A Convention for Defining Traps for use with
the SNMP", RFC 1215, Performance Systems International, March
1991.
[7] IEEE 802.3/ISO 8802-3 - Information processing systems - Local
area networks - Part 3: Carrier sense multiple access with
collision detection (CSMA/CD) access method and physical layer
specifications, 2nd edition, 21 September 1990.
McMaster & McCloghrie [Page 39]
RFC 1516 802.3 Repeater MIB September 1993
[8] IEEE P802.3K - Layer Management for 10 Mb/s Baseband Repeaters,
Section 19, Draft Supplement to ANSI/IEEE 802.3, Draft 8, 9
April 1992.
7. Security Considerations
Security issues are not discussed in this memo.
8. Authors' Addresses
Donna McMaster
SynOptics Communications, Inc.
4401 Great America Parkway
P.O. Box 58185
Santa Clara, CA 95052-8185
Phone: (408) 764-1206
EMail: mcmaster@synoptics.com
Keith McCloghrie
Hughes LAN Systems, Inc.
1225 Charleston Road
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.com
McMaster & McCloghrie [Page 40]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/
