RFC2108 - Definitions of Managed Objects for IEEE 802.3 Repe

时间:2005-02-15 来源: 作者: 点击:
Network Working Group K. de Graaf Request for Comments: 2108 3Com Corporation Obsoletes: 1516 D. Romascanu Category: Standards Track Madge Networks (Israel) Ltd. D. McMaster Coloma Communications K. McCloghrie Cisco Systems Inc. February 1997 Definit
  Network Working Group K. de Graaf
Request for Comments: 2108 3Com Corporation
Obsoletes: 1516 D. Romascanu
Category: Standards Track Madge Networks (Israel) Ltd.
D. McMaster
Coloma Communications
K. McCloghrie
Cisco Systems Inc.
February 1997

Definitions of Managed Objects
for IEEE 802.3 Repeater Devices
using SMIv2

Status of this Memo

This document 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" (STD 1) 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 and 100
Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10
& 100 Mb/s Management," October 26, 1995.

Table of Contents

1. The SNMP Network Management Framework.................... 2
1.1. Object Definitions..................................... 2
2. Overview................................................. 2
2.1. Relationship to RFC1516............................... 2
2.2. Repeater Management.................................... 3
2.3. Structure of the MIB................................... 4
2.3.1. Basic Definitions.................................... 4
2.3.2. Monitor Definitions.................................. 4
2.3.3. Address Tracking Definitions......................... 4
2.3.4. Top N Definitions.................................... 4
2.4. Relationship to Other MIBs............................. 4
2.4.1. Relationship to MIB-II............................... 4
2.4.1.1. Relationship to the 'system' group................. 5
2.4.1.2. Relationship to the 'interfaces' group............. 5
3. Definitions............................................... 6

4. Topology Mapping......................................... 75
5. Acknowledgements......................................... 79
6. References............................................... 80
7. Security Considerations.................................. 81
8. Authors' Addresses....................................... 81

1. The SNMP Network Management Framework

The SNMP Network Management Framework presently consists of three
major components. They are:

o the SMI, described in RFC1902 [6] - the mechanisms used
for describing and naming objects for the purpose of
management.

o the MIB-II, STD 17, RFC1213 [5] - the core set of
managed objects for the Internet suite of protocols.

o the protocol, STD 15, RFC1157 [10] and/or RFC1905
[9] - the protocol used for accessing managed information.

Textual conventions are defined in RFC1903 [7], and conformance
statements are defined in RFC1904 [8].

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 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

2.1. Relationship to RFC1516

This MIB is intended as a superset of that defined by RFC1516 [11],
which will go to historic status. This MIB includes all of the
objects contained in that MIB, plus several new ones which provide

for significant additional capabilities. Implementors are encouraged
to support all applicable conformance groups in order to make the
best use of the new functionality provided by this MIB. The new
objects provide support for:

o multiple repeaters

o 100BASE-T management

o port TopN capability

o address search and topology mapping

Certain objects have been deprecated; in particular, those scalar
objects used for managing a single repeater are now of minimal use
since they are duplicated in the new multiple- repeater definitions.
Additional objects have been deprecated based on implementation
experience with RFC1516.

2.2. Repeater Management

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 [1], and Section 27, "Repeater for
100 Mb/s Baseband Networks" in the IEEE Standard 802.3u-1995 [2].

These Repeater MIB objects may be used to manage non-standard
repeater-like devices, but defining objects to describe
implementation-specific properties of non-standard repeater- like
devices is outside the scope of this memo.

The definitions presented here are based on Section 30.4, "Layer
Management for 10 and 100 Mb/s Baseband Repeaters" and Annex 30A,
"GDMO Specificataions for 802.3 managed objects" of [3].

Implementors of these MIB objects should note that [3] 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 [3], with the intention that the same instrumentation can
be used to implement both the IEEE and IETF management standards.

2.3. Structure of the MIB

Objects in this MIB are arranged into packages, each of which
contains a set of related objects within a broad functional category.
Objects within a package are generally defined under the same OID
subtree. These packages are intended for organizational convenience
ONLY, and have no relation to the conformance groups defined later in
the document.

2.3.1. Basic Definitions

The basic definitions include objects which are applicable to all
repeaters: status, parameter and control objects for each repeater
within the managed system, for the port groups within the system, and
for the individual ports themselves.

2.3.2. Monitor Definitions

The monitor definitions include monitoring statistics for each
repeater within the system and for individual ports.

2.3.3. Address Tracking Definitions

This collection includes objects for tracking the MAC addresses of
the DTEs attached to the ports within the system and for mapping the
topology of a network.

Note: These definitions are based on a technology which has been
patented by Hewlett-Packard Company. HP has granted rights to this
technology to implementors of this MIB. See [12] and [13] for
details.

2.3.4. Top N Definitions

These objects may be used for tracking the ports with the most
activity within the system or within particular repeaters.

2.4. Relationship to Other MIBs

2.4.1. Relationship to MIB-II

It is assumed that a repeater implementing this MIB will also
implement (at least) the 'system' group defined in MIB-II [5].

2.4.1.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
repeaters.

2.4.1.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 'subnetwork'.
(Note that this term is not to be confused with 'subnet' which refers
to an addressing partitioning scheme used in 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
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 a 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.)

3. Definitions

SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN

IMPORTS
Counter32, Counter64, Integer32, Gauge32, TimeTicks,
OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, mib-2
FROM SNMPv2-SMI
TimeStamp, DisplayString, MacAddress, TEXTUAL-CONVENTION,
RowStatus, TestAndIncr
FROM SNMPv2-TC
OBJECT-GROUP, MODULE-COMPLIANCE
FROM SNMPv2-CONF
OwnerString
FROM IF-MIB;

snmpRptrMod MODULE-IDENTITY
LAST-UPDATED "9609140000Z"
ORGANIZATION "IETF HUB MIB Working Group"
CONTACT-INFO
"WG E-mail: hubmib@hprnd.rose.hp.com

Chair: Dan Romascanu
Postal: Madge Networks (Israel) Ltd.
Atidim Technology Park, Bldg. 3
Tel Aviv 61131, Israel
Tel: 972-3-6458414, 6458458
Fax: 972-3-6487146
E-mail: dromasca@madge.com

Editor: Kathryn de Graaf
Postal: 3Com Corporation
118 Turnpike Rd.
Southborough, MA 01772 USA
Tel: (508)229-1627
Fax: (508)490-5882
E-mail: kdegraaf@isd.3com.com"
DESCRIPTION
"Management information for 802.3 repeaters.

The following references are used throughout
this MIB module:

[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 (1993).

[IEEE 802.3 Mgt]
refers to IEEE 802.3u-1995, '10 Mb/s &
100 Mb/s Management, Section 30,'
Supplement to ANSI/IEEE 802.3.

The following terms are used throughout this
MIB module. For complete formal definitions,
the IEEE 802.3 standards should be consulted
wherever possible:

System - A managed entity compliant with this
MIB, and incorporating at least one managed
802.3 repeater.

Chassis - An enclosure for one managed repeater,
part of a managed repeater, or several managed
repeaters. It typically contains an integral
power supply and a variable number of available
module slots.

Repeater-unit - The portion of the repeater set
that is inboard of the physical media interfaces.
The physical media interfaces (MAUs, AUIs) may be
physically separated from the repeater-unit, or
they may be integrated into the same physical
package.

Trivial repeater-unit - An isolated port that can
gather statistics.

Group - A recommended, but optional, entity
defined by the IEEE 802.3 management standard,
in order to support a modular numbering scheme.
The classical example allows an implementor to
represent field-replaceable units as groups of
ports, with the port numbering matching the
modular hardware implementation.

System interconnect segment - An internal
segment allowing interconnection of ports
belonging to different physical entities
into the same logical manageable repeater.
Examples of implementation might be
backplane busses in modular hubs, or
chaining cables in stacks of hubs.

Stack - A scalable system that may include
managed repeaters, in which modularity is
achieved by interconnecting a number of
different chassis.

Module - A building block in a modular
chassis. It typically maps into one 'slot';
however, the range of configurations may be
very large, with several modules entering
one slot, or one module covering several
slots.
"
REVISION "9309010000Z"
DESCRIPTION
"Published as RFC1516"
REVISION "9210010000Z"
DESCRIPTION
"Published as RFC1368"
::= { snmpDot3RptrMgt 5 }

snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }

OptMacAddr ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x:"
STATUS current
DESCRIPTION
"Either a 6 octet address in the `canonical'
order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first
if a value is available or a zero length string."
REFERENCE
"See MacAddress in SNMPv2-TC. The only difference
is that a zero length string is allowed as a value
for OptMacAddr and not for MacAddress."
SYNTAX OCTET STRING (SIZE (0 | 6))

-- Basic information at the repeater, group, and port level.

rptrBasicPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 1 }
rptrRptrInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 1 }
rptrGroupInfo

OBJECT IDENTIFIER ::= { rptrBasicPackage 2 }
rptrPortInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 3 }
rptrAllRptrInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 4 }

-- Monitoring information at the repeater, group, and port level.
rptrMonitorPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 2 }
rptrMonitorRptrInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 }
rptrMonitorGroupInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 }
rptrMonitorPortInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }
rptrMonitorAllRptrInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 4 }

-- Address tracking information at the repeater, group,
-- and port level.
rptrAddrTrackPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 3 }
rptrAddrTrackRptrInfo
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 }
rptrAddrTrackGroupInfo
-- this subtree is currently unused
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 }
rptrAddrTrackPortInfo
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 }

-- TopN information.
rptrTopNPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 4 }
rptrTopNRptrInfo
-- this subtree is currently unused
OBJECT IDENTIFIER ::= { rptrTopNPackage 1 }
rptrTopNGroupInfo
-- this subtree is currently unused
OBJECT IDENTIFIER ::= { rptrTopNPackage 2 }
rptrTopNPortInfo
OBJECT IDENTIFIER ::= { rptrTopNPackage 3 }

-- Old version of basic information at the repeater level.
--
-- In a system containing a single managed repeater,
-- configuration, status, and control objects for the overall
-- repeater.

--
-- The objects contained under the rptrRptrInfo subtree are
-- intended for backwards compatibility with implementations of
-- RFC1516 [11]. In newer implementations (both single- and
-- multiple-repeater implementations) the rptrInfoTable should
-- be implemented. It is the preferred source of this information,
-- as it contains the values for all repeaters managed by the
-- agent. In all cases, the objects in the rptrRptrInfo subtree
-- are duplicates of the corresponding objects in the first entry
-- of the rptrInfoTable.

rptrGroupCapacity OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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
"[IEEE 802.3 Mgt], 30.4.1.1.3,
aRepeaterGroupCapacity."
::= { rptrRptrInfo 1 }

rptrOperStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- undefined or unknown
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

}
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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
"[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState."
::= { rptrRptrInfo 2 }

rptrHealthText OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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
"[IEEE 802.3 Mgt], 30.4.1.1.6, aRepeaterHealthText."
::= { rptrRptrInfo 3 }

rptrReset OBJECT-TYPE
SYNTAX INTEGER {
noReset(1),
reset(2)

}
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

Setting this object to reset(2) causes a
transition to the START state of Fig 9-2 in
section 9 [IEEE 802.3 Std] for a 10Mb/s repeater,
and the START state of Fig 27-2 in section 27
of that standard for a 100Mb/s repeater.

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
"[IEEE 802.3 Mgt], 30.4.1.2.1, acResetRepeater."
::= { rptrRptrInfo 4 }

rptrNonDisruptTest OBJECT-TYPE
SYNTAX INTEGER {
noSelfTest(1),
selfTest(2)

}
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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
"[IEEE 802.3 Mgt], 30.4.1.2.2,
acExecuteNonDisruptiveSelfTest."
::= { rptrRptrInfo 5 }

rptrTotalPartitionedPorts OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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 }

-- Basic information at the group level.
--
-- Configuration and status objects for each
-- managed group in the system, independent
-- of whether there is one or more managed
-- repeater-units in the system.

rptrGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table of descriptive and status information about
the groups of ports."
::= { rptrGroupInfo 1 }

rptrGroupEntry OBJECT-TYPE
SYNTAX RptrGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table, containing information
about a single group of ports."
INDEX { rptrGroupIndex }
::= { rptrGroupTable 1 }

RptrGroupEntry ::=
SEQUENCE {
rptrGroupIndex
Integer32,
rptrGroupDescr
DisplayString,
rptrGroupObjectID
OBJECT IDENTIFIER,
rptrGroupOperStatus
INTEGER,
rptrGroupLastOperStatusChange
TimeTicks,
rptrGroupPortCapacity
Integer32
}

rptrGroupIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the group within the

system for which this entry contains
information."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.2.1.1, aGroupID."
::= { rptrGroupEntry 1 }

rptrGroupDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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
MAX-ACCESS read-only
STATUS current
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),
underTest(5),
resetInProgress(6)
}
MAX-ACCESS read-only
STATUS current
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
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

An object that contains the value of sysUpTime at
the time when the last of the following occurred:
1) the agent cold- or warm-started;
2) the row for the group was created (such
as when the group was added to the system); or
3) the value of rptrGroupOperStatus for the
group 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 Integer32 (1..2147483647)
MAX-ACCESS read-only

STATUS current
DESCRIPTION
"The rptrGroupPortCapacity is the number of ports
that can be contained within the group. Valid
range is 1-2147483647. Within each group, the
ports are uniquely numbered in the range from 1 to
rptrGroupPortCapacity.

Some ports may not be present in the system, in
which case the actual number of ports present
will be less than the value of rptrGroupPortCapacity.
The number of ports present in the group will never
be greater than the value of rptrGroupPortCapacity.

Note: In practice, this will generally be the
number of ports on a module, card, or board, and
the port numbers will correspond to numbers marked
on the physical embodiment."
REFERENCE
"IEEE 802.3 Mgt, 30.4.2.1.2, aGroupPortCapacity."
::= { rptrGroupEntry 6 }

-- Basic information at the port level.
--
-- Configuration and status objects for
-- each managed repeater port in the system,
-- independent of whether there is one or more
-- managed repeater-units in the system.

rptrPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrPortEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table of descriptive and status information about
the repeater ports in the system. The number of
entries is independent of the number of repeaters
in the managed system."
::= { rptrPortInfo 1 }

rptrPortEntry OBJECT-TYPE
SYNTAX RptrPortEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table, containing information
about a single port."

INDEX { rptrPortGroupIndex, rptrPortIndex }
::= { rptrPortTable 1 }

RptrPortEntry ::=
SEQUENCE {
rptrPortGroupIndex
Integer32,
rptrPortIndex
Integer32,
rptrPortAdminStatus
INTEGER,
rptrPortAutoPartitionState
INTEGER,
rptrPortOperStatus
INTEGER,
rptrPortRptrId
Integer32
}

rptrPortGroupIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrPortEntry 1 }

rptrPortIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information. This
identifies the port independently from the repeater
it may be attached to. The numbering scheme for
ports is implementation specific; however, this
value can never be greater than
rptrGroupPortCapacity for the associated group."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.3.1.1, aPortID."
::= { rptrPortEntry 2 }

rptrPortAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)

}
MAX-ACCESS read-write
STATUS current
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
becomes enabled, the rptrPortAutoPartitionState
becomes notAutoPartitioned(1), regardless of its
pre-disabling state.)"
REFERENCE
"[IEEE 802.3 Mgt], 30.4.3.1.2, aPortAdminState
and 30.4.3.2.1, acPortAdminControl."
::= { rptrPortEntry 3 }

rptrPortAutoPartitionState OBJECT-TYPE
SYNTAX INTEGER {
notAutoPartitioned(1),
autoPartitioned(2)
}
MAX-ACCESS read-only
STATUS current
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 Sections
9 and 27 of [IEEE 802.3 Std]. They are not
differentiated here."
REFERENCE

"[IEEE 802.3 Mgt], 30.4.3.1.3, aAutoPartitionState."
::= { rptrPortEntry 4 }

rptrPortOperStatus OBJECT-TYPE
SYNTAX INTEGER {
operational(1),
notOperational(2),
notPresent(3)
}
MAX-ACCESS read-only
STATUS current
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
rptrPortAdminStatus is set to disabled(2), it is
expected that this object's value will soon change
to notOperational(2)."
::= { rptrPortEntry 5 }

rptrPortRptrId OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the repeater to
which this port belongs. The repeater
identified by a particular value of this object
is the same as that identified by the same
value of rptrInfoId. A value of zero
indicates that this port currently is not
a member of any repeater."
::= { rptrPortEntry 6 }

