summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2266.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc2266.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc2266.txt')
-rw-r--r--doc/rfc/rfc2266.txt3139
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]
+