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