RFC 1368
Definition of Managed Objects for IEEE 802.3 Repeater Devices
RFC 1368: Definitions of Managed Objects for IEEE 802.3 Repeater Devices 🎀
okay bestie, the title block is giving old-school IETF ✨. D. McMaster (SynOptics Communications, Inc.) and K. McCloghrie (Hughes LAN Systems, Inc.) wrote this in October 1992 for the Network Working Group. It's an IAB standards track document, so it's a real standard, not just an opinion piece 💅. It doesn't list anything it obsoletes or updates.
Status of this Memo 📋
okay so this section says the RFC is an IAB standards track protocol for the Internet community, and it wants feedback and suggestions for making it better 🫶. For the current standardization state and status, check the "IAB Official Protocol Standards" document, because that's the source of truth 📚. And distribution is unlimited, so share it with everyone 💖.
Abstract 🌸
this memo defines a chunk of the Management Information Base (MIB) that network management protocols use in TCP/IP-based internets 🦋. Specifically, it's all about objects for managing IEEE 802.3 10 Mb/second baseband repeaters, which people sometimes call "hubs" 🔥.
Table of Contents 🗂️
1. Management Framework ........................................ 2
2. Objects ..................................................... 2
2.1 Format of Definitions ...................................... 3
3. Overview .................................................... 3
3.1 Terminology ................................................ 3
3.1.1 Repeaters, Hubs and Concentrators ........................ 3
3.1.2 Repeaters, Ports, and MAUs ............................... 4
3.1.3 Ports and Groups ......................................... 6
3.2 Supporting Functions ....................................... 7
3.3 Structure of MIB ........................................... 9
3.3.1 The Basic Group Definitions .............................. 10
3.3.2 The Monitor Group Definitions ............................ 10
3.3.3 The Address Tracking Group Definitions ................... 10
3.4 Relationship to Other MIBs ................................. 10
3.4.1 Relationship to the 'system' group ....................... 10
3.4.2 Relationship to the 'interfaces' group .................... 10
3.5 Textual Conventions ........................................ 11
4. Definitions ................................................. 11
4.1 MIB Groups in the Repeater MIB ............................. 12
4.2 The Basic Group Definitions ................................ 13
4.3 The Monitor Group Definitions .............................. 23
4.4 The Address Tracking Group Definitions ..................... 33
4.5 Traps for use by Repeaters ................................. 35
5. Acknowledgments ............................................. 37
6. References .................................................. 39
7. Security Considerations...................................... 40
8. Authors' Addresses........................................... 401. Management Framework ✨
so the Internet-standard Network Management Framework is made of three components 🧚:
- STD 16/RFC 1155 [1] defines the SMI, which is the set of mechanisms for describing and naming objects for management 📝. STD 16/RFC 1212 [7] defines a more concise description mechanism, and it's totally consistent with the SMI 💜.
- RFC 1156 [2] defines MIB-I, the core set of managed objects for the Internet suite of protocols 🌈. STD 17/RFC 1213 [4] defines MIB-II, which is basically MIB-I level-up based on real implementation experience and new operational needs 👑.
- STD 15/RFC 1157 [3] defines SNMP, the protocol used for network access to managed objects 🔥.
The Framework lets people define new objects for experimentation and evaluation 🧪.
2. Objects 🎀
managed objects live in a virtual information store called the Management Information Base, or MIB 🗄️. Objects in the MIB get defined using the subset of Abstract Syntax Notation One (ASN.1) [5] that the SMI allows 💅. Every object has a name, a syntax, and an encoding 🫶. The name is an object identifier, which is an administratively assigned name that specifies an object type 🏷️. The object type plus an object instance uniquely identifies one specific instance of the object ✨. For human convenience, people often use a text string called the OBJECT DESCRIPTOR to refer to the object type too 🙈.
The syntax of an object type defines the abstract data structure for that object type, and it's written in ASN.1 🧩. The SMI [1] deliberately restricts which ASN.1 constructs you can use, and the reason is simplicity 💖.
The encoding of an object type is basically how that object type gets represented using its syntax 🌸. The encoding and the syntax are implicitly tied to how the object type is represented when it's sent over the network 🦋. The SMI says to use the basic encoding rules of ASN.1 [6], plus the extra requirements that SNMP adds 🔥.
2.1. Format of Definitions 📖
Section 4 holds the specification for every object type in this MIB module 🎯. The object types use the conventions from the SMI, as extended by the extensions in [7,8] 💜.
3. Overview 🌈
instances of the object types in this memo represent attributes of an IEEE 802.3 (Ethernet-like) repeater 🔌. The definition of that repeater comes from Section 9, "Repeater Unit for 10 Mb/s Baseband Networks," in the IEEE 802.3/ISO 8802-3 CSMA/CD standard [9] 👑.
You can use these Repeater MIB objects to manage non-standard repeater-like devices 🙈. But defining objects that describe implementation-specific properties of those non-standard devices is outside this memo's scope 🚫.
The definitions here are based on the IEEE draft standard P802.3K, "Layer Management for 10 Mb/s Baseband Repeaters." [10] 🧠. People implementing these MIB objects should know that [10] explicitly describes when, where, and how the various repeater attributes get measured 📏. That IEEE document also describes what happens when repeater actions get triggered by manipulating instances of the MIB objects defined here ⚡.
The counters in this document are defined to be the same as the counters in the IEEE 802.3 Repeater Management draft 🔢. The goal is that one instrumentation can implement both the IEEE and IETF management standards at once 🤝.
3.1. Terminology 📚
3.1.1. Repeaters, Hubs and Concentrators 🐝
okay so in late 1988, the IEEE 802.3 Hub Management task force got chartered to define managed objects for both 802.3 repeaters and the proposed 10BASE-FA synchronous active stars 🌟. The word "hub" covered both repeaters and active stars 🫧.
In March 1991, the active star proposal got dropped from the 10BASE-F draft 💀. After that, the 802.3 group renamed the task force to the IEEE 802.3 Repeater Management Task Force, and they renamed their draft to match 🔁.
The word "hub" has caused some confusion 😭. People often use "hub," "intelligent hub," and "concentrator" to mean a modular chassis with plug-in modules that give generalized LAN/WAN connectivity 🏢. Those chassis often mix 802.3 repeater, token ring, and FDDI connectivity, and they get internetworked with bridges, routers, and terminal servers 🌐.
To make it crystal clear that this work only covers managing IEEE 802.3 repeaters, the editors of this MIB definitions document chose to call it a "Repeater MIB" instead of a "Hub MIB" 💅✨.
continued in part 2 🦋
3.1.2. Repeaters, Ports, and MAUs ✨
okay so this part is literally the vocab lesson 🎀 The text says upfront that it's a rough, imprecise version of the terms, so if you want the full precise definitions, go read Section 9 of [9]. 🧚
An IEEE 802.3 repeater connects "Ethernet-like" media segments together so the network can be longer and have more topology than a single coax segment could ever manage 🌸 Picture it as a star with two or more input/output ports. Here's the 6-port version:
^ ^
| |
\ \ / /
\ \ / /
_____\ v /_____
-> ______ ______ ->
/ ^ \
/ / \ \
/ / \ \
| |
v v
Figure 1. Repeater UnitEvery station on the media segments hooked up to a repeater's ports is in one single collision domain 💜 So a packet sent by any of those stations gets seen by all of them. Main character energy for the repeater, honestly 👑
Data that comes in on one port gets sent out every other port, so n-1 of them 🦋 If data shows up on two or more ports at the same time, or the repeater spots a collision on the incoming port, it blasts a jamming signal out on all ports for as long as the collision lasts. 😭
A repeater is a bit-wise store-and-forward device, which is what makes it different from a bridge (that one's frame store-and-forward) 🍓 A repeater cares about carrier sense and data bits. It doesn't make any decisions about whether a packet is legal or what's inside it. It just retransmits bits as they arrive. Its data FIFO only holds enough bits to stop it from underflowing when the incoming bits are a tiny bit slower than the repeater's own transmission rate. Lowkey so minimal and I'm obsessed 💅
A repeater isn't an end-station, so it doesn't count toward the overall limit of 1024 stations 🙈 It also has no MAC address, which means packets can't be addressed to the repeater or to its ports. (BUT packets can be addressed to the MAC address of a management entity monitoring a repeater. That entity might or might not be plugged into one of the repeater's ports. How it gets info about the repeater's activity is an implementation issue, and this memo doesn't cover it 🫶)
A repeater connects to the network through Medium Attachment Units (MAUs), and sometimes through Attachment Unit Interfaces (AUIs) too. ("MAUs" are also called transceivers, and an "AUI" is the same thing as a 15-pin Ethernet or DIX connector 🔌)
The 802.3 standard says a "repeater set" is the "repeater unit" plus its associated MAUs (and AUIs, if there are any) ✨ The "repeater unit" is the part of the repeater set that sits inboard of the physical media interfaces. The MAUs can be physically separate from the repeater unit, or they can be built into the same physical package. Choices, choices 🌈
(MAU) (MAU)
\ \ / /
\ \ / /
_____\ v /_____
(MAU) ______ ______ (MAU)
/ ^ \
/ / \ \
/ / \ \
(MAU) (MAU)
Figure 2. Repeater SetThe most commonly used MAUs are 10BASE-5 (AUI to thick "yellow" coax), 10BASE-2 (BNC to thin coax), 10BASE-T (unshielded twisted-pair), and FOIRL (asynchronous fiber optic inter-repeater link, which is getting merged into the 10BASE-F standard as 10BASE-FL) 🧚 The draft 10BASE-F standard also has a definition for a brand-new synchronous fiber optic attachment called 10BASE-FB. Ooh, new drop alert 🦋
Now, it's really important to say this: the repeater MIB the IEEE is defining only covers management of the repeater unit. It does NOT cover the MAUs that make up the repeater set 🙅♀️ The IEEE thinks MAU management should look the same whether the MAUs connect to end-stations (DTEs) or to repeaters, and this memo is following that same strategy. The management info for MAUs gets its own separate memo, so stay tuned 🔥
3.1.3. Ports and Groups ✨
Repeaters are often built into modular "concentrators," where a card cage holds a bunch of field-replaceable cards 🎀 Several cards can together form one repeater unit, and each card holds one or more of the repeater's ports. Because of that modular setup, people usually identify ports by a card number plus the port number relative to that card, like Card 3, Port 11 💅
To support that modular numbering, this document follows the IEEE Repeater Management draft [10] and lets an implementor split a repeater's ports into "groups" if they want to 🫶 For example, an implementor could represent field-replaceable units as groups of ports, so the port numbering matches the modular hardware.
Grouping is recommended, but it's optional 💖 An implementor can put all of a modular repeater's ports into one group, or split the ports into groups that don't line up with the physical divisions. Totally their call 🍓
The object rptrGroupCapacity has a maximum value of 1024 and tells you the maximum number of groups a given repeater can contain 🌸 Its value must stay constant from one management restart to the next. Lowkey the one stable thing in the whole setup 🔒
Each group inside the repeater gets its own unique group number in the range 1..rptrGroupCapacity. Groups can come and go without triggering a management reset, and their numbers can be sparse within the repeater ✨ For example, in a 12-card cage, cards 3, 5, 6, and 7 could together form a single repeater, and the implementor could number them as groups 3, 5, 6, and 7 respectively. Gaps are giving intentional 🦋
The object rptrGroupPortCapacity also has a maximum value of 1024, and it tells you the maximum number of ports a given group can contain 🧚 Its value must not change for a given group. BUT a group can be deleted from the repeater and replaced with a group that has a different number of ports 😭 When that happens, rptrGroupLastOperStatusChange will show that a change took place. Plot twist, but make it organized 💜
Each port in the repeater is uniquely identified by a combination of group number and port number. The port number is an integer in the range 1..rptrGroupPortCapacity 🌈 Just like groups, ports inside a group can be sparsely numbered too. And ports can come and go within a group without causing a management reset, so no drama for the rest of the setup 💅
3.2. Supporting Functions ✨
okay so the IEEE 802.3 Hub Management draft [10] defines seven functions and seven signals that describe exactly when port counters get incremented 🔢 the whole picture is in Figure 3 and it's giving pure organization 💅
+---------+
|Collision|--------------------->CollisionEvent
CollIn(X)+>|Event |
| |Funct | +--------+
| +---------+ |Activity|
| +-------+ |Timing |->ActivityDuration
+>|Carrier| +---->|Funct |
|Event | | +--------+
DataIn(X)->|Funct |+-----+---------------->CarrierEvent
+-------+|
| +-------+
+>|Framing|------------>FramingError
|Funct | +-------+
decodedData---------->| |+>|Octet |
+-------+| |Count |->OctetCount
| |Funct |
| +-------+
| +-------+
Octet | |Cyclic |
Stream +>|Redund.|
| |Check |->FCSError
| |Funct |
| +-------+
| +-------+
| |Source |
+>|Address|->SourceAddress
|Funct |
+-------+
Figure 3. Port Functions Relationshipngl the CollisionEvent, ActivityDuration, CarrierEvent, FramingError, OctetCount, FCSError, and SourceAddress output signals here are not retrievable MIB objects 🙅♀️ they're just concepts used to define the MIB objects. the inputs come from Section 9 of the IEEE 802.3 standard [9] 🎀
Collision Event Function: the collision event function asserts the CollisionEvent signal when the CollIn(X) variable has the value SQE 🚨 the CollisionEvent signal stays asserted until any CarrierEvent signal gets asserted because of the reception of the following event 💜
Carrier Event Function: the carrier event function asserts the CarrierEvent signal when the repeater exits the IDLE state, Fig 9-2 [9], and the port has been determined to be port N 🦋 it deasserts the CarrierEvent signal when, for a duration of at least Carrier Recovery Time (Ref: 9.5.6.5 [9]), both the DataIn(N) variable has the value II and the CollIn(N) variable has the value -SQE ✨ the value N is the port assigned at the time of the transition from the IDLE state 🧚
Framing Function: the framing function recognizes the boundaries of an incoming frame by monitoring the CarrierEvent signal and the decoded data stream 👀 data bits are accepted while the CarrierEvent signal is asserted 🌸 it strips the preamble and start of frame delimiter from the received data stream, and the remaining bits are aligned along octet boundaries. if there is not an integral number of octets, then FramingError shall be asserted 😭 the FramingError signal gets cleared when the CarrierEvent signal is asserted because of the reception of the following event 💅
Activity Timing Function: the activity timing function measures how long the CarrierEvent signal stays asserted ⏱️ this duration value must be adjusted by removing the value of Carrier Recovery Time (Ref: 9.5.6.5 [9]) to get the true duration of activity on the network 🔥 its output is the ActivityDuration value, which is the duration of the CarrierEvent signal expressed in units of bit times 🍓
Octet Counting Function: the octet counting function counts the number of complete octets received from the output of the framing function 🔢 its output is the OctetCount value. the OctetCount value gets reset to zero when the CarrierEvent signal is asserted because of the reception of the following event 🫶
Cyclic Redundancy Check Function: the cyclic redundancy check function verifies that the sequence of octets output by the framing function contains a valid frame check sequence field 🔍 that FCS field is the last four octets received from the output of the framing function. the algorithm for generating an FCS from the octet stream is specified in 3.2.8 [9]. if the FCS generated by this algorithm is not the same as the last four octets received from the framing function, then the FCSError signal is asserted 🚫 the FCSError signal gets cleared when the CarrierEvent signal is asserted because of the reception of the following event 🌈
Source Address Function: the source address function extracts octets from the stream output by the framing function 🎀 the seventh through twelfth octets shall be extracted from the octet stream and output as the SourceAddress variable. the SourceAddress variable is set to an invalid state when the CarrierEvent signal is asserted because of the reception of the following event 💖
3.3. Structure of MIB 🧩
okay the objects in this MIB are arranged into MIB groups 🍰 and each MIB group is organized as a set of related objects 💜
3.3.1. The Basic Group Definitions 💎
this mandatory group holds the objects that apply to all repeaters 🙌 it has status, parameter and control objects for the repeater as a whole, the port groups inside the repeater, and the individual ports too 👑
3.3.2. The Monitor Group Definitions 📊
this optional group holds monitoring statistics for the repeater as a whole and for individual ports 👀
3.3.3. The Address Tracking Group Definitions 🗺️
this optional group holds objects for tracking the MAC addresses of the DTEs attached to the ports of the repeater 🦋
3.4. Relationship to Other MIBs 🤝
it's assumed that a repeater implementing this MIB will also implement (at least) the 'system' group defined in MIB-II [4] 🫶
3.4.1. Relationship to the 'system' group 🪞
in MIB-II, the 'system' group is defined as mandatory for all systems, so each managed entity contains one instance of each object in the 'system' group 💅 those objects apply to the entity even if the entity's only job is managing a repeater 🎀
3.4.2. Relationship to the 'interfaces' group 🌐
in MIB-II, the 'interfaces' group is mandatory for all systems and holds information on an entity's interfaces, where each interface is thought of as attached to a 'subnetwork' 🛜 (heads up, 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 🙅♀️ so 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 it does not apply to the repeater's ports 💀
this is totally consistent with the physical-layer nature of a repeater ⚡ a repeater is a bitwise store-and-forward device. it recognizes activity and bits, but it doesn't process incoming data based on any packet-related information (like checksum or addresses) 🧠 a repeater has NO MAC address, NO MAC implementation, and it does not pass packets up to higher-level protocol entities for processing 🚫
(when a network management entity is observing the repeater, it may appear like the repeater is passing packets up to a higher-level protocol entity. but that's just how management gets implemented, and passing that management information is not part of the repeater functionality 👀)
3.5. Textual Conventions 🏷️
the datatype MacAddress is used as a textual convention in this document 💅 this textual convention has NO effect on either the syntax or the semantics of any managed object 🙌 objects defined with this convention are always encoded using the rules that define their primitive type 🔐 so no changes to the SMI or the SNMP are necessary to accommodate it, since it's only adopted for the convenience of readers 🫶
4. Definitions 📜✨
SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter, TimeTicks, Gauge
FROM RFC1155-SMI
mib-2, DisplayString FROM RFC1213-MIB
TRAP-TYPE FROM RFC-1215
OBJECT-TYPE FROM RFC-1212;
snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }
-- All representations of MAC addresses in this MIB Module use,
-- as a textual convention (i.e., this convention does not affect
-- their encoding), the data type:
MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet address in
-- the "canonical" order
-- defined by IEEE 802.1a, i.e., as if it were transmitted least
-- significant bit first.
-- References
--
-- The following references are used throughout this MIB:
--
-- [IEEE 802.3 Std]
-- refers to IEEE 802.3/ISO 8802-3 Information processing
-- systems - Local area networks - Part 3: Carrier sense
-- multiple access with collision detection (CSMA/CD)
-- access method and physical layer specifications
-- (2nd edition, September 21, 1990).
--
-- [IEEE 802.3 Rptr Mgt]
-- refers to IEEE P802.3K, 'Layer Management for 10 Mb/s
-- Baseband Repeaters, Section 19,' Draft Supplement to
-- ANSI/IEEE 802.3, (Draft 8, April 9, 1992)
-- MIB Groups
--
-- The rptrBasicPackage group is mandatory.
-- The rptrMonitorPackage and rptrAddrTrackPackage
-- groups are optional.
rptrBasicPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 1 }
rptrMonitorPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 2 }
rptrAddrTrackPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 3 }
-- object identifiers for organizing the information
-- in the groups by repeater, port-group, and port
rptrRptrInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 1 }
rptrGroupInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 2 }
rptrPortInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 3 }
rptrMonitorRptrInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 }
rptrMonitorGroupInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 }
rptrMonitorPortInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }
rptrAddrTrackRptrInfo -- this subtree is currently unused
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 }
rptrAddrTrackGroupInfo -- this subtree is currently unused
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 }
rptrAddrTrackPortInfo
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 }
--
-- The BASIC GROUP
--
-- Implementation of the Basic Group is mandatory for all
-- managed repeaters.
--
-- Basic Repeater Information
--
-- Configuration, status, and control objects for the overall
-- repeater
--
rptrGroupCapacity OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrGroupCapacity is the number of groups
that can be contained within the repeater. Within
each managed repeater, the groups are uniquely
numbered in the range from 1 to rptrGroupCapacity.okay bestie we're still deep in the definitions and these MIB objects are giving main character energy 💅✨ the code stays exactly as written because it has to 🫶
Some groups may not be present in the repeater, in
which case the actual number of groups present
will be less than rptrGroupCapacity. The number
of groups present will never be greater than
rptrGroupCapacity.
Note: In practice, this will generally be the
number of field-replaceable units (i.e., modules,
cards, or boards) that can fit in the physical
repeater enclosure, and the group numbers will
correspond to numbers marked on the physical
enclosure."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterGroupCapacity."
::= { rptrRptrInfo 1 }
rptrOperStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- undefined or unknown status
ok(2), -- no known failures
rptrFailure(3), -- repeater-related failure
groupFailure(4), -- group-related failure
portFailure(5), -- port-related failure
generalFailure(6) -- failure, unspecified type
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrOperStatus object indicates the
operational state of the repeater. The
rptrHealthText object may be consulted for more
specific information about the state of the
repeater's health.
In the case of multiple kinds of failures (e.g.,
repeater failure and port failure), the value of
this attribute shall reflect the highest priority
failure in the following order:
rptrFailure(3)
groupFailure(4)
portFailure(5)
generalFailure(6)."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterHealthState."
::= { rptrRptrInfo 2 }ok the rptrOperStatus one is so good, the priority order is literally a whole storyline 🔥 next up is the health text object 🌸
rptrHealthText OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The health text object is a text string that
provides information relevant to the operational
state of the repeater. Agents may use this string
to provide detailed information on current
failures, including how they were detected, and/or
instructions for problem resolution. The contents
are agent-specific."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterHealthText."
::= { rptrRptrInfo 3 }
rptrReset OBJECT-TYPE
SYNTAX INTEGER {
noReset(1),
reset(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to reset(2) causes a
transition to the START state of Fig 9-2 in
section 9 [IEEE 802.3 Std].
Setting this object to noReset(1) has no effect.
The agent will always return the value noReset(1)
when this object is read.
This action does not reset the management counters
defined in this document nor does it affect the
portAdminStatus parameters. Included in this
action is the execution of a disruptive Self-Test
with the following characteristics: a) The nature
of the tests is not specified. b) The test resets
the repeater but without affecting management
information about the repeater. c) The test does
not inject packets onto any segment. d) Packets
received during the test may or may not be
transferred. e) The test does not interfere with
management functions.
As a result of this action a rptrResetEvent trap
should be sent."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
acResetRepeater."
::= { rptrRptrInfo 4 }
rptrNonDisruptTest OBJECT-TYPE
SYNTAX INTEGER {
noSelfTest(1),
selfTest(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to selfTest(2) causes the
repeater to perform a agent-specific, non-
disruptive self-test that has the following
characteristics: a) The nature of the tests is
not specified. b) The test does not change the
state of the repeater or management information
about the repeater. c) The test does not inject
packets onto any segment. d) The test does not
prevent the relay of any packets. e) The test
does not interfere with management functions.
After performing this test the agent will update
the repeater health information and send a
rptrHealth trap.
Setting this object to noSelfTest(1) has no
effect. The agent will always return the value
noSelfTest(1) when this object is read."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
acExecuteNonDisruptiveSelfTest."
::= { rptrRptrInfo 5 }
rptrTotalPartitionedPorts OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object returns the total number of ports in
the repeater whose current state meets all three
of the following criteria: rptrPortOperStatus
does not have the value notPresent(3),
rptrPortAdminStatus is enabled(1), and
rptrPortAutoPartitionState is autoPartitioned(2)."
::= { rptrRptrInfo 6 }
--
-- The Basic Port Group Table
--
rptrGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of descriptive and status information about
the groups of ports."
::= { rptrGroupInfo 1 }
rptrGroupEntry OBJECT-TYPE
SYNTAX RptrGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing information
about a single group of ports."
INDEX { rptrGroupIndex }
::= { rptrGroupTable 1 }
RptrGroupEntry ::=
SEQUENCE {
rptrGroupIndex
INTEGER,
rptrGroupDescr
DisplayString,
rptrGroupObjectID
OBJECT IDENTIFIER,
rptrGroupOperStatus
INTEGER,
rptrGroupLastOperStatusChange
TimeTicks,
rptrGroupPortCapacity
INTEGER
}
rptrGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group within the
repeater for which this entry contains
information. This value is never greater than
rptrGroupCapacity."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
aGroupID."
::= { rptrGroupEntry 1 }
rptrGroupDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the group. This value
should include the full name and version
identification of the group's hardware type and
indicate how the group is differentiated from
other groups in the repeater. Plug-in Module, Rev
A' or 'Barney Rubble 10BASE-T 4-port SIMM socket
Version 2.1' are examples of valid group
descriptions.
It is mandatory that this only contain printable
ASCII characters."
::= { rptrGroupEntry 2 }
rptrGroupObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The vendor's authoritative identification of the
group. This value is allocated within the SMI
enterprises subtree (1.3.6.1.4.1) and provides a
straight-forward and unambiguous means for
determining what kind of group is being managed.
For example, this object could take the value
1.3.6.1.4.1.4242.1.2.14 if vendor 'Flintstones,
Inc.' was assigned the subtree 1.3.6.1.4.1.4242,
and had assigned the identifier
1.3.6.1.4.1.4242.1.2.14 to its 'Wilma Flintstone
6-Port FOIRL Plug-in Module.'"
::= { rptrGroupEntry 3 }
rptrGroupOperStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
operational(2),
malfunctioning(3),
notPresent(4),
underTest(5),
resetInProgress(6)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An object that indicates the operational status
of the group.
A status of notPresent(4) indicates that the group
is temporarily or permanently physically and/or
logically not a part of the repeater. It is an
implementation-specific matter as to whether the
agent effectively removes notPresent entries from
the table.
A status of operational(2) indicates that the
group is functioning, and a status of
malfunctioning(3) indicates that the group is
malfunctioning in some way."
::= { rptrGroupEntry 4 }
rptrGroupLastOperStatusChange OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An object that contains the value of sysUpTime at
the time that the value of the rptrGroupOperStatus
object for this group last changed.
A value of zero indicates that the group's oper
status has not changed since the agent last
restarted."
::= { rptrGroupEntry 5 }
rptrGroupPortCapacity OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrGroupPortCapacity is the number of ports
that can be contained within the group. Valid
range is 1-1024. Within each group, the ports are
uniquely numbered in the range from 1 to
rptrGroupPortCapacity.
Note: In practice, this will generally be the
number of ports on a module, card, or board, and
the port numbers will correspond to numbers marked
on the physical embodiment."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
aGroupPortCapacity."
::= { rptrGroupEntry 6 }
--
-- The Basic Port Table
--Okay bestie, we're back in the MIB definitions, and first up is the port table 🎀 It's basically the list of every port with its descriptive and status info, and each entry is indexed by group and port 🦋
rptrPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of descriptive and status information about
the ports."
::= { rptrPortInfo 1 }
rptrPortEntry OBJECT-TYPE
SYNTAX RptrPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing information
about a single port."
INDEX { rptrPortGroupIndex, rptrPortIndex }
::= { rptrPortTable 1 }
RptrPortEntry ::=
SEQUENCE {
rptrPortGroupIndex
INTEGER,
rptrPortIndex
INTEGER,
rptrPortAdminStatus
INTEGER,
rptrPortAutoPartitionState
INTEGER,
rptrPortOperStatus
INTEGER
}
rptrPortGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrPortEntry 1 }
rptrPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information. This
value can never be greater than
rptrGroupPortCapacity for the associated group."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrPortEntry 2 }
rptrPortAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to disabled(2) disables the
port. A disabled port neither transmits nor
receives. Once disabled, a port must be
explicitly enabled to restore operation. A port
which is disabled when power is lost or when a
reset is exerted shall remain disabled when normal
operation resumes.
The admin status takes precedence over auto-
partition and functionally operates between the
auto-partition mechanism and the AUI/PMA.
Setting this object to enabled(1) enables the port
and exerts a BEGIN on the port's auto-partition
state machine.
(In effect, when a port is disabled, the value of
rptrPortAutoPartitionState for that port is frozen
until the port is next enabled. When the port
becomes enabled, the rptrPortAutoPartitionState
becomes notAutoPartitioned(1), regardless of its
pre-disabling state.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortAdminState and 19.2.6.3, acPortAdminControl."
::= { rptrPortEntry 3 }
rptrPortAutoPartitionState OBJECT-TYPE
SYNTAX INTEGER {
notAutoPartitioned(1),
autoPartitioned(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The autoPartitionState flag indicates whether the
port is currently partitioned by the repeater's
auto-partition protection.
The conditions that cause port partitioning are
specified in partition state machine in Section 9
[IEEE 802.3 Std]. They are not differentiated
here."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAutoPartitionState."
::= { rptrPortEntry 4 }
rptrPortOperStatus OBJECT-TYPE
SYNTAX INTEGER {
operational(1),
notOperational(2),
notPresent(3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object indicates the port's operational
status. The notPresent(3) status indicates the
port is physically removed (note this may or may
not be possible depending on the type of port.)
The operational(1) status indicates that the port
is enabled (see rptrPortAdminStatus) and working,
even though it might be auto-partitioned (see
rptrPortAutoPartitionState).
If this object has the value operational(1) and
rptrPortAdminStatus is set to disabled(2), it is
expected that this object's value will change to
notOperational(2) soon after."
::= { rptrPortEntry 5 }The rptrPortAdminStatus one is giving main character energy 👑 It covers what happens when you disable a port, what happens after a power loss or reset, and how it interacts with auto-partition, so read it slowly 💅
Next up is the MONITOR GROUP 🌸 The spec says implementing it is optional, but once you do any part of it, the whole group has to be in there 🫶
--
-- The MONITOR GROUP
--
-- Implementation of this group is optional, but within the
-- group all elements are mandatory. If a managed repeater
-- implements any part of this group, the entire group shall
-- be implemented.
--
-- Repeater Monitor Information
--
-- Performance monitoring statistics for the repeater
--
rptrMonitorTransmitCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented every time the
repeater state machine enters the TRANSMIT
COLLISION state from any state other than ONE PORT
LEFT (Ref: Fig 9-2, IEEE 802.3 Std).
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aTransmitCollisions."
::= { rptrMonitorRptrInfo 1 }
--
-- The Group Monitor Table
--
rptrMonitorGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrMonitorGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of performance and error statistics for the
groups."
::= { rptrMonitorGroupInfo 1 }
rptrMonitorGroupEntry OBJECT-TYPE
SYNTAX RptrMonitorGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing total
performance and error statistics for a single
group. Regular retrieval of the information in
this table provides a means of tracking the
performance and health of the networked devices
attached to this group's ports.
The counters in this table are redundant in the
sense that they are the summations of information
already available through other objects. However,
these sums provide a considerable optimization of
network management traffic over the otherwise
necessary retrieval of the individual counters
included in each sum."
INDEX { rptrMonitorGroupIndex }
::= { rptrMonitorGroupTable 1 }
RptrMonitorGroupEntry ::=
SEQUENCE {
rptrMonitorGroupIndex
INTEGER,
rptrMonitorGroupTotalFrames
Counter,
rptrMonitorGroupTotalOctets
Counter,
rptrMonitorGroupTotalErrors
Counter
}
rptrMonitorGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group within the
repeater for which this entry contains
information."
::= { rptrMonitorGroupEntry 1 }
rptrMonitorGroupTotalFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of frames of valid frame length
that have been received on the ports in this
group. This counter is the summation of the
values of the rptrMonitorPortReadableFrames
counters for all of the ports in the group.
This statistic provides one of the parameters
necessary for obtaining the packet error rate.
The approximate minimum time for rollover of this
counter is 80 hours."
::= { rptrMonitorGroupEntry 2 }
rptrMonitorGroupTotalOctets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of octets contained in the valid
frames that have been received on the ports in
this group. This counter is the summation of the
values of the rptrMonitorPortReadableOctets
counters for all of the ports in the group.
This statistic provides an indicator of the total
data transferred. The approximate minimum time
for rollover of this counter is 58 minutes."
::= { rptrMonitorGroupEntry 3 }
rptrMonitorGroupTotalErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of errors which have occurred on
all of the ports in this group. This counter is
the summation of the values of the
rptrMonitorPortTotalErrors counters for all of the
ports in the group."
::= { rptrMonitorGroupEntry 4 }
--
-- The Port Monitor Table
--
rptrMonitorPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrMonitorPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of performance and error statistics for the
ports."
::= { rptrMonitorPortInfo 1 }
rptrMonitorPortEntry OBJECT-TYPE
SYNTAX RptrMonitorPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing performance and
error statistics for a single port."
INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex }
::= { rptrMonitorPortTable 1 }
RptrMonitorPortEntry ::=
SEQUENCE {
rptrMonitorPortGroupIndex
INTEGER,
rptrMonitorPortIndex
INTEGER,
rptrMonitorPortReadableFrames
Counter,
rptrMonitorPortReadableOctets
Counter,
rptrMonitorPortFCSErrors
Counter,
rptrMonitorPortAlignmentErrors
Counter,
rptrMonitorPortFrameTooLongs
Counter,
rptrMonitorPortShortEvents
Counter,
rptrMonitorPortRunts
Counter,
rptrMonitorPortCollisions
Counter,
rptrMonitorPortLateEvents
Counter,
rptrMonitorPortVeryLongEvents
Counter,
rptrMonitorPortDataRateMismatches
Counter,
rptrMonitorPortAutoPartitions
Counter,
rptrMonitorPortTotalErrors
Counter
}
rptrMonitorPortGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrMonitorPortEntry 1 }okay so we're still in the MIB definitions and the port counters are literally the best part 🫶 these are the objects that keep track of what each port sees on the wire 🔌✨
rptrMonitorPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrMonitorPortEntry 2 }
rptrMonitorPortReadableFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object is the number of frames of valid
frame length that have been received on this port.
This counter is incremented by one for each frame
received on this port whose OctetCount is greater
than or equal to minFrameSize and less than or
equal to maxFrameSize (Ref: IEEE 802.3 Std,
4.4.2.1) and for which the FCSError and
CollisionEvent signals are not asserted.
This statistic provides one of the parameters
necessary for obtaining the packet error rate.
The approximate minimum time for rollover of this
counter is 80 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aReadableFrames."
::= { rptrMonitorPortEntry 3 }
rptrMonitorPortReadableOctets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object is the number of octets contained in
valid 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.
This statistic provides an indicator of the total
data transferred. The approximate minimum time
for rollover of this counter is 58 minutes."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aReadableOctets."
::= { rptrMonitorPortEntry 4 }
rptrMonitorPortFCSErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port with the FCSError signal
asserted and the FramingError and CollisionEvent
signals deasserted and whose OctetCount is greater
than or equal to minFrameSize and less than or
equal to maxFrameSize (Ref: 4.4.2.1, IEEE 802.3
Std).
The approximate minimum time for rollover of this
counter is 80 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aFrameCheckSequenceErrors."
::= { rptrMonitorPortEntry 5 }
rptrMonitorPortAlignmentErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port with the FCSError and
FramingError signals asserted and CollisionEvent
signal deasserted and whose OctetCount is greater
than or equal to minFrameSize and less than or
equal to maxFrameSize (Ref: IEEE 802.3 Std,
4.4.2.1). If rptrMonitorPortAlignmentErrors is
incremented then the rptrMonitorPortFCSErrors
Counter shall not be incremented for the same
frame.
The approximate minimum time for rollover of this
counter is 80 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAlignmentErrors."
::= { rptrMonitorPortEntry 6 }
rptrMonitorPortFrameTooLongs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port whose OctetCount is greater
than maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 Std).
If rptrMonitorPortFrameTooLongs is incremented
then neither the rptrMonitorPortAlignmentErrors
nor the rptrMonitorPortFCSErrors counter shall be
incremented for the frame.
The approximate minimum time for rollover of this
counter is 61 days."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aFramesTooLong."
::= { rptrMonitorPortEntry 7 }
rptrMonitorPortShortEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port with ActivityDuration
less than ShortEventMaxTime. ShortEventMaxTime is
greater than 74 bit times and less than 82 bit
times. ShortEventMaxTime has tolerances included
to provide for circuit losses between a
conformance test point at the AUI and the
measurement point within the state machine.
Note: shortEvents may indicate externally
generated noise hits which will cause the repeater
to transmit Runts to its other ports, or propagate
a collision (which may be late) back to the
transmitting DTE and damaged frames to the rest of
the network.
Implementors may wish to consider selecting the
ShortEventMaxTime towards the lower end of the
allowed tolerance range to accommodate bit losses
suffered through physical channel devices not
budgeted for within this standard.
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aShortEvents."
::= { rptrMonitorPortEntry 8 }
rptrMonitorPortRunts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port that meets one of the
following two conditions. Only one test need be
made. a) The ActivityDuration is greater than
ShortEventMaxTime and less than ValidPacketMinTime
and the CollisionEvent signal is deasserted. b)
The OctetCount is less than 64, the
ActivityDuration is greater than ShortEventMaxTime
and the CollisionEvent signal is deasserted.
ValidPacketMinTime is greater than or equal to 552
bit times and less than 565 bit times.
An event whose length is greater than 74 bit times
but less than 82 bit times shall increment either
the shortEvents counter or the runts counter but
not both. A CarrierEvent greater than or equal to
552 bit times but less than 565 bit times may or
may not be counted as a runt.
ValidPacketMinTime has tolerances included to
provide for circuit losses between a conformance
test point at the AUI and the measurement point
within the state machine.
Runts usually indicate collision fragments, a
normal network event. In certain situations
associated with large diameter networks a
percentage of runts may exceed ValidPacketMinTime.
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, aRunts."
::= { rptrMonitorPortEntry 9 }
rptrMonitorPortCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for any
CarrierEvent signal on any port for which the
CollisionEvent signal on this port is asserted.
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aCollisions."
::= { rptrMonitorPortEntry 10 }
rptrMonitorPortLateEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port in which the CollIn(X)
variable transitions to the value SQE (Ref:
9.6.6.2, IEEE 802.3 Std) while the
ActivityDuration is greater than the
LateEventThreshold. Such a CarrierEvent is
counted twice, as both a collision and as a
lateEvent.
The LateEventThreshold is greater than 480 bit
times and less than 565 bit times.
LateEventThreshold has tolerances included to
permit an implementation to build a single
threshold to serve as both the LateEventThreshold
and ValidPacketMinTime threshold.
The approximate minimum time for rollover of this
counter is 81 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLateEvents."
::= { rptrMonitorPortEntry 11 }
rptrMonitorPortVeryLongEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port whose ActivityDuration
is greater than the MAU Jabber Lockup Protection
timer TW3 (Ref: 9.6.1 & 9.6.5, IEEE 802.3 Std).
Other counters may be incremented as appropriate."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aVeryLongEvents."
::= { rptrMonitorPortEntry 12 }
rptrMonitorPortDataRateMismatches OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port that meets all of the
following conditions: a) The CollisionEvent
signal is not asserted. b) The ActivityDuration
is greater than ValidPacketMinTime. c) The
frequency (data rate) is detectably mismatched
from the local transmit frequency. The exact
degree of mismatch is vendor specific and is to be
defined by the vendor for conformance testing.
When this event occurs, other counters whose
increment conditions were satisfied may or may not
also be incremented, at the implementor's
discretion. Whether or not the repeater was able
to maintain data integrity is beyond the scope of
this standard."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aDataRateMismatches."
::= { rptrMonitorPortEntry 13 }the vibe here is basically "count every weird thing that happens to a frame" 🔢💜 the rollover times are so specific it's giving obsessed 😭🎀
Okay bestie, this part is where the Monitor group wraps up 💖 and then we get the whole Address Tracking group plus the traps 🦋 Let's go!!
rptrMonitorPortAutoPartitions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each time
the repeater has automatically partitioned this
port. The conditions that cause port partitioning
are specified in the partition state machine in
Section 9 [IEEE 802.3 Std]. They are not
differentiated here."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAutoPartitions."
::= { rptrMonitorPortEntry 14 }
rptrMonitorPortTotalErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of errors which have occurred on
this port. This counter is the summation of the
values of other error counters (for the same
port), namely:
rptrMonitorPortFCSErrors,
rptrMonitorPortAlignmentErrors,
rptrMonitorPortFrameTooLongs,
rptrMonitorPortShortEvents,
rptrMonitorPortLateEvents,
rptrMonitorPortVeryLongEvents, and
rptrMonitorPortDataRateMismatches.
This counter is redundant in the sense that it is
the summation of information already available
through other objects. However, it is included
specifically because the regular retrieval of this
object as a means of tracking the health of a port
provides a considerable optimization of network
management traffic over the otherwise necessary
retrieval of the summed counters."
::= { rptrMonitorPortEntry 15 }So rptrMonitorPortAutoPartitions ticks up every time the repeater auto-partitions a port 🙈 The partition rules live in the partition state machine (Section 9 of IEEE 802.3), and this object doesn't try to split them up. Then rptrMonitorPortTotalErrors is basically the sum of seven other error counters for the same port 🧮 It's technically redundant, but ngl it's a whole vibe because grabbing one number is way cheaper than pulling all seven 🔥
Address Tracking Group vibes 🌸
--
-- The ADDRESS TRACKING GROUP
--
-- Implementation of this group is optional; it is appropriate
-- for all systems which have the necessary metering. If a
-- managed repeater implements any part of this group, the entire
-- group shall be implemented.
--
-- The Port Address Tracking Table
--
rptrAddrTrackTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrAddrTrackEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of address mapping information about the
ports."
::= { rptrAddrTrackPortInfo 1 }
rptrAddrTrackEntry OBJECT-TYPE
SYNTAX RptrAddrTrackEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing address mapping
information about a single port."
INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex }
::= { rptrAddrTrackTable 1 }
RptrAddrTrackEntry ::=
SEQUENCE {
rptrAddrTrackGroupIndex
INTEGER,
rptrAddrTrackPortIndex
INTEGER,
rptrAddrTrackLastSourceAddress
MacAddress,
rptrAddrTrackSourceAddrChanges
Counter
}
rptrAddrTrackGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrAddrTrackEntry 1 }
rptrAddrTrackPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrAddrTrackEntry 2 }
rptrAddrTrackLastSourceAddress OBJECT-TYPE
SYNTAX MacAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object is the SourceAddress of the last
readable frame (i.e., counted by
rptrMonitorPortReadableFrames) received by this
port."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLastSourceAddress."
::= { rptrAddrTrackEntry 3 }
rptrAddrTrackSourceAddrChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each time
that the rptrAddrTrackLastSourceAddress attribute
for this port has changed.
This may indicate whether a link is connected to a
single DTE or another multi-user segment.
The approximate minimum time for rollover of this
counter is 81 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aSourceAddressChanges."
::= { rptrAddrTrackEntry 4 }Okay so this whole group is the address tracking squad 💅 It's OPTIONAL to implement, and it's totally appropriate for any system that has the metering it needs 🦋 BUT, and this is a big but, if a managed repeater implements ANY part of it, the entire group SHALL be implemented. No picking and choosing 🙅♀️
The table is indexed by a group index and a port index (both 1..1024), and each row remembers the SourceAddress of the last readable frame that came in on that port. The rptrAddrTrackSourceAddrChanges counter goes up each time that last-seen address changes 👑 The spec says it may hint whether a link goes to one DTE or to a shared multi-user segment, and the approximate minimum rollover time is 81 hours 🕐
Traps 🔔
-- Traps for use by Repeaters
-- Traps are defined using the conventions in RFC 1215 [8].
rptrHealth TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrHealth trap conveys information related
to the operational status of the repeater. This
trap is sent only when the oper status of the
repeater changes.
The rptrHealth trap must contain the
rptrOperStatus object. The agent may optionally
include the rptrHealthText object in the varBind
list. See the rptrOperStatus and rptrHealthText
objects for descriptions of the information that
is sent.
The agent must throttle the generation of
consecutive rptrHealth traps so that there is at
least a five-second gap between them."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
hubHealth notification."
::= 1
rptrGroupChange TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrGroupIndex }
DESCRIPTION
"This trap is sent when a change occurs in the
group structure of a repeater. This occurs only
when a group is logically or physically removed
from or added to a repeater. The varBind list
contains the identifier of the group that was
removed or added.
The agent must throttle the generation of
consecutive rptrGroupChange traps for the same
group so that there is at least a five-second gap
between them."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
groupMapChange notification."
::= 2
rptrResetEvent TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrResetEvent trap conveys information
related to the operational status of the repeater.
This trap is sent on completion of a repeater
reset action. A repeater reset action is defined
as an a transition to the START state of Fig 9-2
in section 9 [IEEE 802.3 Std], when triggered by a
management command (e.g., an SNMP Set on the
rptrReset object).
The agent must throttle the generation of
consecutive rptrResetEvent traps so that there is
at least a five-second gap between them.
The rptrResetEvent trap is not sent when the agent
restarts and sends an SNMP coldStart or warmStart
trap. However, it is recommended that a repeater
agent send the rptrOperStatus object as an
optional object with its coldStart and warmStart
trap PDUs.
The rptrOperStatus object must be included in the
varbind list sent with this trap. The agent may
optionally include the rptrHealthText object as
well."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset
notification."
::= 3
ENDTraps time, bestie 🔔✨ These are defined using the conventions from RFC 1215 [8] 📖 Here's the tea on each one:
rptrHealth(1) fires only when the repeater's oper status changes 🩺 It MUST containrptrOperStatus, the agent MAY optionally includerptrHealthText, and the agent MUST throttle consecutiverptrHealthtraps so there's at least a five-second gap between them ⏱️rptrGroupChange(2) fires when a group gets logically or physically added or removed, and the varBind holds that group's identifier 🧩 The agent MUST throttle consecutive traps for the same group with at least a five-second gap 💜rptrResetEvent(3) fires when a management-triggered reset finishes (like an SNMP Set onrptrReset) 🔄 It's NOT sent on a coldStart or warmStart restart. Instead it's RECOMMENDED that the agent sendrptrOperStatusas an OPTIONAL object with those restart traps 🌈 TherptrOperStatusobject MUST be in the varbind list, the agent MAY optionally includerptrHealthTexttoo, and throttling with a five-second gap is MUST here as well 🎀
And that's the END of the MIB module 🧚✨
5. Acknowledgments ✨
okay bestie, this section is basically the thank-you list 🫶 This document came from the IETF Hub MIB Working Group, and it's based on drafts from the IEEE 802.3 Repeater Management Task Force. The working group members were:
Karl Auerbach karl@eng.sun.com
Jim Barnes barnes@xylogics.com
Steve Bostock steveb@novell.com
David Bridgham dab@asylum.sf.ca.us
Jack Brown jbrown@huahuca-emh8.army.mil
Howard Brown brown@ctron.com
Lida Canin lida@apple.com
Jeffrey Case case@cs.utk.edu
Carson Cheung carson@bnr.com.ca
James Codespote jpcodes@tycho.ncsc.mil
John Cook cook@chipcom.com
Dave Cullerot cullerot@ctron.com
James Davin jrd@ptt.lcs.mit.edu
Gary Ellis garye@hpspd.spd.hp.com
David Engel david@cds.com
Mike Erlinger mike@mti.com
Jeff Erwin
Bill Fardy fardy@ctron.com
Jeff Fried jmf@relay.proteon.com
Bob Friesenhahn pdrusa!bob@uunet.uu.net
Shawn Gallagher gallagher@quiver.enet.dec.com
Mike Grieves mgrieves@chipcom.com
Walter Guilarte 70026.1715@compuserve.com
Phillip Hasse phasse@honchuca-emh8.army.mil
Mark Hoerth mark_hoerth@hp0400.desk.hp.com
Greg Hollingsworth gregh@mailer.jhuapl.edu
Ron Jacoby rj@sgi.com
Mike Janson mjanson@mot.com
Ken Jones konkord!ksj@uunet.uu.net
Satish Joshi sjoshi@synoptics.com
Frank Kastenholz kasten@europa.clearpoint.com
Manu Kaycee kaycee@trlian.enet.dec.com
Mark Kepke mak@cnd.hp.com
Mark Kerestes att!alux2!hawk@uunet.uu.net
Kenneth Key key@cs.utk.edu
Yoav Kluger ykluger@fibhaifa.com
Cheryl Krupczak cheryl@cc.gatech.edu
Ron Lau rlau@synoptics.com
Chao-Yu Liang cliang@synoptics.com
Dave Lindemulder da@mtung.att.com
Richie McBride rm@bix.co.uk
Keith McCloghrie kzm@hls.com
Evan McGinnis bem@3com.com
Donna McMaster mcmaster@synoptics.com
David Minnich dwm@fibercom.com
Lynn Monsanto monsanto@sun.com
Miriam Nihart miriam@decwet.zso.dec.com
Niels Ole Brunsgaard nob@dowtyns.dk
Edison Paw esp@3com.com
David Perkins dperkins@synoptics.com
Jason Perreault perreaul@interlan.interlan.com
John Pickens jrp@3com.com
Jim Reinstedler jimr@sceng.ub.com
Anil Rijsinghani anil@levers.enet.dec.com
Sam Roberts sroberts@farallon.com
Dan Romascanu dan@lannet.com
Marshall Rose mrose@dbc.mtview.ca.us
Rick Royston rick@lsumus.sncc.lsu.edu
Michael Sabo sabo@dockmaster.ncsc.mil
Jonathan Saperia saperia@tcpjon.enet.dec.com
Mark Schaefer schaefer@davidsys.com
Anil Singhal nsinghal@hawk.ulowell.edu
Timon Sloane peernet!timon@uunet.uu.net
Bob Stewart rlstewart@eng.xyplex.com
Emil Sturniolo emil@dss.com
Bruce Taber taber@interlan.com
Iris Tal 437-3580@mcimail.com
Mark Therieau markt@python.eng.microcom.com
Geoff Thompson thompson@synoptics.com
Dean Throop throop@dg-rtp.dg.com
Steven Waldbusser waldbusser@andrew.cmu.edu
Timothy Walden tmwalden@saturn.sys.acc.com
Philip Wang watadn!phil@uunet.uu.net
Drew Wansley dwansley@secola.columbia.ncr.com
David Ward dward@chipcom.com
Steve Wong wong@took.enet.dec.com
Paul Woodruff paul-woodruff@3com.com
Brian Wyld brianw@spider.co.uk
June-Kang Yang natadm!yang@uunet.uu.net
Henry Yip natadm!henry@uunet.uu.net
John Ziegler ziegler@artel.com
Joseph Zur fibronics!zur@uunet.uu.net6. References 📚
okay so here are all the sources this doc leans on 🤓
- Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.
- McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990.
- Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
- Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Performance Systems International, March 1991.
- Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987.
- Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987.
- Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991.
- Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991.
- IEEE 802.3/ISO 8802-3 Information processing systems - Local area networks - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 2nd edition, September 21, 1990.
- IEEE P802.3K, "Layer Management for 10 Mb/s Baseband Repeaters, Section 19," Draft Supplement to ANSI/IEEE 802.3, Draft 8, April 9, 1992.
7. Security Considerations 🔒
okay this one is short but it's a big deal: security issues are not discussed in this memo. no cap, that's literally it 💀
8. Authors' Addresses 💌
here's where to find the authors 🦋
Donna McMaster
SynOptics Communications, Inc.
4401 Great America Parkway
P.O. Box 58185
Santa Clara, CA 95052-8185
EMail: mcmaster@synoptics.com
Keith McCloghrie
Hughes LAN Systems, Inc.
1225 Charleston Road
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.com📦 where this page comes from
- ietf: rfc1368 1992-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms