rfc2108.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,751 行 · 第 1/5 页
TXT
1,751 行
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.
de Graaf, et. al. Standards Track [Page 7]
RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
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 RFC 1516"
REVISION "9210010000Z"
DESCRIPTION
"Published as RFC 1368"
::= { 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
de Graaf, et. al. Standards Track [Page 8]
RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
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.
de Graaf, et. al. Standards Track [Page 9]
RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
--
-- The objects contained under the rptrRptrInfo subtree are
-- intended for backwards compatibility with implementations of
-- RFC 1516 [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
de Graaf, et. al. Standards Track [Page 10]
RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
}
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)
de Graaf, et. al. Standards Track [Page 11]
RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
}
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)
de Graaf, et. al. Standards Track [Page 12]
RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
}
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.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?