-- New version of basic information at the repeater level.
--
-- Configuration, status, and control objects for
-- each managed repeater in the system.

rptrInfoTable OBJECT-TYPE

SYNTAX SEQUENCE OF RptrInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of information about each
non-trivial repeater. The number of entries
depends on the physical configuration of the
managed system."
::= { rptrAllRptrInfo 1 }

rptrInfoEntry OBJECT-TYPE
SYNTAX RptrInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table, containing information
about a single non-trivial repeater."
INDEX { rptrInfoId }
::= { rptrInfoTable 1 }

RptrInfoEntry ::=
SEQUENCE {
rptrInfoId
Integer32,
rptrInfoRptrType
INTEGER,
rptrInfoOperStatus
INTEGER,
rptrInfoReset
INTEGER,
rptrInfoPartitionedPorts
Gauge32,
rptrInfoLastChange
TimeStamp
}

rptrInfoId OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the repeater for which
this entry contains information."
::= { rptrInfoEntry 1 }

rptrInfoRptrType OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- undefined or unknown

tenMb(2),
onehundredMbClassI(3),
onehundredMbClassII(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The rptrInfoRptrType returns a value that identifies
the CSMA/CD repeater type."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.1.1.2, aRepeaterType."
::= { rptrInfoEntry 2 }

rptrInfoOperStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
ok(2),
failure(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The rptrInfoOperStatus object indicates the
operational state of the repeater."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState."
::= { rptrInfoEntry 3 }

rptrInfoReset OBJECT-TYPE
SYNTAX INTEGER {
noReset(1),
reset(2)
}
MAX-ACCESS read-write
STATUS current
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] for a 10Mb/s repeater,
and to the START state of Fig 27-2 in section 27
of that standard for a 100Mb/s repeater.

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
rptrInfoOperStatus), and send a rptrInfoResetEvent
notification."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.1.2.1, acResetRepeater."
::= { rptrInfoEntry 4 }

rptrInfoPartitionedPorts OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
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)."
::= { rptrInfoEntry 5 }

rptrInfoLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when any of the following
conditions occurred:
1) agent cold- or warm-started;
2) this instance of repeater was created

(such as when a device or module was
added to the system);
3) a change in the value of rptrInfoOperStatus;
4) ports were added or removed as members of
the repeater; or
5) any of the counters associated with this
repeater had a discontinuity."
::= { rptrInfoEntry 6 }

--
-- Old version of statistics at the repeater level.
--
-- Performance monitoring statistics for the repeater
--
-- In a system containing a single managed repeater-unit,
-- the statistics object for the repeater-unit.

-- The objects contained under the rptrMonitorRptrInfo subtree are
-- intended for backwards compatibility with implementations of
-- RFC1516 [11]. In newer implementations (both single- and
-- multiple-repeater implementations), the rptrMonitorTable will
-- be implemented. It is the preferred source of this information,
-- as it contains the values for all repeaters managed by the
-- agent. In all cases, the objects in the rptrMonitorRptrInfo
-- subtree are duplicates of the corresponding objects in the
-- first entry of the rptrMonitorTable.

rptrMonitorTransmitCollisions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

For a clause 9 (10Mb/s) repeater, 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]).

For a clause 27 repeater, this counter is
incremented every time the repeater core state
diagram enters the Jam state as a result of
Activity(ALL) > 1 (fig 27-2 [IEEE 802.3 Std]).

The approximate minimum time for rollover of this
counter is 16 hours in a 10Mb/s repeater and 1.6
hours in a 100Mb/s repeater."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.1.1.8, aTransmitCollisions."
::= { rptrMonitorRptrInfo 1 }

-- Statistics at the group level.
--
-- In a system containing a single managed repeater-unit,
-- the statistics objects for each group.

rptrMonitorGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrMonitorGroupEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

Table of performance and error statistics for the
groups within the repeater. The number of entries
is the same as that in the rptrGroupTable."
::= { rptrMonitorGroupInfo 1 }

rptrMonitorGroupEntry OBJECT-TYPE
SYNTAX RptrMonitorGroupEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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.

Note: Group-level counters are

deprecated in this MIB. It is recommended
that management applications instead use
the repeater-level counters contained in
the rptrMonTable."
INDEX { rptrMonitorGroupIndex }
::= { rptrMonitorGroupTable 1 }

