diff options
Diffstat (limited to 'doc/rfc/rfc2266.txt')
| -rw-r--r-- | doc/rfc/rfc2266.txt | 3139 |
1 files changed, 3139 insertions, 0 deletions
diff --git a/doc/rfc/rfc2266.txt b/doc/rfc/rfc2266.txt new file mode 100644 index 0000000..05719d5 --- /dev/null +++ b/doc/rfc/rfc2266.txt @@ -0,0 +1,3139 @@ + + + + + + +Network Working Group J. Flick +Request for Comments: 2266 Hewlett Packard Company +Category: Standards Track January 1998 + + + + Definitions of Managed Objects for IEEE 802.12 Repeater Devices + + +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. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in TCP/IP-based internets. + In particular, it defines objects for managing network repeaters + based on IEEE 802.12. + + +Table of Contents + + 1. The SNMP Network Management Framework ...................... 2 + 1.1. Object Definitions ....................................... 2 + 2. Overview ................................................... 2 + 2.1. Repeater Management Model ................................ 3 + 2.2. MAC Addresses ............................................ 4 + 2.3. Master Mode and Slave Mode ............................... 4 + 2.4. IEEE 802.12 Training Frames .............................. 4 + 2.5. Structure of the MIB ..................................... 6 + 2.5.1. Basic Definitions ...................................... 7 + 2.5.2. Monitor Definitions .................................... 7 + 2.5.3. Address Tracking Definitions ........................... 7 + 2.6. Relationship to other MIBs ............................... 7 + 2.6.1. Relationship to MIB-II ................................. 7 + 2.6.1.1. Relationship to the 'system' group ................... 7 + 2.6.1.2. Relationship to the 'interfaces' group ............... 8 + 2.6.2. Relationship to the 802.3 Repeater MIB ................. 8 + + + +Flick Standards Track [Page 1] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + 2.7. Mapping of IEEE 802.12 Managed Objects ................... 9 + 3. Definitions ................................................ 12 + 4. Acknowledgements ........................................... 53 + 5. References ................................................. 53 + 6. Security Considerations .................................... 54 + 7. Author's Address ........................................... 55 + 8. Full Copyright Statement ................................... 56 + +1. The SNMP Network Management Framework + + The SNMP Network Management Framework consists of several components. + For the purpose of this specification, the applicable components of + the Framework are the SMI and related documents [2, 3, 4], which + define the mechanisms used for describing and naming objects for the + purpose of management. + + 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 (MIB). Objects in the MIB are + defined using the subset of Abstract Syntax Notation One (ASN.1) [1] + defined in the SMI [2]. 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 + + Instances of these object types represent attributes of an IEEE + 802.12 repeater, as defined by Section 12, "RMAC Protocol" in IEEE + Standard 802.12-1995 [6]. + + The definitions presented here are based on Section 13, "Layer + management functions and services", and Annex C, "GDMO Specifications + for Demand Priority Managed Objects" of IEEE Standard 802.12-1995 + [6]. + + Implementors of these MIB objects should note that the IEEE document + explicitly describes (in the form of Pascal pseudocode) 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. + + + + +Flick Standards Track [Page 2] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + The counters in this document are defined to be the same as those + counters in IEEE Standard 802.12-1995, with the intention that the + same instrumentation can be used to implement both the IEEE and IETF + management standards. + +2.1. Repeater Management Model + + The model used in the design of this MIB allows for a managed system + to contain one or more managed 802.12 repeaters, and one or more + managed 802.12 repeater ports. + + A repeater port may be thought of as a source of traffic into a + repeater in the system. The vgRptrBasicPortTable contains entries + for each physical repeater port in the managed system. An + implementor may choose to separate these ports into "groups". For + example, a group may be used to represent a field-replaceable unit, + so that the port numbering may match the numbering in the hardware + implementation. Note that this group mapping is recommended but + optional. An implementor may choose to put all of the system's ports + into a single group, or to divide the ports into groups that do not + match physical divisions. Each group within the system is uniquely + identified by a group number. Each port within a system is uniquely + identified by a combination of group number and port number. The + method of numbering groups and ports is implementation-specific. + Both groups and ports may be sparsely numbered. + + In addition to the externally visible ports, some implementations may + have internal ports that are not obvious to the end-user but are + nevertheless sources of traffic into the repeater system. Examples + include internal management ports, through which an agent + communicates, and ports connecting to a backplane internal to the + implementation. It is the decision of the implementor to select the + appropriate group(s) in which to place internal ports. + + Managed repeaters in the system are represented by entries in the + vgRptrInfoTable. There may be multiple repeaters in the managed + system. They are uniquely identified by a repeater number. The + method of numbering repeaters is implementation-specific. Each port + will either be associated with one of the repeaters, or isolated (a + so-called "trivial" repeater). The set of ports associated with a + single repeater will be in the same contention domain, and will be + participating in the same instance of the Demand Priority Access + Method protocol. The mapping of ports to repeaters may be static or + dynamic. A column in the vgRptrBasicPortTable, + vgRptrPortRptrInfoIndex, indicates the repeater that the port is + currently associated with. The method for assigning a port to a + repeater is implementation-specific. + + + + +Flick Standards Track [Page 3] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + +2.2. MAC Addresses + + All representations of MAC addresses in this MIB module are in + "canonical" order defined by 802.1a, i.e., as if it were transmitted + least significant bit first. This is true even if the repeater is + operating in token ring framing mode, which requires MAC addresses to + be transmitted most significant bit first. + +2.3. Master Mode and Slave Mode + + In an IEEE 802.12 network, "master" devices act as network + controllers to decide when to grant requesting end-nodes permission + to transmit. These master devices may be repeaters, or other active + controller devices such as switches. + + Devices which do not act as network controllers, such as end-nodes or + passive switches, are considered to be operating in "slave" mode. + + An 802.12 repeater always acts in "master" mode on its local ports, + which may connect to end nodes, switch or other device ports acting + in "slave" mode, or lower-level repeaters in a cascade. It acts in + "slave" mode on cascade ports, which may connect to an upper-level + repeater in a cascade, or to switch or other device ports operating + in "master" mode. + +2.4. IEEE 802.12 Training Frames + + Training frames are special MAC frames that are used only during link + initialization. Training frames are initially constructed by the + device at the "lower" end of a link, which is the slave mode device + for the link. The training frame format is as follows: + + +----+----+------------+--------------+----------+-----+ + | DA | SA | Req Config | Allow Config | Data | FCS | + +----+----+------------+--------------+----------+-----+ + + DA = destination address (six octets) + SA = source address (six octets) + Req Config = requested configuration (2 octets) + Allow Config = allowed configuration (2 octets) + Data = data (594 to 675 octets) + FCS = frame check sequence (4 octets) + + Training frames are always sent with a null destination address. To + pass training, an end node must use its source address in the source + address field of the training frame. A repeater may use a non-null + source address if it has one, or it may use a null source address. + + + + +Flick Standards Track [Page 4] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + The requested configuration field allows the slave mode device to + inform the master mode device about itself and to request + configuration options. The training response frame from the master + mode device contains the slave mode device's requested configuration + from the training request frame. The currently defined format of the + requested configuration field as defined in the IEEE Standard + 802.12-1995 standard is shown below. Please refer to the most + current version of the IEEE document for a more up to date + description of this field. In particular, the reserved bits may be + used in later versions of the standard. + + First Octet: Second Octet: + + 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + |v|v|v|r|r|r|r|r| |r|r|r|F|F|P|P|R| + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + + vvv: The version of the 802.12 training protocol with which + the training initiator is compliant. The current version + is 100. Note that because of the different bit ordering + used in IEEE and IETF documents, this value corresponds + to version 1. + r: Reserved bits (set to zero) + FF: 00 = frameType88023 + 01 = frameType88025 + 10 = reserved + 11 = frameTypeEither + PP: 00 = singleAddressMode + 01 = promiscuousMode + 10 = reserved + 11 = reserved + R: 0 = the training initiator is an end node + 1 = the training initiator is a repeater + + The allowed configuration field allows the master mode device to + respond with the allowed configuration. The slave mode device sets + the contents of this field to all zero bits. The master mode device + sets the allowed configuration field as follows: + + First Octet: Second Octet: + + 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + |v|v|v|D|C|N|r|r| |r|r|r|F|F|P|P|R| + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + + + + + +Flick Standards Track [Page 5] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + vvv: The version of the 802.12 training protocol with which + the training responder is compliant. The current version + is 100. Note that because of the different bit ordering + used in IEEE and IETF documents, this value corresponds + to version 1. + D: 0 = No duplicate address has been detected. + 1 = Duplicate address has been detected. + C: 0 = The requested configuration is compatible with the + network and the attached port. + 1 = The requested configuration is not compatible with + the network and/or the attached port. In this case, + the FF, PP, and R bits indicate a configuration that + would be allowed. + N: 0 = Access will be allowed, providing the configuration + is compatible (C = 0). + 1 = Access is not granted because of security + restrictions. + r: Reserved bits (set to zero). + FF: 00 = frameType88023 will be used. + 01 = frameType88025 will be used. + 10 = reserved + 11 = reserved + PP: 00 = singleAddressMode + 01 = promiscuousMode + 10 = reserved + 11 = reserved + R: 0 = Requested access as an end node is allowed. + 1 = Requested access as a repeater is allowed. + + Again, note that the most recent version of the IEEE 802.12 standard + should be consulted for the most up to date definition of the + requested configuration and allowed configuration fields. + + The data field contains between 594 and 675 octets and is filled in + by the training initiator. The first 55 octets may be used for + vendor specific protocol information. The remaining octets are all + zeros. The length of the training frame combined with the + requirement that 24 consecutive training frames be exchanged without + error to complete training ensures that marginal links will not + complete training. + +2.5. Structure of the MIB + + Objects in this MIB are arranged into OID subtrees, each of which + contains a set of related objects within a broad functional category. + These subtrees are intended for organizational convenience ONLY, and + have no relation to the conformance groups defined later in the + document. + + + +Flick Standards Track [Page 6] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + +2.5.1. Basic Definitions + + The basic definitions include objects for managing the basic status + and control parameters for each repeater within the managed system, + for the port groups within the managed system, and for the individual + ports themselves. + +2.5.2. Monitor Definitions + + The monitor definitions include monitoring statistics for each + repeater within the system and for individual ports. + +2.5.3. Address Tracking Definitions + + This collection includes objects for tracking the MAC addresses of + the DTEs attached to the ports within the system. + + Note that this MIB also includes by reference a collection of objects + from the 802.3 Repeater MIB which may be used for mapping the + topology of a network. These definitions are based on a technology + which has been patented by Hewlett-Packard Company (HP). HP has + granted rights to this technology to implementors of this MIB. See + [8] and [9] for details. + +2.6. Relationship to other MIBs + +2.6.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.6.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. + + Note that all of the managed repeaters (i.e. entries in the + vgRptrInfoTable) will normally exist within a single naming scope. + Therefore, there will normally only be a single instance of each of + the objects in the system group for the entire managed repeater + system regardless of how many managed repeaters there are in the + system. + + + + + + +Flick Standards Track [Page 7] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + +2.6.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. An + 802.12 repeater has an RMAC implementation, which acts as the + repeater end of the Demand Priority Access Method, but does not + contain a DTE 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.) + +2.6.2. Relationship to the 802.3 Repeater MIB + + An IEEE 802.12 repeater can be configured to operate in either + ethernet or token ring framing mode. This only affects the frame + format and address bit order of the frames on the wire. An 802.12 + network does not use the media access protocol for either ethernet or + token ring. Instead, IEEE 802.12 defines its own media access + protocol, the Demand Priority Access Method (DPAM). + + There is an existing standards-track MIB module for instrumenting + IEEE 802.3 repeaters [7]. That MIB module is designed to instrument + the operation of the repeater in a network implementing the 802.3 + media access protocol. Therefore, much of that MIB does not apply to + 802.12 repeaters. + + However, the 802.3 Repeater MIB also contains a collection of objects + that may be used to map the topology of a network. These objects are + contained in a separable OBJECT-GROUP, are not 802.3-specific, and + are considered useful for 802.12 repeaters. In addition, the layer + + + + +Flick Standards Track [Page 8] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + management clause of the IEEE 802.12 specification includes similar + functionality. Therefore, vendors of agents for 802.12 repeaters are + encouraged to implement the snmpRptrGrpRptrAddrSearch OBJECT-GROUP + defined in the 802.3 Repeater MIB. + +2.7. Mapping of IEEE 802.12 Managed Objects + + IEEE 802.12 Managed Object Corresponding SNMP Object + + oRepeater + .aCurrentFramingType vgRptrInfoCurrentFramingType + .aDesiredFramingType vgRptrInfoDesiredFramingType + .aFramingCapability vgRptrInfoFramingCapability + .aMACAddress vgRptrInfoMACAddress + .aRepeaterHealthState vgRptrInfoOperStatus + .aRepeaterID vgRptrInfoIndex + .aRepeaterSearchAddress SNMP-REPEATER-MIB - + rptrAddrSearchAddress + .aRepeaterSearchGroup SNMP-REPEATER-MIB - + rptrAddrSearchGroup + .aRepeaterSearchPort SNMP-REPEATER-MIB - + rptrAddrSearchPort + .aRepeaterSearchState SNMP-REPEATER-MIB - + rptrAddrSearchState + .aRMACVersion vgRptrInfoTrainingVersion + .acRepeaterSearchAddress SNMP-REPEATER-MIB - + rptrAddrSearchAddress + .acResetRepeater vgRptrInfoReset + .nRepeaterHealth vgRptrHealth + .nRepeaterReset vgRptrResetEvent + + oGroup + .aGroupCablesBundled vgRptrGroupCablesBundled + .aGroupID vgRptrGroupIndex + .aGroupPortCapacity vgRptrGroupPortCapacity + + oPort + .aAllowableTrainingType vgRptrPortAllowedTrainType + .aBroadcastFramesReceived vgRptrPortBroadcastFrames + .aCentralMgmtDetectedDupAddr vgRptrMgrDetectedDupAddress + .aDataErrorFramesReceived vgRptrPortDataErrorFrames + .aHighPriorityFramesReceived vgRptrPortHighPriorityFrames + .aHighPriorityOctetsReceived vgRptrPortHCHighPriorityOctets, or + vgRptrPortHighPriorityOctets and + vgRptrPortHighPriOctetRollovers + .aIPMFramesReceived vgRptrPortIPMFrames + .aLastTrainedAddress vgRptrAddrLastTrainedAddress + .aLastTrainingConfig vgRptrPortLastTrainConfig + + + +Flick Standards Track [Page 9] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + .aLocalRptrDetectedDupAddr vgRptrRptrDetectedDupAddress + .aMulticastFramesReceived vgRptrPortMulticastFrames + .aNormalPriorityFramesReceived vgRptrPortNormPriorityFrames + .aNormalPriorityOctetsReceived vgRptrPortHCNormPriorityOctets, or + vgRptrPortNormPriorityOctets and + vgRptrPortNormPriOctetRollovers + .aNullAddressedFramesReceived vgRptrPortNullAddressedFrames + .aOctetsInUnreadableFramesRcvd vgRptrPortHCUnreadableOctets, or + vgRptrPortUnreadableOctets and + vgRptrPortUnreadOctetRollovers + .aOversizeFramesReceived vgRptrPortOversizeFrames + .aPortAdministrativeState vgRptrPortAdminStatus + .aPortID vgRptrPortIndex + .aPortStatus vgRptrPortOperStatus + .aPortType vgRptrPortType + .aPriorityEnable vgRptrPortPriorityEnable + .aPriorityPromotions vgRptrPortPriorityPromotions + .aReadableFramesReceived vgRptrPortReadableFrames + .aReadableOctetsReceived vgRptrPortHCReadableOctets, or + vgRptrPortReadableOctets and + vgRptrPortReadOctetRollovers + .aSupportedCascadeMode vgRptrPortSupportedCascadeMode + .aSupportedPromiscMode vgRptrPortSupportedPromiscMode + .aTrainedAddressChanges vgRptrAddrTrainedAddressChanges + .aTrainingResult vgRptrPortTrainingResult + .aTransitionsIntoTraining vgRptrPortTransitionToTrainings + .acPortAdministrativeControl vgRptrPortAdminStatus + + The following IEEE 802.12 managed objects have not been included in + the 802.12 Repeater MIB for the indicated reasons. + + IEEE 802.12 Managed Object Disposition + + oRepeater + .aGroupMap Can be determined by GetNext sweep + of vgRptrBasicGroupTable + + .aRepeaterGroupCapacity Meaning is unclear in many + repeater implementations. For + example, some cards may have + daughter cards which make group + capacity change depending on the + cards installed. Meaning is also + unclear in a stackable + implementation. Also, since + groups are not required to be + numbered from 1..capacity, but may + be computed algorithmically or + + + +Flick Standards Track [Page 10] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + related to Entity MIB indices, + this object was not considered + useful. + + .aRepeaterHealthData Since the data is implementation + specific and non-interoperable, + it was not considered useful. + + .aRepeaterHealthText Implementation experience with + similar object in 802.3 Rptr MIB + indicated it was not useful. + + .acExecuteNonDisruptiveSelfTest Implementation experience with + similar object in 802.3 Rptr MIB + indicated it was not useful. + + .nGroupMapChange Since aGroupMap was not included, + a notification of a change in that + object was not needed. + + oGroup + .aPortMap Can be determined by GetNext sweep + of vgRptrBasicPortTable + .nPortMapChange Since aPortMap was not included, + a notification of a change in that + object was not needed. + + oPort + .aMediaType This object is a function of the + Physical Media Dependent (PMD) + layer, which is defined + differently for each type of + network. For an 802.3 network, + .aMediaType corresponds to the PMD + definitions in the 802.3 MAU MIB. + For management of an 802.12 + network, mapping of this object is + deferred to future work on an + 802.12 PMD MIB which will include + both repeater and interface PMD + information and redundant link + support. + + + + + + + + + +Flick Standards Track [Page 11] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + +3. Definitions + + DOT12-RPTR-MIB DEFINITIONS ::= BEGIN + + IMPORTS + mib-2, Integer32, Counter32, Counter64, + OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE + FROM SNMPv2-SMI + MacAddress, TruthValue, TimeStamp + FROM SNMPv2-TC + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF; + + vgRptrMIB MODULE-IDENTITY + LAST-UPDATED "9705192256Z" -- May 19, 1997 + ORGANIZATION "IETF 100VG-AnyLAN Working Group" + CONTACT-INFO + "WG E-mail: vgmib@hprnd.rose.hp.com + + Chair: Jeff Johnson + Postal: RedBack Networks + 2570 North First Street, Suite 410 + San Jose, CA 95131 + Tel: +1 408 571 2699 + Fax: +1 408 571 2698 + E-mail: jeff@redbacknetworks.com + + Editor: John Flick + Postal: Hewlett Packard Company + 8000 Foothills Blvd. M/S 5556 + Roseville, CA 95747-5556 + Tel: +1 916 785 4018 + Fax: +1 916 785 3583 + E-mail: johnf@hprnd.rose.hp.com" + DESCRIPTION + "This MIB module describes objects for managing + IEEE 802.12 repeaters." + ::= { mib-2 53 } + + vgRptrObjects OBJECT IDENTIFIER ::= { vgRptrMIB 1 } + vgRptrBasic OBJECT IDENTIFIER ::= { vgRptrObjects 1 } + vgRptrBasicRptr OBJECT IDENTIFIER ::= { vgRptrBasic 1 } + + vgRptrInfoTable OBJECT-TYPE + SYNTAX SEQUENCE OF VgRptrInfoEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +Flick Standards Track [Page 12] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + "A table of information about each 802.12 repeater + in the managed system." + ::= { vgRptrBasicRptr 1 } + + vgRptrInfoEntry OBJECT-TYPE + SYNTAX VgRptrInfoEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the table, containing information + about a single repeater." + INDEX { vgRptrInfoIndex } + ::= { vgRptrInfoTable 1 } + + VgRptrInfoEntry ::= + SEQUENCE { + vgRptrInfoIndex Integer32, + vgRptrInfoMACAddress MacAddress, + vgRptrInfoCurrentFramingType INTEGER, + vgRptrInfoDesiredFramingType INTEGER, + vgRptrInfoFramingCapability INTEGER, + vgRptrInfoTrainingVersion INTEGER, + vgRptrInfoOperStatus INTEGER, + vgRptrInfoReset INTEGER, + vgRptrInfoLastChange TimeStamp + } + + vgRptrInfoIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique identifier for the repeater for which + this entry contains information. The numbering + scheme for repeaters is implementation specific." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.2.1, + aRepeaterID." + ::= { vgRptrInfoEntry 1 } + + vgRptrInfoMACAddress OBJECT-TYPE + SYNTAX MacAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The MAC address used by the repeater when it + initiates training on the uplink port. Repeaters + are allowed to train with an assigned MAC address + + + +Flick Standards Track [Page 13] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + or a null (all zeroes) MAC address." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.2.1, + aMACAddress." + ::= { vgRptrInfoEntry 2 } + + vgRptrInfoCurrentFramingType OBJECT-TYPE + SYNTAX INTEGER { + frameType88023(1), + frameType88025(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of framing (802.3 or 802.5) currently + in use by the repeater." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.2.1, + aCurrentFramingType." + ::= { vgRptrInfoEntry 3 } + + vgRptrInfoDesiredFramingType OBJECT-TYPE + SYNTAX INTEGER { + frameType88023(1), + frameType88025(2) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The type of framing which will be used by the + repeater after the next time it is reset. + + The value of this object should be preserved + across repeater resets and power failures." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.2.1, + aDesiredFramingType." + ::= { vgRptrInfoEntry 4 } + + vgRptrInfoFramingCapability OBJECT-TYPE + SYNTAX INTEGER { + frameType88023(1), + frameType88025(2), + frameTypeEither(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Flick Standards Track [Page 14] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + "The type of framing this repeater is capable of + supporting." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.2.1, + aFramingCapability." + ::= { vgRptrInfoEntry 5 } + + vgRptrInfoTrainingVersion OBJECT-TYPE + SYNTAX INTEGER (0..7) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The highest version bits (vvv bits) supported by + the repeater during training." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.2.1, + aRMACVersion." + ::= { vgRptrInfoEntry 6 } + + vgRptrInfoOperStatus OBJECT-TYPE + SYNTAX INTEGER { + other(1), + ok(2), + generalFailure(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The vgRptrInfoOperStatus object indicates the + operational state of the repeater." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.2.1, + aRepeaterHealthState." + ::= { vgRptrInfoEntry 7 } + + vgRptrInfoReset OBJECT-TYPE + SYNTAX INTEGER { + noReset(1), + reset(2) + } + + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Setting this object to reset(2) causes the + repeater to transition to its initial state as + specified in clause 12 [IEEE Std 802.12]. + + + + +Flick Standards Track [Page 15] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + 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 vgRptrPortAdminStatus parameters. + Included in this action is the execution of a + disruptive Self-Test with the following + characteristics: + + 1) The nature of the tests is not specified. + 2) The test resets the repeater but without + affecting configurable management + information about the repeater. + 3) Packets received during the test may or + may not be transferred. + 4) The test does not interfere with + management functions. + + After performing this self-test, the agent will + update the repeater health information (including + vgRptrInfoOperStatus), and send a + vgRptrResetEvent." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.2.2, + acResetRepeater." + ::= { vgRptrInfoEntry 8 } + + vgRptrInfoLastChange 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); + + + +Flick Standards Track [Page 16] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + 3) a change in the value of + vgRptrInfoOperStatus; + 4) ports were added or removed as members of + the repeater; or + 5) any of the counters associated with this + repeater had a discontinuity." + ::= { vgRptrInfoEntry 9 } + + vgRptrBasicGroup OBJECT IDENTIFIER ::= { vgRptrBasic 2 } + + vgRptrBasicGroupTable OBJECT-TYPE + SYNTAX SEQUENCE OF VgRptrBasicGroupEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table containing information about groups of + ports." + ::= { vgRptrBasicGroup 1 } + + vgRptrBasicGroupEntry OBJECT-TYPE + SYNTAX VgRptrBasicGroupEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the vgRptrBasicGroupTable, containing + information about a single group of ports." + INDEX { vgRptrGroupIndex } + ::= { vgRptrBasicGroupTable 1 } + + VgRptrBasicGroupEntry ::= + SEQUENCE { + vgRptrGroupIndex Integer32, + vgRptrGroupObjectID OBJECT IDENTIFIER, + vgRptrGroupOperStatus INTEGER, + vgRptrGroupPortCapacity Integer32, + vgRptrGroupCablesBundled INTEGER + } + + vgRptrGroupIndex OBJECT-TYPE + SYNTAX Integer32 (1..2146483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object identifies the group within the + system for which this entry contains information. + The numbering scheme for groups is implementation + specific." + REFERENCE + + + +Flick Standards Track [Page 17] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + "IEEE Standard 802.12-1995, 13.2.4.4.1, + aGroupID." + ::= { vgRptrBasicGroupEntry 1 } + + vgRptrGroupObjectID 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 Plug-in Module.'" + ::= { vgRptrBasicGroupEntry 2 } + + vgRptrGroupOperStatus 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 system. 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 + + + +Flick Standards Track [Page 18] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + malfunctioning(3) indicates that the group is + malfunctioning in some way." + ::= { vgRptrBasicGroupEntry 3 } + + vgRptrGroupPortCapacity OBJECT-TYPE + SYNTAX Integer32 (1..2146483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The vgRptrGroupPortCapacity 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 vgRptrGroupPortCapacity. + + 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 vgRptrGroupPortCapacity. + The number of ports present is never greater than + the value of vgRptrGroupPortCapacity. + + 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 Standard 802.12-1995, 13.2.4.4.1, + aGroupPortCapacity." + ::= { vgRptrBasicGroupEntry 4 } + + vgRptrGroupCablesBundled OBJECT-TYPE + SYNTAX INTEGER { + someCablesBundled(1), + noCablesBundled(2) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object is used to indicate whether there are + any four-pair UTP links connected to this group + that are contained in a cable bundle with multiple + four-pair groups (e.g. a 25-pair bundle). Bundled + cable may only be used for repeater-to-end node + links where the end node is not in promiscuous + mode. + + When a broadcast or multicast packet is received + from a port on this group that is not a + + + +Flick Standards Track [Page 19] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + promiscuous or cascaded port, the packet will be + buffered completely before being repeated if + this object is set to 'someCablesBundled(1)'. + When this object is equal to 'noCablesBundled(2)', + all packets received from ports on this group will + be repeated as the frame is being received. + + Note that the value 'someCablesBundled(1)' will + work in the vast majority of all installations, + regardless of whether or not any cables are + physically in a bundle, since packets received + from promiscuous and cascaded ports automatically + avoid the store and forward. The main situation + in which 'noCablesBundled(2)' is beneficial is + when there is a large amount of multicast traffic + and the cables are not in a bundle. + + The value of this object should be preserved + across repeater resets and power failures." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.4.1, + aGroupCablesBundled." + ::= { vgRptrBasicGroupEntry 5 } + + vgRptrBasicPort OBJECT IDENTIFIER ::= { vgRptrBasic 3 } + + vgRptrBasicPortTable OBJECT-TYPE + SYNTAX SEQUENCE OF VgRptrBasicPortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table containing configuration and status + information about 802.12 repeater ports in the + system. The number of entries is independent of + the number of repeaters in the managed system." + ::= { vgRptrBasicPort 1 } + + vgRptrBasicPortEntry OBJECT-TYPE + SYNTAX VgRptrBasicPortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the vgRptrBasicPortTable, containing + information about a single port." + INDEX { vgRptrGroupIndex, vgRptrPortIndex } + ::= { vgRptrBasicPortTable 1 } + + VgRptrBasicPortEntry ::= + + + +Flick Standards Track [Page 20] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + SEQUENCE { + vgRptrPortIndex Integer32, + vgRptrPortType INTEGER, + vgRptrPortAdminStatus INTEGER, + vgRptrPortOperStatus INTEGER, + vgRptrPortSupportedPromiscMode INTEGER, + vgRptrPortSupportedCascadeMode INTEGER, + vgRptrPortAllowedTrainType INTEGER, + vgRptrPortLastTrainConfig OCTET STRING, + vgRptrPortTrainingResult OCTET STRING, + vgRptrPortPriorityEnable TruthValue, + vgRptrPortRptrInfoIndex Integer32 + } + + vgRptrPortIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + 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 + vgRptrGroupPortCapacity for the associated group." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aPortID." + ::= { vgRptrBasicPortEntry 1 } + + vgRptrPortType OBJECT-TYPE + SYNTAX INTEGER { + cascadeExternal(1), + cascadeInternal(2), + localExternal(3), + localInternal(4) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Describes the type of port. One of the + following: + + cascadeExternal - Port is an uplink with + physical connections which + are externally visible + cascadeInternal - Port is an uplink with + + + +Flick Standards Track [Page 21] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + physical connections which + are not externally visible, + such as a connection to an + internal backplane in a + chassis + localExternal - Port is a downlink or local + port with externally + visible connections + localInternal - Port is a downlink or local + port with connections which + are not externally visible, + such as a connection to an + internal agent + + 'internal' is used to identify ports which place + traffic into the repeater, but do not have any + external connections. Note that both DTE and + cascaded repeater downlinks are considered + 'local' ports." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aPortType." + ::= { vgRptrBasicPortEntry 2 } + + vgRptrPortAdminStatus OBJECT-TYPE + SYNTAX INTEGER { + enabled(1), + disabled(2) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Port enable/disable function. Enabling a + disabled port will cause training to be + initiated by the training initiator (the slave + mode device) on the link. 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 value of this object should be preserved + across repeater resets and power failures." + REFERENCE + + + +Flick Standards Track [Page 22] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aPortAdministrativeState." + ::= { vgRptrBasicPortEntry 3 } + + vgRptrPortOperStatus OBJECT-TYPE + SYNTAX INTEGER { + active(1), + inactive(2), + training(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Current status for the port as specified by the + PORT_META_STATE in the port process module of + clause 12 [IEEE Std 802.12]. + + During initialization or any link warning + conditions, vgRptrPortStatus will be + 'inactive(2)'. + + When Training_Up is received by the repeater on a + local port (or when Training_Down is received on + a cascade port), vgRptrPortStatus will change to + 'training(3)' and vgRptrTrainingResult can be + monitored to see the detailed status regarding + training. + + When 24 consecutive good FCS packets are exchanged + and the configuration bits are OK, + vgRptrPortStatus will change to 'active(1)'. + + A disabled port shall have a port status of + 'inactive(2)'." + REFERENCE + "IEEE Standard 802.12, 13.2.4.5.1, + aPortStatus." + ::= { vgRptrBasicPortEntry 4 } + + vgRptrPortSupportedPromiscMode OBJECT-TYPE + SYNTAX INTEGER { + singleModeOnly(1), + singleOrPromiscMode(2), + promiscModeOnly(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Flick Standards Track [Page 23] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + "This object describes whether the port hardware + is capable of supporting promiscuous mode, single + address mode (i.e., repeater filters unicasts not + addressed to the end station attached to this + port), or both. A port for which vgRptrPortType + is equal to 'cascadeInternal' or 'cascadeExternal' + will always have a value of 'promiscModeOnly' for + this object." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aSupportedPromiscMode." + ::= { vgRptrBasicPortEntry 5 } + + vgRptrPortSupportedCascadeMode OBJECT-TYPE + SYNTAX INTEGER { + endNodesOnly(1), + endNodesOrRepeaters(2), + cascadePort(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object describes whether the port hardware + is capable of supporting cascaded repeaters, end + nodes, or both. A port for which vgRptrPortType + is equal to 'cascadeInternal' or + 'cascadeExternal' will always have a value of + 'cascadePort' for this object." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aSupportedCascadeMode." + ::= { vgRptrBasicPortEntry 6 } + + vgRptrPortAllowedTrainType OBJECT-TYPE + SYNTAX INTEGER { + allowEndNodesOnly(1), + allowPromiscuousEndNodes(2), + allowEndNodesOrRepeaters(3), + allowAnything(4) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This security object is set by the network + manager to configure what type of device is + permitted to connect to the port. One of the + following values: + + + + +Flick Standards Track [Page 24] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + allowEndNodesOnly - only non- + promiscuous end + nodes permitted. + allowPromiscuousEndNodes - promiscuous or + non-promiscuous + end nodes + permitted + allowEndNodesOrRepeaters - repeaters or non- + promiscuous end + nodes permitted + allowAnything - repeaters, + promiscuous or + non-promiscuous + end nodes + permitted + + For a port for which vgRptrPortType is equal to + 'cascadeInternal' or 'cascadeExternal', the + corresponding instance of this object may not be + set to 'allowEndNodesOnly' or + 'allowPromiscuousEndNodes'. + + The agent must reject a SET of this object if the + value includes no capabilities that are + supported by this port's hardware, as defined by + the values of the corresponding instances of + vgRptrPortSupportedPromiscMode and + vgRptrPortSupportedCascadeMode. + + Note that vgRptrPortSupportPromiscMode and + vgRptrPortSupportedCascadeMode represent what the + port hardware is capable of supporting. + vgRptrPortAllowedTrainType is used for setting an + administrative policy for a port. The actual set + of training configurations that will be allowed + to succeed on a port is the intersection of what + the hardware will support and what is + administratively allowed. The above requirement + on what values may be set to this object says that + the intersection of what is supported and what is + allowed must be non-empty. In other words, it + must not result in a situation in which nothing + would be allowed to train on that port. However, + a value can be set to this object as long as the + combination of this object and what is supported + by the hardware would still leave at least one + configuration that could successfully train on the + port. + + + +Flick Standards Track [Page 25] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + The value of this object should be preserved + across repeater resets and power failures." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aAllowableTrainingType." + ::= { vgRptrBasicPortEntry 7 } + + vgRptrPortLastTrainConfig OBJECT-TYPE + SYNTAX OCTET STRING (SIZE(2)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a 16 bit field. For local ports, + this object contains the requested configuration + field from the most recent error-free training + request frame sent by the device connected to + the port. For cascade ports, this object contains + the responder's allowed configuration field from + the most recent error-free training response frame + received in response to training initiated by this + repeater. The format of the current version of + this field is described in section 3.2. Please + refer to the most recent version of the IEEE + 802.12 standard for the most up-to-date definition + of the format of this object." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aLastTrainingConfig." + ::= { vgRptrBasicPortEntry 8 } + + vgRptrPortTrainingResult OBJECT-TYPE + SYNTAX OCTET STRING (SIZE(3)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This 18 bit field is used to indicate the result + of training. It contains two bits which indicate + if error-free training frames have been received, + and it also contains the 16 bits of the allowed + configuration field from the most recent + error-free training response frame on the port. + + First Octet: Second and Third Octets: + 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+-----------------------------+ + |0|0|0|0|0|0|V|G| allowed configuration field | + +-+-+-+-+-+-+-+-+-----------------------------+ + + + + +Flick Standards Track [Page 26] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + V: Valid: set when at least one error-free + training frame has been received. + Indicates the 16 training configuration + bits in vgRptrPortLastTrainConfig and + vgRptrPortTrainingResult contain valid + information. This bit is cleared when + vgRptrPortStatus transitions to the + 'inactive' or 'training' state. + G: LinkGood: indicates the link hardware is + OK. Set if 24 consecutive error-free + training packets have been exchanged. + Cleared when a training packet with + errors is received, or when + vgRptrPortStatus transitions to the + 'inactive' or 'training' state. + + The format of the current version of the allowed + configuration field is described in section 3.2. + Please refer to the most recent version of the + IEEE 802.12 standard for the most up-to-date + definition of the format of this field. + + If the port is in training, a management station + can examine this object to see if any training + packets have been passed successfully. If there + have been any good training packets, the Valid + bit will be set and the management station can + examine the allowed configuration field to see if + there is a duplicate address, configuration, or + security problem. + + Note that on a repeater local port, this repeater + generates the training response bits, while on + a cascade port, the device at the upper end of + the link originated the training response bits." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aTrainingResult." + ::= { vgRptrBasicPortEntry 9 } + vgRptrPortPriorityEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A configuration flag used to determine whether + the repeater will service high priority requests + received on the port as high priority or normal + priority. When 'false', high priority requests + + + +Flick Standards Track [Page 27] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + on this port will be serviced as normal priority. + + The setting of this object has no effect on a + cascade port. Also note that the setting of this + object has no effect on a port connected to a + cascaded repeater. In both of these cases, this + setting is treated as always 'true'. The value + 'false' only has an effect when the port is a + localInternal or localExternal port connected to + an end node. + + The value of this object should be preserved + across repeater resets and power failures." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aPriorityEnable." + ::= { vgRptrBasicPortEntry 10 } + + vgRptrPortRptrInfoIndex OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object identifies the repeater that this + port is currently mapped to. The repeater + identified by a particular value of this object + is the same as that identified by the same value + of vgRptrInfoIndex. A value of zero indicates + that this port is not currently mapped to any + repeater." + ::= { vgRptrBasicPortEntry 11 } + + + vgRptrMonitor OBJECT IDENTIFIER ::= { vgRptrObjects 2 } + + vgRptrMonRepeater OBJECT IDENTIFIER ::= { vgRptrMonitor 1 } + + vgRptrMonitorTable OBJECT-TYPE + SYNTAX SEQUENCE OF VgRptrMonitorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table of performance and error statistics for + each repeater in the system. The instance of the + vgRptrInfoLastChange associated with a repeater + is used to indicate possible discontinuities of + the counters in this table that are associated + with the same repeater." + + + +Flick Standards Track [Page 28] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + ::= { vgRptrMonRepeater 1 } + + vgRptrMonitorEntry OBJECT-TYPE + SYNTAX VgRptrMonitorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the table, containing statistics + for a single repeater." + INDEX { vgRptrInfoIndex } + ::= { vgRptrMonitorTable 1 } + + VgRptrMonitorEntry ::= + SEQUENCE { + vgRptrMonTotalReadableFrames Counter32, + vgRptrMonTotalReadableOctets Counter32, + vgRptrMonReadableOctetRollovers Counter32, + vgRptrMonHCTotalReadableOctets Counter64, + vgRptrMonTotalErrors Counter32 + } + + vgRptrMonTotalReadableFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of good frames of valid frame + length that have been received on all ports in + this repeater. If an implementation cannot + obtain a count of frames as seen by the repeater + itself, this counter may be implemented as the + summation of the values of the + vgRptrPortReadableFrames counters for all of the + ports in this repeater. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrInfoLastChange changes." + ::= { vgRptrMonitorEntry 1 } + + vgRptrMonTotalReadableOctets OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of octets contained in good + frames that have been received on all ports in + this repeater. If an implementation cannot + + + +Flick Standards Track [Page 29] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + obtain a count of octets as seen by the repeater + itself, this counter may be implemented as the + summation of the values of the + vgRptrPortReadableOctets counters for all of the + ports in this repeater. + + Note that this counter can roll over very + quickly. A management station is advised to + also poll the vgRptrReadableOctetRollovers + object, or to use the 64-bit counter defined by + vgRptrMonHCTotalReadableOctets instead of the + two 32-bit counters. + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrInfoLastChange changes." + ::= { vgRptrMonitorEntry 2 } + + vgRptrMonReadableOctetRollovers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of times that the associated + instance of the vgRptrMonTotalReadableOctets + counter has rolled over. + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrInfoLastChange changes." + ::= { vgRptrMonitorEntry 3 } + + vgRptrMonHCTotalReadableOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + + + +Flick Standards Track [Page 30] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + DESCRIPTION + "The total number of octets contained in good + frames that have been received on all ports in + this repeater. If an implementation cannot + obtain a count of octets as seen by the repeater + itself, this counter may be implemented as the + summation of the values of the + vgRptrPortHCReadableOctets counters for all of the + ports in this repeater. + + This counter is a 64 bit version of + vgRptrMonTotalReadableOctets. It should be used + by Network Management protocols which support 64 + bit counters (e.g. SNMPv2). + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrInfoLastChange changes." + ::= { vgRptrMonitorEntry 4 } + + vgRptrMonTotalErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of errors which have occurred on + all of the ports in this repeater. If an + implementation cannot obtain a count of these + errors as seen by the repeater itself, this + counter may be implemented as the summation of the + values of the vgRptrPortIPMFrames, + vgRptrPortOversizeFrames, and + vgRptrPortDataErrorFrames counters for all of the + ports in this repeater. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrInfoLastChange changes." + ::= { vgRptrMonitorEntry 5 } + + vgRptrMonGroup OBJECT IDENTIFIER ::= { vgRptrMonitor 2 } + -- Currently unused + + vgRptrMonPort OBJECT IDENTIFIER ::= { vgRptrMonitor 3 } + + vgRptrMonPortTable OBJECT-TYPE + SYNTAX SEQUENCE OF VgRptrMonPortEntry + MAX-ACCESS not-accessible + + + +Flick Standards Track [Page 31] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + STATUS current + DESCRIPTION + "A table of performance and error statistics for + the ports. The columnar object + vgRptrPortLastChange is used to indicate possible + discontinuities of counter type columnar objects + in this table." + ::= { vgRptrMonPort 1 } + + vgRptrMonPortEntry OBJECT-TYPE + SYNTAX VgRptrMonPortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the vgRptrMonPortTable, containing + performance and error statistics for a single + port." + INDEX { vgRptrGroupIndex, vgRptrPortIndex } + ::= { vgRptrMonPortTable 1 } + + VgRptrMonPortEntry ::= + SEQUENCE { + vgRptrPortReadableFrames Counter32, + vgRptrPortReadableOctets Counter32, + vgRptrPortReadOctetRollovers Counter32, + vgRptrPortHCReadableOctets Counter64, + vgRptrPortUnreadableOctets Counter32, + vgRptrPortUnreadOctetRollovers Counter32, + vgRptrPortHCUnreadableOctets Counter64, + vgRptrPortHighPriorityFrames Counter32, + vgRptrPortHighPriorityOctets Counter32, + vgRptrPortHighPriOctetRollovers Counter32, + vgRptrPortHCHighPriorityOctets Counter64, + vgRptrPortNormPriorityFrames Counter32, + vgRptrPortNormPriorityOctets Counter32, + vgRptrPortNormPriOctetRollovers Counter32, + vgRptrPortHCNormPriorityOctets Counter64, + vgRptrPortBroadcastFrames Counter32, + vgRptrPortMulticastFrames Counter32, + vgRptrPortNullAddressedFrames Counter32, + vgRptrPortIPMFrames Counter32, + vgRptrPortOversizeFrames Counter32, + vgRptrPortDataErrorFrames Counter32, + vgRptrPortPriorityPromotions Counter32, + vgRptrPortTransitionToTrainings Counter32, + vgRptrPortLastChange TimeStamp + } + + + + +Flick Standards Track [Page 32] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + vgRptrPortReadableFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the number of good frames of + valid frame length that have been received on + this port. This counter is incremented by one + for each frame received on the port which is not + counted by any of the following error counters: + vgRptrPortIPMFrames, vgRptrPortOversizeFrames, + vgRptrPortNullAddressedFrames, or + vgRptrPortDataErrorFrames. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aReadableFramesReceived." + ::= { vgRptrMonPortEntry 1 } + + vgRptrPortReadableOctets OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of octets + contained in good 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. each frame counted by + vgRptrPortReadableFrames). + + Note that this counter can roll over very + quickly. A management station is advised to + also poll the vgRptrPortReadOctetRollovers + object, or to use the 64-bit counter defined by + vgRptrPortHCReadableOctets instead of the two + 32-bit counters. + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + + + +Flick Standards Track [Page 33] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aReadableOctetsReceived." + ::= { vgRptrMonPortEntry 2 } + + vgRptrPortReadOctetRollovers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of times + that the associated instance of the + vgRptrPortReadableOctets counter has rolled over. + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aReadableOctetsReceived." + ::= { vgRptrMonPortEntry 3 } + + vgRptrPortHCReadableOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of octets + contained in good 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. each frame counted by + vgRptrPortReadableFrames). + + This counter is a 64 bit version of + vgRptrPortReadableOctets. It should be used by + Network Management protocols which support 64 bit + counters (e.g. SNMPv2). + + + +Flick Standards Track [Page 34] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aReadableOctetsReceived." + ::= { vgRptrMonPortEntry 4 } + + vgRptrPortUnreadableOctets OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of octets + contained in invalid frames that have been + received on this port. This counter is + incremented by OctetCount for each frame received + on this port which is counted by + vgRptrPortIPMFrames, vgRptrPortOversizeFrames, + vgRptrPortNullAddressedFrames, or + vgRptrPortDataErrorFrames. This counter can be + combined with vgRptrPortReadableOctets to + calculate network utilization. + + Note that this counter can roll over very + quickly. A management station is advised to + also poll the vgRptrPortUnreadOctetRollovers + object, or to use the 64-bit counter defined by + vgRptrPortHCUnreadableOctets instead of the two + 32-bit counters. + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aOctetsInUnreadableFramesRcvd." + ::= { vgRptrMonPortEntry 5 } + + vgRptrPortUnreadOctetRollovers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + + + +Flick Standards Track [Page 35] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + STATUS current + DESCRIPTION + "This object is a count of the number of times + that the associated instance of the + vgRptrPortUnreadableOctets counter has rolled + over. + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aOctetsInUnreadableFramesRcvd." + ::= { vgRptrMonPortEntry 6 } + + vgRptrPortHCUnreadableOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of octets + contained in invalid frames that have been + received on this port. This counter is + incremented by OctetCount for each frame received + on this port which is counted by + vgRptrPortIPMFrames, vgRptrPortOversizeFrames, + vgRptrPortNullAddressedFrames, or + vgRptrPortDataErrorFrames. This counter can be + combined with vgRptrPortHCReadableOctets to + calculate network utilization. + + This counter is a 64 bit version of + vgRptrPortUnreadableOctets. It should be used + by Network Management protocols which support 64 + bit counters (e.g. SNMPv2). + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aOctetsInUnreadableFramesRcvd." + + + +Flick Standards Track [Page 36] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + ::= { vgRptrMonPortEntry 7 } + + vgRptrPortHighPriorityFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of high priority frames + that have been received on this port. This + counter is incremented by one for each high + priority frame received on this port. This + counter includes both good and bad high priority + frames, as well as high priority training frames. + This counter does not include normal priority + frames which were priority promoted. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aHighPriorityFramesReceived." + ::= { vgRptrMonPortEntry 8 } + + vgRptrPortHighPriorityOctets OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of octets + contained in high priority frames that have been + received on this port. This counter is + incremented by OctetCount for each frame received + on this port which is counted by + vgRptrPortHighPriorityFrames. + + Note that this counter can roll over very + quickly. A management station is advised to + also poll the vgRptrPortHighPriOctetRollovers + object, or to use the 64-bit counter defined by + vgRptrPortHCHighPriorityOctets instead of the two + 32-bit counters. + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + + +Flick Standards Track [Page 37] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aHighPriorityOctetsReceived." + ::= { vgRptrMonPortEntry 9 } + + vgRptrPortHighPriOctetRollovers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of times + that the associated instance of the + vgRptrPortHighPriorityOctets counter has rolled + over. + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aHighPriorityOctetsReceived." + ::= { vgRptrMonPortEntry 10 } + + vgRptrPortHCHighPriorityOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of octets + contained in high priority frames that have been + received on this port. This counter is + incremented by OctetCount for each frame received + on this port which is counted by + vgRptrPortHighPriorityFrames. + + This counter is a 64 bit version of + vgRptrPortHighPriorityOctets. It should be used + by Network Management protocols which support + 64 bit counters (e.g. SNMPv2). + + + +Flick Standards Track [Page 38] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aHighPriorityOctetsReceived." + ::= { vgRptrMonPortEntry 11 } + + vgRptrPortNormPriorityFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of normal priority frames + that have been received on this port. This + counter is incremented by one for each normal + priority frame received on this port. This + counter includes both good and bad normal + priority frames, as well as normal priority + training frames and normal priority frames which + were priority promoted. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aNormalPriorityFramesReceived." + ::= { vgRptrMonPortEntry 12 } + + vgRptrPortNormPriorityOctets OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of octets + contained in normal priority frames that have + been received on this port. This counter is + incremented by OctetCount for each frame received + on this port which is counted by + vgRptrPortNormPriorityFrames. + + Note that this counter can roll over very + quickly. A management station is advised to + also poll the vgRptrPortNormPriOctetRollovers + object, or to use the 64-bit counter defined by + vgRptrPortHCNormPriorityOctets instead of the two + 32-bit counters. + + + +Flick Standards Track [Page 39] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aNormalPriorityOctetsReceived." + ::= { vgRptrMonPortEntry 13 } + + vgRptrPortNormPriOctetRollovers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of times + that the associated instance of the + vgRptrPortNormPriorityOctets counter has rolled + over. + + This two-counter mechanism is provided for those + network management protocols that do not support + 64-bit counters (e.g. SNMPv1). Note that + retrieval of these two counters in the same PDU + is NOT guaranteed to be atomic. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aNormalPriorityOctetsReceived." + + ::= { vgRptrMonPortEntry 14 } + + vgRptrPortHCNormPriorityOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of octets + contained in normal priority frames that have + been received on this port. This counter is + incremented by OctetCount for each frame received + + + +Flick Standards Track [Page 40] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + on this port which is counted by + vgRptrPortNormPriorityFrames. + + This counter is a 64 bit version of + vgRptrPortNormPriorityOctets. It should be used + by Network Management protocols which support + 64 bit counters (e.g. SNMPv2). + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aNormalPriorityOctetsReceived." + ::= { vgRptrMonPortEntry 15 } + + vgRptrPortBroadcastFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of broadcast packets that + have been received on this port. This counter is + incremented by one for each readable frame + received on this port whose destination MAC + address is the broadcast address. Frames + counted by this counter are also counted by + vgRptrPortReadableFrames. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aBroadcastFramesReceived." + ::= { vgRptrMonPortEntry 16 } + + vgRptrPortMulticastFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of multicast packets that + have been received on this port. This counter is + incremented by one for each readable frame + received on this port whose destination MAC + address has the group address bit set, but is not + the broadcast address. Frames counted by this + + + +Flick Standards Track [Page 41] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + counter are also counted by + vgRptrPortReadableFrames, but not by + vgRptrPortBroadcastFrames. Note that when the + value of the instance vgRptrInfoCurrentFramingType + for the repeater that this port is associated + with is equal to 'frameType88025', this count + includes packets addressed to functional + addresses. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aMulticastFramesReceived." + ::= { vgRptrMonPortEntry 17 } + + vgRptrPortNullAddressedFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of null addressed packets + that have been received on this port. This + counter is incremented by one for each frame + received on this port with a destination MAC + address consisting of all zero bits. Both void + and training frames are included in this + counter. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aNullAddressedFramesReceived." + ::= { vgRptrMonPortEntry 18 } + + vgRptrPortIPMFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of the number of frames + that have been received on this port with an + invalid packet marker and no PMI errors. A + repeater will write an invalid packet marker to + the end of a frame containing errors as it is + + + +Flick Standards Track [Page 42] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + forwarded through the repeater to the other + ports. This counter is incremented by one for + each frame received on this port which has had an + invalid packet marker added to the end of the + frame. + + This counter indicates problems occurring in the + domain of other repeaters, as opposed to problems + with cables or devices directly attached to this + repeater. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aIPMFramesReceived." + ::= { vgRptrMonPortEntry 19 } + + vgRptrPortOversizeFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of oversize frames + received on this port. This counter is + incremented by one for each frame received on + this port whose OctetCount is larger than the + maximum legal frame size. + + The frame size which causes this counter to + increment is dependent on the current value of + vgRptrInfoCurrentFramingType for the repeater that + the port is associated with. When + vgRptrInfoCurrentFramingType is equal to + frameType88023 this counter will increment for + frames that are 1519 octets or larger. When + vgRptrInfoCurrentFramingType is equal to + frameType88025 this counter will increment for + frames that are 4521 octets or larger. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aOversizeFramesReceived." + ::= { vgRptrMonPortEntry 20 } + + + +Flick Standards Track [Page 43] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + vgRptrPortDataErrorFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a count of errored frames + received on this port. This counter is + incremented by one for each frame received on + this port with any of the following errors: bad + FCS (with no IPM), PMI errors (excluding frames + with an IPM error as the only PMI error), or + undersize (with no IPM). Does not include + packets counted by vgRptrPortIPMFrames, + vgRptrPortOversizeFrames, or + vgRptrPortNullAddressedFrames. + + This counter indicates problems with cables or + devices directly connected to this repeater, while + vgRptrPortIPMFrames indicates problems occurring + in the domain of other repeaters. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aDataErrorFramesReceived." + ::= { vgRptrMonPortEntry 21 } + + vgRptrPortPriorityPromotions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This counter is incremented by one each time the + priority promotion timer has expired on this port + and a normal priority frame is priority + promoted. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aPriorityPromotions." + ::= { vgRptrMonPortEntry 22 } + + vgRptrPortTransitionToTrainings OBJECT-TYPE + + + +Flick Standards Track [Page 44] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This counter is incremented by one each time the + vgRptrPortStatus object for this port transitions + into the 'training' state. + + This counter may experience a discontinuity when + the value of the corresponding instance of + vgRptrPortLastChange changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aTransitionsIntoTraining." + ::= { vgRptrMonPortEntry 23 } + + vgRptrPortLastChange OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime when the last of the + following occurred: + 1) the agent cold- or warm-started; + 2) the row for the port was created + (such as when a device or module was + added to the system); or + 3) any condition that would cause one of + the counters for the row to experience + a discontinuity." + ::= { vgRptrMonPortEntry 24 } + + + vgRptrAddrTrack OBJECT IDENTIFIER ::= { vgRptrObjects 3 } + + vgRptrAddrTrackRptr + OBJECT IDENTIFIER ::= { vgRptrAddrTrack 1 } + + -- Currently unused + + vgRptrAddrTrackGroup + OBJECT IDENTIFIER ::= { vgRptrAddrTrack 2 } + -- Currently unused + + vgRptrAddrTrackPort + OBJECT IDENTIFIER ::= { vgRptrAddrTrack 3 } + + vgRptrAddrTrackTable OBJECT-TYPE + + + +Flick Standards Track [Page 45] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + SYNTAX SEQUENCE OF VgRptrAddrTrackEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of address mapping information about the + ports." + ::= { vgRptrAddrTrackPort 1 } + + vgRptrAddrTrackEntry OBJECT-TYPE + SYNTAX VgRptrAddrTrackEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the table, containing address mapping + information about a single port." + INDEX { vgRptrGroupIndex, vgRptrPortIndex } + ::= { vgRptrAddrTrackTable 1 } + + VgRptrAddrTrackEntry ::= + SEQUENCE { + vgRptrAddrLastTrainedAddress OCTET STRING, + vgRptrAddrTrainedAddrChanges Counter32, + vgRptrRptrDetectedDupAddress TruthValue, + vgRptrMgrDetectedDupAddress TruthValue + } + + + vgRptrAddrLastTrainedAddress OBJECT-TYPE + SYNTAX OCTET STRING (SIZE(0 | 6)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the MAC address of the last + station which succeeded in training on this port. + A cascaded repeater may train using the null + address. If no stations have succeeded in + training on this port since the agent began + monitoring the port activity, the agent shall + return a string of length zero." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aLastTrainedAddress." + ::= { vgRptrAddrTrackEntry 1 } + + vgRptrAddrTrainedAddrChanges OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + +Flick Standards Track [Page 46] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + DESCRIPTION + "This counter is incremented by one for each time + that the vgRptrAddrLastTrainedAddress object for + this port changes." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aTrainedAddressChanges." + ::= { vgRptrAddrTrackEntry 2 } + + vgRptrRptrDetectedDupAddress OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is used to indicate that the + repeater detected an error-free training frame on + this port with a non-null source MAC address which + matches the value of vgRptrAddrLastTrainedAddress + of another active port in the same repeater. This + is reset to 'false' when an error-free training + frame is received with a non-null source MAC + address which does not match + vgRptrAddrLastTrainedAddress of another port which + is active in the same repeater. + + For the cascade port, this object will be 'true' + if the 'D' bit in the most recently received + error-free training response frame was set, + indicating the device at the other end of the link + believes that this repeater's cascade port is + using a duplicate address. This may be because + the device at the other end of the link detected a + duplicate address itself, or, if the other device + is also a repeater, it could be because + vgRptrMgrDetectedDupAddress was set to 'true' on + the port that this repeater's cascade port is + connected to." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aLocalRptrDetectedDupAddr." + ::= { vgRptrAddrTrackEntry 3 } + + vgRptrMgrDetectedDupAddress OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object can be set by a management station + + + +Flick Standards Track [Page 47] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + when it detects that there is a duplicate MAC + address. This object is OR'd with + vgRptrRptrDetectedDupAddress to form the value of + the 'D' bit in training response frames on this + port. + + The purpose of this object is to provide a means + for network management software to inform an end + station that it is using a duplicate station + address. Setting this object does not affect the + current state of the link; the end station will + not be informed of the duplicate address until it + retrains for some reason. Note that regardless + of its station address, the end station will not + be able to train successfully until the network + management software has set this object back to + 'false'. Although this object exists on + cascade ports, it does not perform any function + since this repeater is the initiator of training + on a cascade port." + REFERENCE + "IEEE Standard 802.12-1995, 13.2.4.5.1, + aCentralMgmtDetectedDupAddr." + ::= { vgRptrAddrTrackEntry 4 } + + + vgRptrTraps OBJECT IDENTIFIER ::= { vgRptrMIB 2 } + vgRptrTrapPrefix OBJECT IDENTIFIER ::= { vgRptrTraps 0 } + + vgRptrHealth NOTIFICATION-TYPE + OBJECTS { vgRptrInfoOperStatus } + STATUS current + DESCRIPTION + "A vgRptrHealth trap conveys information related + to the operational state of a repeater. This trap + is sent when the value of an instance of + vgRptrInfoOperStatus changes. The vgRptrHealth + trap is not sent as a result of powering up a + repeater. + + The vgRptrHealth trap must contain the instance of + the vgRptrInfoOperStatus object associated with + the affected repeater. + + The agent must throttle the generation of + consecutive vgRptrHealth traps so that there is at + least a five-second gap between traps of this + type. When traps are throttled, they are dropped, + + + +Flick Standards Track [Page 48] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + not queued for sending at a future time. (Note + that 'generating' a trap means sending to all + configured recipients.)" + REFERENCE + "IEEE 802.12, Layer Management, 13.2.4.2.3, + nRepeaterHealth." + ::= { vgRptrTrapPrefix 1 } + + vgRptrResetEvent NOTIFICATION-TYPE + OBJECTS { vgRptrInfoOperStatus } + STATUS current + DESCRIPTION + "A vgRptrResetEvent trap conveys information + related to the operational state of a repeater. + This trap is sent on completion of a repeater + reset action. A repeater reset action is defined + as a transition to its initial state as specified + in clause 12 [IEEE Std 802.12] when triggered by + a management command. + + The vgRptrResetEvent trap is not sent when the + agent restarts and sends an SNMP coldStart or + warmStart trap. + + The vgRptrResetEvent trap must contain the + instance of the vgRptrInfoOperStatus object + associated with the affected repeater. + + The agent must throttle the generation of + consecutive vgRptrResetEvent traps so that there + is at least a five-second gap between traps of + this type. When traps are throttled, they are + dropped, not queued for sending at a future time. + (Note that 'generating' a trap means sending to + all configured recipients.)" + REFERENCE + "IEEE 802.12, Layer Management, 13.2.4.2.3, + nRepeaterReset." + ::= { vgRptrTrapPrefix 2 } + + -- conformance information + + vgRptrConformance OBJECT IDENTIFIER ::= { vgRptrMIB 3 } + + vgRptrCompliances + OBJECT IDENTIFIER ::= { vgRptrConformance 1 } + + vgRptrGroups OBJECT IDENTIFIER ::= { vgRptrConformance 2 } + + + +Flick Standards Track [Page 49] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + -- compliance statements + + vgRptrCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for managed 802.12 + repeaters." + + MODULE -- this module + MANDATORY-GROUPS { vgRptrConfigGroup, + vgRptrStatsGroup, + vgRptrAddrGroup, + vgRptrNotificationsGroup } + + GROUP vgRptrStats64Group + DESCRIPTION + "Implementation of this group is recommended + for systems which can support Counter64." + + OBJECT vgRptrInfoDesiredFramingType + MIN-ACCESS read-only + DESCRIPTION + "Write access to this object is not required + in a repeater system that does not support + configuration of framing types." + + MODULE SNMP-REPEATER-MIB + GROUP snmpRptrGrpRptrAddrSearch + DESCRIPTION + "Implementation of this group is recommended + for systems which have the necessary + instrumentation to search all incoming data + streams for a particular source MAC address." + ::= { vgRptrCompliances 1 } + + -- units of conformance + + vgRptrConfigGroup OBJECT-GROUP + OBJECTS { + vgRptrInfoMACAddress, + vgRptrInfoCurrentFramingType, + vgRptrInfoDesiredFramingType, + vgRptrInfoFramingCapability, + vgRptrInfoTrainingVersion, + vgRptrInfoOperStatus, + vgRptrInfoReset, + vgRptrInfoLastChange, + vgRptrGroupObjectID, + + + +Flick Standards Track [Page 50] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + vgRptrGroupOperStatus, + vgRptrGroupPortCapacity, + vgRptrGroupCablesBundled, + vgRptrPortType, + vgRptrPortAdminStatus, + vgRptrPortOperStatus, + vgRptrPortSupportedPromiscMode, + vgRptrPortSupportedCascadeMode, + vgRptrPortAllowedTrainType, + vgRptrPortLastTrainConfig, + vgRptrPortTrainingResult, + vgRptrPortPriorityEnable, + vgRptrPortRptrInfoIndex + } + STATUS current + DESCRIPTION + "A collection of objects for managing the status + and configuration of IEEE 802.12 repeaters." + ::= { vgRptrGroups 1 } + + vgRptrStatsGroup OBJECT-GROUP + OBJECTS { + vgRptrMonTotalReadableFrames, + vgRptrMonTotalReadableOctets, + vgRptrMonReadableOctetRollovers, + vgRptrMonTotalErrors, + vgRptrPortReadableFrames, + vgRptrPortReadableOctets, + vgRptrPortReadOctetRollovers, + vgRptrPortUnreadableOctets, + vgRptrPortUnreadOctetRollovers, + vgRptrPortHighPriorityFrames, + vgRptrPortHighPriorityOctets, + vgRptrPortHighPriOctetRollovers, + vgRptrPortNormPriorityFrames, + vgRptrPortNormPriorityOctets, + vgRptrPortNormPriOctetRollovers, + vgRptrPortBroadcastFrames, + vgRptrPortMulticastFrames, + vgRptrPortNullAddressedFrames, + vgRptrPortIPMFrames, + vgRptrPortOversizeFrames, + vgRptrPortDataErrorFrames, + vgRptrPortPriorityPromotions, + vgRptrPortTransitionToTrainings, + vgRptrPortLastChange + } + STATUS current + + + +Flick Standards Track [Page 51] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + DESCRIPTION + "A collection of objects for providing statistics + for IEEE 802.12 repeaters. Systems which support + Counter64 should also implement + vgRptrStats64Group." + ::= { vgRptrGroups 2 } + + vgRptrStats64Group OBJECT-GROUP + OBJECTS { + vgRptrMonHCTotalReadableOctets, + vgRptrPortHCReadableOctets, + vgRptrPortHCUnreadableOctets, + vgRptrPortHCHighPriorityOctets, + vgRptrPortHCNormPriorityOctets + } + STATUS current + DESCRIPTION + "A collection of objects for providing statistics + for IEEE 802.12 repeaters in a system that + supports Counter64." + ::= { vgRptrGroups 3 } + + vgRptrAddrGroup OBJECT-GROUP + OBJECTS { + vgRptrAddrLastTrainedAddress, + vgRptrAddrTrainedAddrChanges, + vgRptrRptrDetectedDupAddress, + vgRptrMgrDetectedDupAddress + } + STATUS current + DESCRIPTION + "A collection of objects for tracking addresses + on IEEE 802.12 repeaters." + ::= { vgRptrGroups 4 } + + vgRptrNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { + vgRptrHealth, + vgRptrResetEvent + } + STATUS current + DESCRIPTION + "A collection of notifications used to indicate + 802.12 repeater general status changes." + ::= { vgRptrGroups 5 } + + END + + + + +Flick Standards Track [Page 52] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + +4. Acknowledgements + + This document was produced by the IETF 100VG-AnyLAN Working Group, + whose efforts were greatly advanced by the contributions of the + following people: + + Paul Chefurka + Bob Faulk + Jeff Johnson + Karen Kimball + David Lapp + Jason Spofford + Kaj Tesink + + This document is based on the work of IEEE 802.12. + +5. References + + [1] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization. International + Standard 8824 (December, 1987). + + [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and + S. Waldbusser, "Structure of Management Information for Version 2 + of the Simple Network Management Protocol (SNMPv2)", RFC 1902, + January 1996. + + [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and + S. Waldbusser, "Textual Conventions for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + + [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and + S. Waldbusser, "Conformance Statements for Version 2 of the + Simple Network Management Protocol (SNMPv2)", RFC 1904, January + 1996. + + [5] McCloghrie, K. and M. Rose, "Management Information Base for + Network Management of TCP/IP-based internets - MIB-II", STD 17, + RFC 1213, March 1991. + + [6] IEEE, "Demand Priority Access Method, Physical Layer and + Repeater Specifications for 100 Mb/s Operation", IEEE Standard + 802.12-1995" + + + + + + + +Flick Standards Track [Page 53] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + + [7] de Graaf, K., D. Romascanu, D. McMaster, and K. McCloghrie, + "Definitions of Managed Objects for IEEE 802.3 Repeater Devices", + RFC 2108, 3Com Corporation, Madge Networks (Israel) Ltd., Cisco + Systems, Inc., February, 1997. + + [8] McAnally, G., Gilbert, D. and J. Flick, "Conditional Grant of + Rights to Specific Hewlett-Packard Patents In Conjunction With + the Internet Engineering Task Force's Internet-Standard Network + Management Framework", RFC 1988, August 1996. + + [9] Hewlett-Packard Company, US Patents 5,293,635 and 5,421,024. + +6. Security Considerations + + Certain management information defined in this MIB may be considered + sensitive in some network environments. Therefore, authentication of + received SNMP requests and controlled access to management + information should be employed in such environments. The method for + this authentication is a function of the SNMP Administrative + Framework, and has not been expanded by this MIB. + + Several objects in the vgRptrConfigGroup allow write access. Setting + these objects can have a serious effect on the operation of the + network, including modifying the framing type of the network, + resetting the repeater, enabling and disabling individual ports, and + modifying the allowed capabilities of end stations attached to each + port. It is recommended that implementers seriously consider whether + set operations should be allowed without providing, at a minimum, + authentication of request origin. + + One particular object in this MIB, vgRptrPortAllowedTrainType, is + considered significant for providing operational security in an + 802.12 network. It is recommended that network administrators + configure this object to the 'allowEndNodesOnly' value on all ports + except ports which the administrator knows are attached to cascaded + repeaters or devices which require promiscuous receive capability + (bridges, switches, RMON probes, etc.). This will prevent + unauthorized users from extending the network (by attaching cascaded + repeaters or bridges) without the administrator's knowledge, and will + prevent unauthorized end nodes from listening promiscuously to + network traffic. + + + + + + + + + + +Flick Standards Track [Page 54] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + +7. Author's Address + + John Flick + Hewlett Packard Company + 8000 Foothills Blvd. M/S 5556 + Roseville, CA 95747-5556 + + Phone: +1 916 785 4018 + Email: johnf@hprnd.rose.hp.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Flick Standards Track [Page 55] + +RFC 2266 IEEE 802.12 Repeater MIB January 1998 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Flick Standards Track [Page 56] + |