home *** CD-ROM | disk | FTP | other *** search
Text File | 2003-06-11 | 130.9 KB | 3,140 lines |
-
-
-
-
-
-
- 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]
-
-