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 RFC 1516............................... 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 de Graaf, et. al. Standards Track [Page 1] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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 RFC 1902 [6] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [5] - the core set of managed objects for the Internet suite of protocols. o the protocol, STD 15, RFC 1157 [10] and/or RFC 1905 [9] - the protocol used for accessing managed information. Textual conventions are defined in RFC 1903 [7], and conformance statements are defined in RFC 1904 [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 RFC 1516 This MIB is intended as a superset of that defined by RFC 1516 [11], which will go to historic status. This MIB includes all of the objects contained in that MIB, plus several new ones which provide de Graaf, et. al. Standards Track [Page 2] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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 RFC 1516. 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. de Graaf, et. al. Standards Track [Page 3] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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]. de Graaf, et. al. Standards Track [Page 4] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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.) de Graaf, et. al. Standards Track [Page 5] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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 de Graaf, et. al. Standards Track [Page 6] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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. 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. 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 } de Graaf, et. al. Standards Track [Page 13] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 -- 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 de Graaf, et. al. Standards Track [Page 14] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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), de Graaf, et. al. Standards Track [Page 15] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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 de Graaf, et. al. Standards Track [Page 16] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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." de Graaf, et. al. Standards Track [Page 17] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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) de Graaf, et. al. Standards Track [Page 18] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 } 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 de Graaf, et. al. Standards Track [Page 19] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 "[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 de Graaf, et. al. Standards Track [Page 20] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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 de Graaf, et. al. Standards Track [Page 21] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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 de Graaf, et. al. Standards Track [Page 22] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 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 de Graaf, et. al. Standards Track [Page 23] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 (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 -- RFC 1516 [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]). de Graaf, et. al. Standards Track [Page 24] RFC 2108 802.3 Repeater