RptrMonitorGroupEntry ::=
SEQUENCE {
rptrMonitorGroupIndex
Integer32,
rptrMonitorGroupTotalFrames
Counter32,
rptrMonitorGroupTotalOctets
Counter32,
rptrMonitorGroupTotalErrors
Counter32
}

rptrMonitorGroupIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

This object identifies the group within the
repeater for which this entry contains
information."
::= { rptrMonitorGroupEntry 1 }

rptrMonitorGroupTotalFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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 in a 10Mb/s repeater."
::= { rptrMonitorGroupEntry 2 }

rptrMonitorGroupTotalOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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 in a
10Mb/s repeater."
::= { rptrMonitorGroupEntry 3 }

rptrMonitorGroupTotalErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********

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 }

-- Statistics at the port level.
--

rptrMonitorPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrMonitorPortEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table of performance and error statistics for the
ports. The number of entries is the same as that

in the rptrPortTable.

The columnar object rptrMonitorPortLastChange
is used to indicate possible discontinuities
of counter type columnar objects in the table."
::= { rptrMonitorPortInfo 1 }

rptrMonitorPortEntry OBJECT-TYPE
SYNTAX RptrMonitorPortEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table, containing performance and
error statistics for a single port."
INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex }
::= { rptrMonitorPortTable 1 }

RptrMonitorPortEntry ::=
SEQUENCE {
rptrMonitorPortGroupIndex
Integer32,
rptrMonitorPortIndex
Integer32,
rptrMonitorPortReadableFrames
Counter32,
rptrMonitorPortReadableOctets
Counter32,
rptrMonitorPortFCSErrors
Counter32,
rptrMonitorPortAlignmentErrors
Counter32,
rptrMonitorPortFrameTooLongs
Counter32,
rptrMonitorPortShortEvents
Counter32,
rptrMonitorPortRunts
Counter32,
rptrMonitorPortCollisions
Counter32,
rptrMonitorPortLateEvents
Counter32,
rptrMonitorPortVeryLongEvents
Counter32,
rptrMonitorPortDataRateMismatches
Counter32,
rptrMonitorPortAutoPartitions
Counter32,
rptrMonitorPortTotalErrors

Counter32,
rptrMonitorPortLastChange
TimeStamp
}

rptrMonitorPortGroupIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrMonitorPortEntry 1 }

rptrMonitorPortIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.3.1.1, aPortID."
::= { rptrMonitorPortEntry 2 }

rptrMonitorPortReadableFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
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.

A discontinuity may occur in the value
when the value of object
rptrMonitorPortLastChange changes.

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 at 10Mb/s."
REFERENCE

"[IEEE 802.3 Mgt], 30.4.3.1.4, aReadableFrames."
::= { rptrMonitorPortEntry 3 }

rptrMonitorPortReadableOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
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).

A discontinuity may occur in the value
when the value of object
rptrMonitorPortLastChange changes.

This statistic provides an indicator of the total
data transferred. The approximate minimum time
for rollover of this counter in a 10Mb/s repeater
is 58 minutes.

For ports receiving traffic at a maximum rate in
a 100Mb/s repeater, this counter can roll over
in less than 6 minutes. Since that amount of time
could be less than a management station's poll cycle
time, in order to avoid a loss of information a
management station is advised to also poll the
rptrMonitorPortUpper32Octets object, or to use the
64-bit counter defined by
rptrMonitorPortHCReadableOctets instead of the
two 32-bit counters."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.3.1.5, aReadableOctets."
::= { rptrMonitorPortEntry 4 }

rptrMonitorPortFCSErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
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).

A discontinuity may occur in the value
when the value of object
rptrMonitorPortLastChange changes.

The approximate minimum time for rollover of this
counter is 80 hours at 10Mb/s."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.3.1.6,
aFrameCheckSequenceErrors."
::= { rptrMonitorPortEntry 5 }

rptrMonitorPortAlignmentErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
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.

A discontinuity may occur in the value
when the value of object
rptrMonitorPortLastChange changes.

The approximate minimum time for rollover of this
counter is 80 hours at 10Mb/s."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.3.1.7, aAlignmentErrors."
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容