SynOptics Communications, Inc.
K. McCloghrie
Hughes LAN Systems, Inc.
October 1992
-
-
Definitions of Managed Objects for IEEE 802.3 Repeater Devices
-
Status of this Memo
-
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
-
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing IEEE 802.3 10
Mb/second baseband repeaters, sometimes referred to as "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........................................... 40
1. Management Framework
-
The Internet-standard Network Management Framework consists of three
components. They are:-
STD 16/RFC 1155 [1] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management. STD
16/RFC 1212 [7] defines a more concise description mechanism,
which is wholly consistent with the SMI.RFC 1156 [2] which defines MIB-I, the core set of managed objects
for the Internet suite of protocols. STD 17/RFC 1213 [4] defines
MIB-II, an evolution of MIB-I based on implementation experience
and new operational requirements.STD 15/RFC 1157 [3] which defines the SNMP, the protocol used for
network access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation. -
2. Objects
-
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [5]
defined in the SMI. In particular, each object has a name, a syntax,
and an encoding. The name is an object identifier, an
administratively assigned name, which specifies an object type. 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 OBJECT
DESCRIPTOR, to also refer to the object type.The syntax of an object type defines the abstract data structure
corresponding to that object type. The ASN.1 language is used for
this purpose. However, the SMI [1] purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly made
for simplicity.The encoding of an object type is simply how that object type is
represented using the object type's syntax. Implicitly tied to the
notion of an object type's syntax and encoding is how the object type
is represented when being transmitted on the network.The SMI specifies the use of the basic encoding rules of ASN.1 [6],
subject to the additional requirements imposed by the SNMP.
2.1. Format of Definitions
-
Section 4 contains the specification of all object types contained in
this MIB module. The object types are defined using the conventions
defined in the SMI, as amended by the extensions specified in [7,8].
3. Overview
-
Instances of the object types defined in this memo represent
attributes of an IEEE 802.3 (Ethernet-like) repeater, as defined by
Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE
802.3/ISO 8802-3 CSMA/CD standard [9].These Repeater MIB objects may be used to manage non-standard
repeater-like devices, but defining objects to describe
implementation-specific properties of non-standard repeater-like
devices is outside the scope of this memo.The definitions presented here are based on the IEEE draft standard
P802.3K, "Layer Management for 10 Mb/s Baseband Repeaters." [10]
Implementors of these MIB objects should note that [10] explicitly
describes when, where, and how various repeater attributes are
measured. The IEEE document also describes the effects of repeater
actions that may be invoked by manipulating instances of the MIB
objects defined here.The counters in this document are defined to be the same as those
counters in the IEEE 802.3 Repeater Management draft, with the
intention that a single instrumentation can be used to implement both
the IEEE and IETF management standards.
3.1. Terminology
3.1.1. Repeaters, Hubs and Concentrators
-
In late 1988, the IEEE 802.3 Hub Management task force was chartered
to define managed objects for both 802.3 repeaters and the proposed
10BASE-FA synchronous active stars. The term "hub" was used to cover
both repeaters and active stars.In March, 1991, the active star proposal was dropped from the
10BASE-F draft. Subsequently the 802.3 group changed the name of the
task force to be the IEEE 802.3 Repeater Management Task Force, and
likewise renamed their draft.The use of the term "hub" has led to some confusion, as the terms
"hub," "intelligent hub," and "concentrator" are often used to
indicate a modular chassis with plug-in modules that provide
generalized LAN/WAN connectivity, often with a mix of 802.3 repeater,
token ring, and FDDI connectivity, internetworked by bridges,
routers, and terminal servers.To be clear that this work covers the management of IEEE 802.3
repeaters only, the editors of this MIB definitions document chose to
call this a "Repeater MIB" instead of a "Hub MIB."
3.1.2. Repeaters, Ports, and MAUs
-
The following text roughly defines the terms "repeater," "port," and
"MAU" as used in the context of this memo. This text is imprecise
and omits many technical details. For a more complete and precise
definition of these terms, refer to Section 9 of [9].An IEEE 802.3 repeater connects "Ethernet-like" media segments
together to extend the network length and topology beyond what can be
achieved with a single coax segment. It can be pictured as a star
structure with two or more input/output ports. The diagram below
illustrates a 6-port repeater:^ ^ | | \ \ / / \ \ / / _____\ v /_____ -> ______ ______ -> / ^ \ / / \ \ / / \ \ | | v v-
-
-
-
Figure 1. Repeater Unit
-
-
-
All the stations on the media segments connected to a given
repeater's ports participate in a single collision domain. A packet
transmitted by any of these stations is seen by all of these
stations.Data coming in on any port in the repeater is transmitted out through
each of the remaining n-1 ports. If data comes in to the repeater on
two or more ports simultaneously or the repeater detects a collision
on the incoming port, the repeater transmits a jamming signal out on
all ports for the duration of the collision.A repeater is a bit-wise store-and-forward device. It is
differentiated from a bridge (a frame store-and-forward device) in
that it is primarily concerned with carrier sense and data bits, and
does not make data-handling decisions based on the legality or
contents of a packet. A repeater retransmits data bits as they are
received. Its data FIFO holds only enough bits to make sure that the
FIFO does not underflow when the data rate of incoming bits is
slightly slower than the repeater's transmission rate.A repeater is not an end-station on the network, and does not count
toward the overall limit of 1024 stations. A repeater has no MAC
address associated with it, and therefore packets may not be
addressed to the repeater or to its ports. (Packets may be addressed
to the MAC address of a management entity that is monitoring a
repeater. This management entity may or may not be connected to the
network through one of the repeater's ports. How the management
entity obtains information about the activity on the repeater is an
implementation issue, and is not discussed in this memo.)A repeater is connected to the network with Medium Attachment Units
(MAUs), and sometimes through Attachment Unit Interfaces (AUIs) as
well. ("MAUs" are also known as transceivers, and an "AUI" is the
same as a 15-pin Ethernet or DIX connector.)The 802.3 standard defines a "repeater set" as the "repeater unit"
plus its associated MAUs (and AUIs if present). The "repeater unit"
is defined as the portion of the repeater set that is inboard of the
physical media interfaces. The MAUs may be physically separate from
the repeater unit, or they may be integrated into the same physical
package.(MAU) (MAU) \ \ / / \ \ / / _____\ v /_____ (MAU) ______ ______ (MAU) / ^ \ / / \ \ / / \ \ (MAU) (MAU)-
-
-
-
-
Figure 2. Repeater Set
-
-
-
-
The most commonly-used MAUs are the 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 being combined into the 10BASE-F standard as 10BASE-FL). The
draft 10BASE-F standard also includes the definition for a new
synchronous fiber optic attachment, known as 10BASE-FB.It should be stressed that the repeater MIB being defined by the IEEE
covers only the repeater unit management - it does not include
management of the MAUs that form the repeater set. The IEEE
recognizes that MAU management should be the same for MAUs connected
to end-stations (DTEs) as it is for MAUs connected to repeaters.
This memo follows the same strategy; the definition of management
information for MAUs is being addressed in a separate memo. -
3.1.3. Ports and Groups
-
Repeaters are often implemented in modular "concentrators," where a
card cage holds several field-replaceable cards. Several cards may
form a single repeater unit, with each card containing one or more of
the repeater's ports. Because of this modular architecture, users
typically identify these repeater ports with a card number plus the
port number relative to the card, e.g., Card 3, Port 11.To support this modular numbering scheme, this document follows the
example of the IEEE Repeater Management draft [10], allowing an
implementor to separate the ports in a repeater into "groups", if
desired. For example, an implementor might choose to represent
field-replaceable units as groups of ports so that the port numbering
would match the modular hardware implementation.This group mapping is recommended but optional. An implementor may
choose to put all of a modular repeater's ports into a single group,
or to divide the ports into groups that do not match physical
divisions.The object rptrGroupCapacity, which has a maximum value of 1024,
indicates the maximum number of groups that a given repeater may
contain. The value of rptrGroupCapacity must remain constant from
one management restart to the next.Each group within the repeater is uniquely identified by a group
number in the range 1..rptrGroupCapacity. Groups may come and go
without causing a management reset, and may be sparsely numbered
within the repeater. For example, in a 12-card cage, cards 3, 5, 6,
and 7 may together form a single repeater, and the implementor may
choose to number them as groups 3, 5, 6, and 7, respectively.The object rptrGroupPortCapacity, which also has a maximum value of
1024, indicates the maximum number of ports that a given group may
contain. The value of rptrGroupPortCapacity must not change for a
given group. However, a group may be deleted from the repeater and
replaced with a group containing a different number of ports. The
value of rptrGroupLastOperStatusChange will indicate that a change
took place.Each port within the repeater is uniquely identified by a combination
of group number and port number, where port number is an integer in
the range 1..rptrGroupPortCapacity. As with groups within a
repeater, ports within a group may be sparsely numbered. Likewise,
ports may come and go within a group without causing a management
reset.
3.2. Supporting Functions
-
The IEEE 802.3 Hub Management draft [10] defines the following seven
functions and seven signals used to describe precisely when port
counters are incremented. The relationship between the functions and
signals is shown in Figure 3.The CollisionEvent, ActivityDuration, CarrierEvent, FramingError,
OctetCount, FCSError, and SourceAddress output signals defined here
are not retrievable MIB objects, but rather are concepts used in
defining the MIB objects. The inputs are defined in Section 9 of the
IEEE 802.3 standard [9].+---------+ |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 Relationship
-
-
Collision Event Function: The collision event function asserts the CollisionEvent signal when the CollIn(X) variable has the value SQE. The CollisionEvent signal remains asserted until the assertion of any CarrierEvent signal due to 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 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. The framing function strips preamble and start
of frame delimiter from the received data stream. 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 is cleared upon the assertion of the CarrierEvent
signal due to the reception of the following event.Activity Timing Function: The activity timing function measures the duration of the assertion of the CarrierEvent signal. This duration value must be adjusted by removing the value of Carrier Recovery Time (Ref: 9.5.6.5 [9]) to obtain the true duration of activity on the network. The output of the Activity Timing function is the ActivityDuration value, which represents the duration of the CarrierEvent signal as 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. The output of the octet counting function is the OctetCount value. The OctetCount value is reset to zero upon the assertion of the CarrierEvent signal due to the reception of the folloÐÜëéî}îåjYiÝËÈÉÌá[LKUceøÙÖÛÚÛÔÒâVEAH]fÝÏ×ÜùeZVT[eOMZwîY\îο½ËSBIÞÁ¿ÅÎ^FCNkèÝÒÁ½¿Èì]SOPDGQkîûùhh`\PHGFFDENoß×̽¶¶ºÁÛ^SZùÜÛáÞìwòÙÔþPKRX\]\fxéâëéþea`g_I8:fº¿v24¸¸»¶¶Ñ ,4G_½£©¸>4J6/^10<;:3<âÏN90/>ËÅf¼·¯´·¦©ÏHOί°½Õ^QC367* %-SÙIG@KÎÇÎ͸®µÑͨ³É_ÌÖPßÏG:7><.,,$"/8)%*?é>>úǽ¾È³¢£§«ª®Æµ§¦©¬¯ÌHTâï1+'!&$&'-DLH<e]AKOÚ»¸²±À¿¹¾ÍëÀ¶¯±h\®¦°ÁêXV;1=B2'#(+47H]K\Þ±¼Î^䮬±¿ÊÐþżÌËÒàü*(OÅÍO6/:CPf¼R74:eFí×Ⱥè㯫ÅçU[½±¯·½¾ÉÔå[dMM<,$.UÏÒO0*3=M|ÌÍHEF̶¾¶³®¸´ §Ïä>Vĺ¿ÇÚ;DM:67/.4(%6ÙÁ¾ÅN9;_¾¸¾ÆÏWJÖ½¶¶±¯¾«®V=8_ÍÃ×_T>72252./:/&4Ͷ½ïêÊĵ¬¹¾Ëê¾¾¿¹°°Å]Ô²ø834CHRJB;8ESIK?;:K>'6¿±²¼Æ×Ϻ¯®²ÄýÁÃÇÇÈÆÚ<f½;*-/<L=;<45LoãÕåtjÔÌCí¨«´ÅÐÌåϺÃc?HZ\IOVO:Iµk31/<üƼÀyKͺÙcXNC>_ÌôO¾¯¶½ÙZägîËÍÏh==IRVG=6¼·JO=Eåż¹ÉkýÒÌÌÄÎkU=@MD9?ßÖñßêÔÖnì¾Â×ØØÞYTLM¶¿A<>H]óÆ¿ÌÑjöÛÎÀÓW@:=?IRHK[ÍÎìÓäã[êÇÝÚÌÊÚÕäg¬dEDrÑÍÊÎå=22<@{ÒðWAJL??Wåóì]ÝÀÀÄÕÍÈÅÃÌÄËÍÛæÇÁÈæE?IbûaY=8IdP_ïñkVJJE>H]ÚÍhKoÐÌÀ¾ÂÁĺº½¹½ÍÏWMlãK=??JNE99@IOQlSOíÈÈØúÑÌ×ïPQùâѽ»½¶µ½ÒÏÃÓVDS_KC:;=?D74:>LþÝÜÊÃÃÀÇÚÇÅËľÇÙ×ëÎÂÃÊí`hgLIHDELK=88:BaÙÝñeçÈ¿½¾½ÍäÎľ¿ÍÔßÎÞHA;::;@IPTfÜĽ¼ÂÞ^GLláìfßéÞücÚËÅÆÃÏqU_õÝãQ?CNB=AD?PrÍÁÉÁÉ÷ë×ÅÎäâ~ÍÔÞÕh|mMHLhÓ÷ëxep|ßÞÈÖwbFHWZCBF@LáÑÓËÀ¿Á¿ÂÇÉÚ[cøMKIH><@hÇÏÉÁÊÈÑvðímöZPPþëG9;HJNcÑÇÄ¿½¼ÃØäÏËÒêØÔààä[?>BCD>=HHOçÊËÑçãéæÒÜoLGXßÜ;¿¼¼¼¸ºÊZV_U^GLI>I<8=AEESê÷kkÛÐäl]bÍÂÅÆÇÓÛϾ»¾ÌßÐÙûvãÕãRHYdIA<89;<?DEQñîÛÙË¿»³´¾ÇÊÏØs\_SQ\ÙØTXúÙÑÞÝØeJCIONPKKQGRãíÝÜáîïßÒÆÆÆÇèlæÜÍÐáããx^PJUZScnïoHDCHWîËÝßÎÞkàÔÖÐÐÜvnrÚÉÊÏônúèTVfMLNOKHMlÖÔÕÓÚýZY_bwÞÓÙÞ÷SbÜÓÖÌËÍÓnbæÕÏÖiXXPWYXTMJHJJKPcÞÜék\ã×ÜǾ¾ÁÉÒÛÖÙÏËÓìöWBDERnor_LPWOXSXbSPT^oêéØÌÑÝþà×ÏÄ¿ÉÎÑíìÐÇÌÎØÙêKEDGKRM@EDDIFPnómp|ìåÏÅÄÁÍÚÏßÒÌÍËÈÊÏú]hxW[î^SLFJNDJîÔßb^]_Yl}ia^oxÞÔÍÆÇÛþqníØÌÅÁÎm]XVTMR|ëlu[LNV^kìxlðkqÛÑÎÓögWY÷äÓÌÓüMGGSdßÍÌ×ìúýâfÿÞÜãâÜüc[ríÞÚêxlZS]lgSLNWXeÚÏÏÏîQJ[g×ÇÉÇçcg`tm}æØÔÓÔÜðf^_m]]k_\ZqÜÛoWQNN]ùvykn\ViïÒÈÁÉÏÔÕÙæééåïoYTZWLQlçòþo_\iððm]^mjïßÝðqhLMnÞÎÍËÍÝÛã~äÙÓÕÖÔÔæicQGJXSOOPRQQ]aekW]ixßÍËËÎÜÙÌÉÉÊÏÕÙãsyoer^[g^OOXSO\ah`\YMYfgc_]kâ×ÔÑÎÎÖà÷éÚÖÎÍÐÐ×ñîæåéwngjRMRLIKOTYZ\jèÞÞÝáþnl]hçÛÝæäÜÔÎÐÑÏâlkofwwýêãrW\jýf]YW]ccgíáëzlb^ignæÙÒÏ×ÚØçêÚÚí_SZhgkvoa_ga^boñíâêo|ýûìÙÒÙâç÷uyëáøoiuwZYúäÝwl|Z[WV^jü÷qj{êççëéäïïîó÷ÝÏÍÖíha]WbèÜâÝæìñùðæòWQRPMKUiiiníãôns~þææâÖÐÔß×ÏÔÝíxr`jîæäû}|q`_üåãïj_]RMMLIEGSfa}ÙÔÏɾ»½ÁÂÈÎÝnWJC<;57¿¿XK?Amu^ÜàÝëìphо·¯v1Îä»´Å¿ÃÇÞàúyõPD<72..0.24;G_[TÏʹ¶¸¹¹¼¾¾»º¹´©§ª°½ÏâcbRA80,*(''(((*+,/27?OzÍ¿¸±®¬«««««ª«®±µ¸¼ÂÇÈÏã\MHEC>=::856677789;?DKW`àÜâÚêbXMMNUHHzeÕ»´¯®´ÄÆÀ¼¼º¾ÏÛêüúÙÑóäþ[MIG?BJOcãî|VRMK]göÓËÓèçhX]VU_ÑÌÍÑÝùVUJGOcúìàwLD>:9>MêžÀÄÃÏë|èÞÐÂÄÏé_ORÿÜɽ¸·¸¼Ìy^Q@>?>AGHEFLLHOTQZ~ëãÎÆÉ¿ÅÌÒÖàÝÝÒÉÄÇØÝøK?>=<>BDLYXMKHEJ]|ÙÆÀ¿¿¿ÂÅÅÉËÍËÌÏÍÙ`C7-*.8NÑ·¯¯´¼¾Æ×ë]LGC>;989<??EOY^grpëÕÍÎÏÌÑÚÖÔßÒÌÏÍÏÚàÔÎÔÜâòfjna]`cY]XOOLHHMS[xäèìäçâàÞȸµËD0.4Eܾ´®¬²¼ÍYA73410268:?KTfßÏƼ¶±¯®¯±¶½ÈÚþ^VOMJC;86:>?FLVUTNLO^öÛ̾½¼ÁÉÒÔÈÄÁÂÃÅÌÔÝ_ML_ÛM.%"(0AÚ¼±®±¹¾Îì^MNHCBDAFLMKGJQbøÞÓÊ»¹¹»ÁÎécPLJJLMX_cwõvgdeeg÷ÜÚÝÝãéózjZUOTiëéèá×ÕÜãoZ[þ×àJ4-/7LϹ¯¬±ºÂÒâ]UOOOOU^VRQMSTTV[iåÌÄ¿¿ÅÎÝtVNKIFILJMMPXpzÚÜsxÿîßÓÌËÌÔÙàìnmýàÐËÉÈÈÇÆÊÕûgaþÜg@/*),7Oɸ±³·¼ÆÖiOLMSY[\]]XPOMMR`æÔÉÅÀ¿¿ÃÊÑáqc^\XTY\]]lðßÔÏÑÝú`XRRQSRONOLHHFGIO_òÎľ»»¼¿ÃÂÀÀÇæI;8:@[ξ¹¸»ÅÜZG>;99:<?HR]iõýìîìÛÙĺ·¶¶º¿ËáeUKFDBBBEIMQZkêÞßÝÚ×ÑÎËËÓÐÏÙØÞöbTLFBBGOfÛÏÌÉÊÌÍÕôYIDCCHVþϽº»¿ÂÊÏØéiOHDC?>>=;;>?EM_àË¿»»»¼¾¿ÂÄÊÙève\XRNNXg_XTY_pêítþùpjv÷o^TNKMT]c}é×ÊÇÇÇÉÌÚiMA?>FPxÐÍÀ»½¿ÄÊÎÍÑåükYRONLF@=::;?J^ã×ÏÌÉÆÇÌËÐÞçãâìðøryïàÛÚÕÔÓÒÓÛëïîzwztg]XNKFDEIQ_þæÖÌËÏàõYGDC@BKaàÍÁ½¼½ÀľÀÉËÐÝìüoaUKHD?<<=?EKWjxöÙÍÊÎÏßxýxlfõåÚ×ÖÒÝèçßÛÚÞîþcmn^ZNTTU\WY`lúÜÓÉÅÀ¾¿Å×úUIB?DCGLQXYZYeléÙÏÊÐÕÛ×Ò×ÙÞØÖØßÞïjrsyyíçãè|_YXNHD@?CJTeýîÙÍÉÄÃÂÂÄÆÇÇÇÊÝjSICA@>?ADKP_â×ÏÎÍÍÏÔÚäèëèÝÐÍÎÒÚÝßßö_VONOZ_YROOTYVZsíßÙÕÔÎÍÎÍÍËÉËÓÝbTJCD?BMUZ\cmzñïéíàÏÆÃÇËØèïeWQNLIJO[akúyòëíçîò~õæÞÑÉÄÀÀÁÄÇËÚësi[ONMKGDBBCEHNSQTXauõáØÎÉÆÆÆÉÎÓàóûÿzoeWSWZ][[_mêÖËÆÇÇÊÎÔÛçìëv^SOOQSW^\RQNLJFFIN]xå×ÎËÉÇÄÅÆÆÈÎÕÏÏÕÙtdTQSLNONONMOOV`ÿíèÝÔÐÒÖÖØÜÜÝâïwdZ_^YYXNQXdåÔÍÎÑÙÝÝÜàîýe\dÿüàØÙßþ_TNNQVXRPQWYhëàÛÚÙÙÜØÓÏÍÍÌÍÏÕÝæ÷la[RMNMLPW_gmp~phvêÜÕÙÝÞáäæåít_ZZ]d|æàßêþýxdghhu|lb_erêßÙÔÔÚñ~_m|ýëfszjimøíìótvwqïêííììèÝÞßæééùmd[TRXSaòzvin{îçäãßæêçíï÷}mgeccoïåßÜÛÜæòòÿmaac_^a`^lðåßê{fgw÷çßÝÞèñïïêéçìóøúöyrpfc^^dnmnoýéø|fdkoy÷èãßãèäáßÜÜêüqihc_^[XUX]gùôõÝßÚÓÙÓèsîêí|e]]^fýîéïvgffglwwtùûîßÝÝßåèuûýüî÷}nmokib`hsöôôzyûþïî÷nk}ìßÚÙÚÞãêú~m^XSRPQRW]gùêäÝÙÓÒÓÔÕÓÔ×Ýêøvnhq}ld\XWVUTWNNSV_bmñÝÖÒÏÎÏÑÏÎÏÔØÜæìx_]]\Z[]^ZY`cbb_`jfìéàÔâèÜÞÜÜåàî{þýzkmqyööóüuvspzÿna_^behbfglùöïæëúñwóztroîëåãäÝßáßÞÞÛØÖØÝìûomi`]]]YSRXXWVTY\hùíìââßÝÝÚÜØØÜÞàäíø}îßçprqïó}}vpcda[[[_imhgigimpvþùöëçêêìô÷}óàÝÚÜÝáòå~xõlñpg÷éêèäéú{onkiba`bj`bedfhfejxõûoxìuøãåááÙÙÙ×ÙÞçêîoa^ed_cbdhcirüôûxpþõòçëòûþîývúêëïãâîô|vtwwsxzø|tz~ÿþùùûïofxÿçïztahnùj^vkcliqlikõåßÞãØÖÜÓ××ÖçßåÝe_idm]QRPT\^^W[Y_óøèíæÞâáêëôäÛÞÜíéêîç|ùp_io~øýðïôëôþyóòpüàâêón~ððéðyaX[ZWUTYSZeaaevôåÞÚÓÑÎÎÔÒÏÙÜèäëwrnomhc^[VTX\`e]^[^wûèÞÜÜÚÞßÞÝØáßÞyñzd]flfnjotipnjj_gowåãâïöàäàèïòý÷íõekaddoyoêüyk}åæÜæôéïojvyos{wikgum\bji{ñzîìøðíîñçü{äãÞãÛÜùíãìïâüjl{gqï|kokXVUYV[noozô{}ëyàÚÜÞØÞúêñeøØâììèøzõx_ihairzicûf_ôtúym{ï~êëãêmïìêíúþnryqvüôíìüov÷k`mïìåî{ù~éçbnï{ñvjkix^`ncvþèîåç~÷üöìõðÙêõßåàéêåßõûvZ]Z[aV]_c`j]gëëÝáåèåæââãêÿtno|û÷õørghnr}ðïïìéëìêîéçëêêêëëçóÿslh`]ZZ__^^]]_goýnòéçßàÝÜÛÙÚÜÛßÞãñõqkidbbbiovw|pmqöðíãÚÝêõj__iZef\_úèààæðnggffefgmwùïíáÚÔÓÔÖ×ÙÜÜÛòìäïva[XXXWYWYYXVWZ_oìÝ×ÐÏÕÛîcRKJIM\äÌÈÉÌÏÕÒËÇÆÆÈÍÞoWOKOØ=$.<FnÕȾ¹¿ÌyÙÒJÖÙcwéç_ÚØëWOcNN2O½¸¸NܵÃËÝõĺ½ÏzYTLU`~?.4-)+(07:IbƵ·ÇÎØ¿µ®ª¦£¤£©¯¶ÌLA884/.++)()$",/6FFIÓÏØǯ¯µµ¯²¯´°¯¶®¹ÏÁÌéÙÏÍW}d7:2)&)&(-+-0BHQ×¾º½¸ÄÄÅÀ¸¤¥ª¨«³¿¾¾ÏèFCJ6-/3,(-/0,.25JnjÌ»²´°²³¯±³µ´µ¹ÅÐßYÛÃP?4.;?;CHCCB<9:AMξ9;ça¶³µº¸®ÊÉ·ÏÔ×eçÌÊT=443>Vò·¿å}Ñb?;?E<>ibZϺ¾|¿²±¼Íƹ´¾ÈÇÉÏàmL?56740/220/-/89>HSóÑ»»µ¯°®®¯®¬°³®²·´»¿Ìä^J@;@h_<-**,3@OMMXNOMJHB?BB?CJUM\Þǽ¾º¹¸¸¹º¾¿Ç¾½ÄÎ×ÎÇÎÎÍkejNOOJXICE?FBGLq\ôÐÜåõàXWÚÍËÃÅÌËåZRRÞ×z</+/Faùµ²¸¾ÒñmO@?NDFKNVLRx×ÎÜÑÏÔÈÛÑÂÃÐÙÌÉÍÙéõÖauë\jXZKIOSQTVRY]d`[emòÓÝßÑÜ_m×ÎÁÈÏÝãÙtSHLW^ÑãC768>è¿»¸·±µ¿ÎvTEA;9<?KLShEEWjW[ØÏļ¼º¼½¿¿ÁÂÍÙÚùhZY[L?:?C=:;?>BMMsÛÕØÖÏÖæÛľÂÁ¶ºÎËÎÑÍõ]U]ÑÉØF40/>TáÁ¿¾ÂÌÖYOJ>?EIPï|]êþøëØÊÍÉÇÏÛÔÏÌÆÌÖðMEAA?>?>>CRüâÛÃÃÝÒÇÈ¿ÁÇÍÅÆËØoùìêllàî[rlOIDCFEKYT?5.-6HƲ¬ªªª®µ»ÁÔêpULHK??D?==9:=?N]mÑÇÉÀ¾ÍËÚöêÿèíi~qüñìÛéßÓëéênáñßÍÍßþrOIIDEJRaüüìäÙÕÙéáÒÕÏÑæoSJ?CnÏ¿¸´µ¼Èí^QA<<=:87=AEQN]bnéÝÖÝÍÁ½¹º¼¾ÂÈÎýøÿe~gnhh`S^dVQO\ffU[}SO_PQSNJS{ÜÚÔÌÇÎÏÉÑØçôYMKGF@IWñÍ¿º¹··¼½ÅÐädZSONJBA@ADFFDIQWýêÝÚÕËÑÔØÛÚßêìåïxbb`gùâÛêÞÛuëíab\Zkz^XhõáßÕË×ÖËÍÈÇÉÉÏÞ|K<720/4;IeÑÁ¿¾ÏÁ½åÙÓØnÔÏîÏÉÊÓÍòWi]RSÞÕÕÀÉåKE:68<BBV[[VeVRüßƺµ¹»·¿ÏÔßoïÈÒâßhJHE<<K\YßÙýnWJAALOlÑÒï×ÊÏÏÊÈÄ»º½ÄÆåQPF==EGJZíÿnpg_kmcØÉÐÎÃËÒÕÜkKRPJKKIHSTOY}gbwl`oÜÔÉÄÆÎÎÎßÐÉÓ×ÏÏìje[QlßómiVHC=9;@HXéÍÌÅ¿ÈÒÌÊÎËÆÏÎÊÛ^E=99?DDTwêæØÜnÙÓÖËÀ¿Á½½ÊÚÞjXUYMLaQFJJCFLHJV^\zß}rÎÎÓÎËÖÔÏÌÌÍÊÌÊÉÈÍ×Û_OL?>@ADRìÛÑÇÈØóxbYYfcmÜù`ùfLKJMVY\óÒÍËÌÌÍÚ×ÏÏÎÍÑÑØÜiY_RRRSR\]OMQW[_eddäÝèèÙèsðÙãðÕÐ×ØØ÷ùdRbVKPTZmbif`ìÜÝÔÈÅÉÊÈÌ×ç{ýñçyjybVRKIGJCAKMRZd\jvëÕÚÛâÛÎÏÊÉÈÊÊÎÝÛÕÕÙÔÏÓßènVSLGFEAAB@EKTeóÙÎÈÈÈÒàØÛß×ÚßÜÕØêáènqûodùæñû^Z_]ZTZjwsôøig_rh}çÜÖ×ÐÙÝí~òg_Y[fX[hiýîööxÜÛÝÑÝÚ×Ô×Üå{zîöfYWQLNV[níúvjh^V^ceqéÜßÚÕÏÔÛÞááþlwkbcc\[\[\[W^ÿßÚ×ÎÍËÊÊÉÍÏÒÖÖÙþ\XKFFBDDHOOMQVQWdoïáÛÏÐÓÎÌÑÛÓÛêòßÒÔÒÏ×êb_[Vhðzvn[X[W^øçÞÒÑØÛßètcb^\Z_aee[^XNOY][p÷ÛåäÖàà×ÐÐÌËÒÔ×æ}lc\^\W^h^]_ilsïzêâèãÛÙþk~wrjåÞáÜáúcSMLMPWamwöúíàÕÓÕÓÏÎÑÕ×ÙÝäæw]USQOTTSXXXYX\adclèÚÕÑÎÌÌÎÓ×Üæ~z|ngi^[`tpmvôîìèÿyrÿzgbzcdvwwop{þ}kgoideecoþtüÝäìÚÚØ×ÔÚ×æôæäÛÞèìs]RSRLNTVZ_c_jpsúëåâÙÓÕÑÏÚØÞåó}ïwøéßæôõwmi^ZY^[V^a__jjoõèèäÞåéèîxkfek~xlxyw÷îéêàÛÙ×Ö×Üéývl~ú{öyhla]][]\^qcxúls{ìtxxtnsçÜÚÝãuaôêøêïvï×ÔÚÚÝÛßz^]]]`uiof[\JKPKUafùæßàæ|öâÓÉÄÀ¾¾ÄÒôd[ZUU[bb`OCDEDKPXvâÛÚêóëçÜØÒËÅÃÅÉÕìs_XRPVdme]USUUWbõäÖÎÔÜáèïïäîðâáàîöi[\URNNNOYZ^qìâÝÓÏÒÎÉËÌÉÌÎÏÖâôaXTPNNMMLMMLLR[xôæßÛÕÖÖÝâÚÏÍÌÐ×ÜqtdX`U[ophcc`[X[brîâÞÛÚØÚÞâëííÝÙßèïvd]\MNYYeid]\_n~îèåßÜÜØ×ÞÝàéö~ý}|÷ttkbddkjwýìï{ýú÷ùûy÷çâÜÛáæï÷}olhee^XUWUX_akox~îèâÛÛØÖ×ØØØÛÛÜâørp`ccekhkkj^]^]bafbpðïïñëâëïèséãìãgjïïìëïïôöü{nfikmokfmëâæêãÞáçêóîæèqmk`gda\_filfgcgjoxzðêääçßÝÜÖØÚØß~la]V]tsxnihejwõñøèéëö}þùéæàÝáçê÷üúüùðîq^]XVWV[X_eh{ìàæèèëçßÝÜÛÝàßãîöîìö÷ðyfg_ZUSV[_uõíÝåìàëâàðçÚØÛÞéïqedca^beb`^\_b`]\boðçãÜØÙâÝÝåçêéíõöþ}ÿû÷üû}zðôòèæáìò}n~ojikmka[\[^`babc_koglm|ôêàØÔÕÖÕÕÕÓ×ÛÞäåîýyj_^_]_eggha^[\Z_kqöíæçìïï÷úïéäÞáæèî|liddciyùîâêúïeqpuìfrêßÜâçîñ÷÷ö÷özxuid__`^`bienu{óñíâxîÜÛØÜåú{lkjdjoýòæÞãâîÿxkhcfglyù÷þ|úîèäâäèéîýøûwigaddfeffbaeda`g{áÖÑÍÍÐÚðgWNMOYnÝÖÙáþsÿàÒËÆÆÉÐÝnWPJGEEDFJNUZbwçÙÒÏÏÎÌËÎÎÓÏÓØÕïòëøònf[WWVXVWURNLLMU_}ãÜÕÒÒÖáïjZKHGKë¾³µÆlNTâ·´¶¼ÇØ|UD920037:<=BMfßÏÈÅÁ½»¹¸·¹º½ÃÉÓågYQKJH@>@@BGHLWZY^sûnîÔÌÇÇÃÂÆÕlWH>:77<]»®±ÃðiÚº¶µ·»ÄÍáX?4.-.0379?I[ÞÛÐÌɽ¼¼Æ¹¥¾¿ÖÝÅÝTYID=50?CDÎ.$ð^ÀºÝÆǾÃÎÊÐÕÏoT\HNQ9=?;MBKViÍÍǼ¾ÅÄ»´®®¯±µ¹¿ÊÞ]H=8711.+11./122577@HGiÝÒƽ¹µ¯°²±°³³¸»º½ÃÆż¾ÈØÞÔóNCDGF<:BLCLenóbHCD=:85<]Í\<98;W῵µ³¹¾ÂËõRITMOVRêÑÏÕËÂÀÀ¹¹»·½ÆÇÌÊË×^MQB=K=9><??>>ABBE]èßÐÔÌ¿ÉÑÌÇÇËÅÁÁ¿ÆÏÔtPI<:TïH.&&+2IÒ»³«®²¸Ç×ß_NJHFJBLYfn|ãØËÄÊÉÅÆÍÞÔëtXGMKDEEGIOLNoçÚÕà{ðßßËÄÎÌÔmlkNumber of groups that can be contained within the repeater. Within each managed repeater, the groups are uniquely numbered in the range from 1 to rptrGroupCapacity.-
-
-
-
-
Some groups may not be present in the repeater, in
which case the actual number of groups present
will be less than rptrGroupCapacity. The number
of groups present will never be greater than
rptrGroupCapacity.
-
-
-
-
Note: In practice, this will generally be the number of field-replaceable units (i.e., modules, cards, or boards) that can fit in the physical repeater enclosure, and the group numbers will correspond to numbers marked on the physical enclosure." REFERENCE "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 }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 --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 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 }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 thBML?I[[gÜßîhx}Ï»·¾Q9;B^̺·´¯²¶¼Æz@85435:::<HOZñÒÁ»¹¹º»À¼¼ÂÈ×qROKA=968:8;CNV_m|ÑÏʽº¼½¿ÃÄÆËÉÉËÓàÞî__YQRLFED@^Îä=,*-7^ǵ®«¬²ºÊrSKHGCB>>?HN\\WXR^uoðÜÖÐËÌÏËÇÉÈÊÓÐÕÚÑÓÛçòã_[_MNPLQVOMOLJNMNM]ýñ~øçåÙÕÍÏν³·ì8/5CÖº¯«¯·½ÉZ=5/..//49=DSôéÛÓÌÁ½»º··¸¸»¿ÆÌù[OEA>==>CDHR_üåêvln~âðßÔÑÐÏÏßt_awúêßØÒßñ\\â˾ÂQ6,*3F㶰°³ºÁ×VLF>@DEJIEKXjïìóþoáèÙÇÁº³¸¼¾Æ×lVOQKGIFGLW[`aZQQRSXZbïßÜÔÐÙjde[~occníÝÕÔÑÛÞ̾ºËN;8@cĶ°¯±µ»ÅßQ>9401349<?HW`VcjÙÎÊþ»¸»¾¿ÅÍêtbOTQMOURKLMNOMKMOVúÑÈÁ½½¾ÀÆÏ×âïî÷ncWNLD??DPhmI7129KϹ¯¬®±¹¼ÇãdXONUYb]UOGEA@A>?GR]ëÏËÊÉÌÍÕØÜáØÛØÓßÛçßîku_^QJHWddoqtïêæÝÞèÛÛßÕÔÞæÞèççêÎÄÍn?4/19NÙ¿···»ÂÍÞcPHCDLQ]oqnzl]ZWY]úÞÎÂÄÀ½ÄÌÛlTMGAACCGKKMW]fìóïäÛÐÌÇÆÅÄÇËÎÔßúgg]ZSW_Y^\S\õÝÐÜU>65:JëÅ·°±µ»Ä×qOD??BIQR`úbei^]dùôâÚÑÉÄÂÃÅÌ×âxm]VNKNMMNNNORUV]b{çÞÙÕÓÎÎÏÎÏÕáìéíêÛÕÑÖÚÞÝÙÙÔÏçO=537>XÏÀ¾¾ÃÑèjYOHFFJLQgzïäââæïïèäÜÍÈÂÀÀÂÉÑÝïm\UY[ZYROOLRUT]RX^\djrxîåæév`XX]hüýàÛàÜÕÔÔÏÉÆÈÒpO?@IYÓ¾¸·¹½Éã_OHA>?@CEGNPLIKOUW\nãÙÍÃÀ¿ÁÆÌÑÙÜÝáßäãâââîþ}{mkf^^XTVRROOOMLMOW\uéØÒÖÕÕÏÌÊÿ¿ÆÒdF?>DTèËÂÀÃÏéjULFDEIMTbjminò÷mytÞÛÓËÍÅÂÈÍÓénj]Y[\]c_YWUTXYcknsdi|úòèÝÛêèüöììáßØÖÚâìøjn~ðÜÜámOD>>BLrÑÿÁÉÓßy^ULKOQWbùåÝÝáÝÚÕÑÏÍÌÊÉÊÍÕÚìjXPNMOOOOPLHIILTTX\^gi~øêßÛÕÔÔÖ×ÕÑÏÎÍÍÍÎÖßÞßÝØÙÛÜþYLDCGNaïÑÍÌÏüf]ROKIILNOT\tìéâÞÜØØÙÕÐÍÊÉËÎ×âôoj]fmso`[WWUW\b`^__`ahwòßÞÞÞæåßÝÚ×ÕÖÞýh`i{ïÞÖÔÝ{[MHHL\äÎÊÈÌÔão[VSNNNOQV[clwïîîêíèÜÔÎÍËÊÎÔÚßë|qkld`[TSORVY_`gwü{|îêÞÚÖÔÖÑ×ââwôülnVTWX\\gúìêr^UKHJNfÙËÃÀÀÅÍÒÚàèôse_dZ_oløxnf_]]benùíêóöüpnkmlowqojhfi|øöóöýou{ûíàÚ×ØØØÙÜÝÝâæèöri`ZY\_ijd_ULHIIMYqÝÍÈÆÆÇËÎÖÛßïokmmpokhhh_]_ainyý÷ööùxrtnlz{mp^dfbþbjîíêðøöïâÜ×ÔÒÒÕÚÞæîöþwe\UOORYbizó_[]WTT[oßÑÊÇÇÇÉÍÓÖÞïxg_]ZY[]df`^ZXXZ]dkxöðôûö÷÷ïìèëêèëïñìëñìêçæëîÿ÷ïíéëåëøûrvtqpcb_[WW]aqûôõuj_ZX\kðÛÏÊÇÆÈÉçjÎâêdRQ[ULYxÓÛÙlJG?@IhÍǼ¾ÊhJA?LiÎüÀÍæR@<CLýƾ¿ÇÒ_J>=F\ÉÁ¿ÃÌëVJ@CNøÎÆÂÆÔùYIBIM\êÝêZø½ÈûcOfÊÚííôcQZLKGUb×·Ág>caË¿àËÁÁÄÉÚíSUPEB>=<4;eMD:AïbM|ÆÉÉ¿½º¸¹»»¹¸¶±²´µºÈùOF@95434120.,*./6=?M_òåãÑû·²°±®®±µ·»¿¾¿ÂÄÅÈËÎØïp\adVZXU[nV?2/17>FJMIE@@DEDEKPV^i|óåÙÎËÃÀ¿ÁÆÈÆÁÀ¿¾ÀÆÊÕÛÕÏÍÌÏÚÞêømYPKJóÆd847Ca×ÊÉÐçfWQVSNSLCFnÏËÎßùêÞÕÎÕåua\`zêòeROR]a`UPTcm_okåíô׺µóB>Kåȼ¶´¸ÃÒÜÜæl]]lkQ=9KïÞTJB?CMdv{ÝÉÄÈÏÖÖÕÑÍËÔßw_QGA?AILFeµÂ<44>`×Ƽ½¼¼¾ÁÂÄÍÛÚÚÚÖC2MžÏ[D<78CP[_rÔÐÝ×ÊÁ¾¼»¾ÁËà\MOGDAE@<¾¾5/3=aÔËÊØàÛØÜÒÌÎËÌÎÓÑËK9Õ²®·Ï_?75>[b^g^LCAHh;¼¾ÂÒeZX`aYRL·ªT31:dÙÌÊÛYWfvítYLM^ûwgìË\9o³«¹ÕVD=IçÅÊ~SG?DXíÒËÊÈàH<;>EKO˳^36BÛ½²¯³¾Îß÷ÙÌß[NO_li^UZêK1=ϼÀóIA<;XÌÈß\dpÞÍÈÿº¸¿ÚL><?IKöÂN8<Gèɾ¸¶¿Ï_GJHIOOT\_Þ×àãØÍN;nÁ¹»ÍoXWbßÞeJ>AOeÙÈÇÁÃÓëYA9:?B@ïÉN?AMèȺ±°¸ÉzZaÜÎÍÓÜç}éôÞÚpZsï?6LÌ¿ÅÏmK@@ILKJJ`~âËÊÑÍÉÑoG:J×S:8DÝÀ½»º»»»ÄÖïðíìÞÒÐÚö\JLlïeWZPB;<DOgéçgNFKmÛâÞßÙËÌÌÐÔÌÎÝÎÈ]>=BOuÞÛááâÜÏÈÇãKDSÖÈÌÎÍãlqýéþhdYOPW[UKDEFBHSëÍÍïZyÏÆÆÄ¿ÃÌÖÔÏáa[dîÞÒÐ}YORdvnNDGKQWWiocdøßÝÙÚÜÝÛÙÞÞÖÓØì{xknóòíàëüd]VìÑÕÙÜÜêH<>HjØÊÈÎàqulòè{g_[VVp|zÖÐÛêèäÓånìéïûsiifcZT[zßÞÛ×Ýl[nëæg]ïâiK=9=VòØÄÀÀÆÕ÷mböÖÏÔ|TV`aîÕÑÙàßßðjuhRNMTmz\X|î~j^ûÚâÜÇÆÚfNMOPdmQFGVèÏý»¼ÀÌèréÕÑìL>98>PàÊÊÏß{[LLMS`oìäíxðÙÑÎÎÌÏÜÊ¿ÇÏêTLFCIPLI?EVwÏȾ¶³¸ÁÐßóùøfPB;9;>EN[dvq`VLHMbÝÎÈÅÍÈÃÆÅÆÅËп¶ºËaKE@<>OlXF;7:Jýɾ½ÅÖÛçrvlvsYNNU_hnåÐÊËØüZKJV÷ÛÐÐÞeRW`îÊ¿ÜÛ¶³ºÊjLC==PÎÒ>.-2Bæ¿··ÀÔøiSNNJHKP]ßÉÂÄËËÄÀÄÊà^YkúêÛq^OJMK]ÕÎG;̶¹ÌWG?;;}´Ç5-1Aë½²®°¹ÅÓxMD@<<AKTnÖÌÊÐÖÌÃÃÊìPLN[ßÏÛúXLJQ_õÑ[7Tº¶½ÞVPJ={¶ò4/:÷·°±·¿ÍÚôO;669?FL[ëÚÔÐÏÎÆ¿ÄÍçkzxÞÔöMEELfïëâØ\28ϸ¼ÑmMEÍÑ715BÞ½²®¯³¹¾¾ÃÜM958<A?DRkêåîòîÓÌÛä~húÚÐÛ]MLYüÙ×Ý××?/K¾·ÃôCkÀ>.3@\ãÁ´°±´ºÀÃÅÔqM=:=DMMGIR]WWgoèâæ}[bòÛçq[]æÐÇÄÉÇÆ^2=Å´µÆYIYUH?;<@\ÓÉÂÁÄÃÂÆËÏëRB>FOSNOYkzmnïÛÒÎÏÞkdhpjSN\þØÅÀ¿ÅÒñfm`äÙÓÕJ945=NîÒÏÐØísôàÝ×ÌÊÏî\\c[U\aôÏÌÒØÓÖÎÍØõWJBAGYîáßÛêyîáê÷ÛØäÝÏÈÚM=;=HlÝÞàíuhøÜØ×ÙÒÖïg^TMUkê×ÊÄÊ×ÞÜÙØávWJABNníëìñ{uüñoXOdÝÎÉÍçRJNcèÛÓÏÎÓãgaâØÕÕØõ\L>=COeïÓÌÎÛcqêÒÌÜì^OPWvìååìõþn^hôìåÜÜècU^íÛÕÒÞ}~éÛãébXeñâíupwVGFKNVfîßÚÝéæÝÔÎÉÉÔãúwskhkjhk_Y]_\]eùìrdrèãææp^cöÛØ×épãÒËÊÎÔÜkPKEA?BNVhèÜ×ÝÝßÖÌÈÍÛÞäíñi\jððþod]RMSVYagvïÜÓØïþã|ìîßÓâÏÃÇÒÜï`OLJFCDJPYnçààßîæÔÍÏ×ÖÖØÞòlbóàÜÙÜãybYURQMKQoã{\~×ÛoURYpÙÆÄÌÕéscetxna]akvwk~ýroxêäÞÖÔÜþ^Xeùîíîñûèáæîzxh`^bméÜÌÌ[?:>LpÒÈÇÌ×éäÚÚç÷ü`V]fkjgmonkilêÞÖæuþoósZkoðÏÎØÛÞßî{òôtt÷ÔÄÙH99?NlíìßÚàïïâÛÜïÜÔÚçñçùqemòûze_eýêíçàçtXOU_ñÝÏÎÚÙáxk`sð~LJµ×<48CVdÖÇÓxZ~ØÝÓËÎÍÓÚßÚÕääïðüdWLMRSWï×ÙìZJEJYëÍÈÌÓíihråÜÕ`?ůÑ@8=MoñÒÈÑüY`÷÷fkçÝzò~lwýïáæýldanðçÛÏÉÉÙeLDGNsÜÖÙÝùbp÷hjvdKyÄòNMhàÝÞÜÍËÒbQ^VKOþ×ÓÓÕÕÞbV_]STVPXjõÞÊ¿ÁÈØoSO[rß×ÓÛiOMT_lþî\J]SM^àÔÖÓçêÐÏêZajWToÖÎÌÌÍÎãZNLMKKKN]xÜÇÁÆÍÑß÷g\oßÕÎÐýXWRhkVTJIGAGuÏÏÐÌÖìãêj_ÿðùçÕËÊËÍÏÏÕëVFCADDHQSgÕÉÐÚÚÙÛõdõÛÖÎÏÙâøðÛäU^ÒH6;BíÂÂÈÇÙi\NKMRSVnÚÎÆÂÄÉÊÍÝgOKGDGMSNYçÙéòßÝ×ÙçéæÝÑÏÙèêØÎEe¼è,(>ø»¼¿ÜH?HONKLZuëØÌÄÂÁÂÆÍà^LG@IOVuï×Üûglòß×ØðX[ûéîmn÷ýe]ÙÂÒI73?Ö¹³¶½ßMACLT]bñî_XkÝÏÊÅÅÊÖtSJIKNZøâîv^VjÔËÎÖèùõôóæîo[UbéØì[LNrÕÊÌÖö_YXXKKUiäÝàóplmêÙÐÌÍÔìg`^]bdfkgWSmÙÌÉËÏÛèvmýsZNU÷ìeOGDKwÍÅÅÌáûhlúPKTxÞï|ùíïìÞØ×ÔÕãfWSSV[_côìnnáÍÆÆÌØÚæjde`[YciVMJO[jçÚ×Ù^PsNiÖTpÕÑÅÑúîkâíxÞÜÍÎe]YQMHMR^ïhÝÌâÊÂËÅÌòskSToiQñrJLKJ_îóú÷ç[erKgß^þÍÈÌÄ¿ËÎæVíÓwêéi\KJIKSKQú_óÝâÚ×ÒÞÎÌßÚðUZUKnë_|eRViôàÌËáî_QôêöåÜîûÐÒþÐÄ×ÿ[JQzNHMOEJTZá×ÖÈ¿ÆÏÕÚnuû\iên^g]]aüìèxZöî\l~oílYfxáÓÊÇÙ\M_ÚèXXcbYT\lÝèoÏËéã×ãØÏ×ãÜsM`~bôwNLIEKPZêÃÆÓÖí^RVYmÝÙØÏÉÓÍÓ[`ßÕÛõL<9;?[óÞÍǾ¾ÉÐÓÙúmscU[US~iZîèc^]RShêͼ¿Ïå=/1?m̼¼¿¾ÄÆÍXMhsM@ADHRYõÏÏÕ×ÓÎÌÊÂÁÂÌðYEAAAI_û÷ûþzfUGIQXlƱ¸M33BâÆ»µ¹ÀÄÇÌÏÓâ~K96;<?IK]âäìÓÎÔÎÈÉÅÁÉÙì]QMNcíÞp]ñî^NGIS[dÁ»X40:Oν¶³º¾¾ÄÃÂÍkG=:=??CHITðØÔÌÊÔÖÚçÙÌÚÜê^RYm~íycwÝ^ONQ\l{eÀ®Ð2+.AÔ»¶¶¶·ºÁÍâiJ?CDB@BHLSkÔÈÊÏØæêoaçÊÊÚlMGLQ_ëÙÒÊÍãwaYYUR¼¯Y-+1IÕ¾¸·º¾ÌÔÛ}XNILYSV^]dôÚÐÎÐß~]NS[lÓÒÙcNH?InÚ××ÎÅÆÖpac÷¿·ÍE52<RÕ¿»¾ÈÕóXROFB?EMoæÒÅÄÇÊÇÌÒÚ]QRMZzæÞæ\JEIVeýnsØÏ×ÿct~Û¼¼ãB9>Mßÿ¾ÄÔÞßqOKHDKISsÔÊÊÍÛä}dUNV^þàÝÝÎËÚlNHNUjòêáØæù\IGÕ½ÛG@GOéË̽¼ÀÅËÏÞsOEEDIW÷âÞâìû^XQROR^yÝÚÛÖÎÎÚìýziipøÝÒÐßQG]ãxSJJTlÜÏÊÉÎÍÌÎÛlOGGHIVwáÒÏ××ÙêïîwmÿxþêÝí\RQUTV\g}dhÙÍÔÞóêß~^lÜÑÎÔÞáíd_îââùYNKGFKZëàÝÏÉÆÈÊËÑ}WLMTWUSRRUg~slgrqjôÜÏÊËÖ}_jáÎÊÇËÑÙáxZLLQLJEEEObïÎÉÈÔèêáÝÒÚÕé_]Vcf][fwwjj`SZmïé÷yîÑÑÔËÙäàÞÖÎÒãépRHCDIQ^rëèîáÖÓÞÿhféãáÕÙífXVaxõçê~omle_[SWkÞÔÒ×ïûrbdiúÝÑ×ßì{òÝÙâül_[V]ójñÒñjTQXfìåÝÜàûhgaeoiguþåÒÑØí[OWc}åþ]UVVjÖÍÊÉÉÅÇÍå\PIGHNZ`eoíßÞÚÜSîÕ[y`YXêpSuÞÒʽÎZS?8<PñǾÍÌ»ÆâpgagÚê`L<35=Hß¼·º¾ÅzQGEMòÅÆÂÀÉê_QADSùá×èTF<4-+;Áª£§±¼ÜGEIB;EYPfØÍÉÃËÞr\WLQ\Z_ýììÏÒÑÌÇÍÙà÷gMJEO×@))6hµ²¸¿ÌÛèëõ~òäîéÏÜ÷ØÎÜìÜîjgYNHFEG^åöfihWSTVkêÙµn;MûÚÛÍÈÎáßÔÐÔySB98=HVtÚ×áüîÿeêáêÙÁ»º¸¸¿Þ]IEMKLJNU[:<eMBAbÓÌÞ×À¿ÂÎæáêëäßÎÆËÜcMKJKIKKAESeâÓż¿ËôáÍÚêíÆÀ.&¿£ë.*/5GɽÍUNOEQß×ÙÖÙ]GFN}ÔÕÒÎÏÝÙÍÌÊÕÏÇÃÍîXE>HÝ:%=¼¬¬=)#*Hǹµ¿ÊÏåìÊÂÑÞýH;:6>IOim÷îôöêwïÏĺ³¶ÁÝ]]ÕZ+5»¯´«©Q( #/KÒÆÊØùÛÎμ¿ÙSD==?IföÞÌÆÏ×íe\dnä¿»ÅrP|J*4»®¾Àæ&&.:[ÔÄ¿ÑØËÃÀ»»ÑH94688@LéÌÄÆÌÑÙðhÛçÏ¿»ÀÔÎB(:»¯±½üR¼F),.5Aп¿À¾¾Àº»¾áF==?=>GOaäÒÉÒÙß|_YaoÕÀ¼¼M(=¸¯±¸ÂVDÂW,,.3@ݶµ¾Á»¾ÒPD?><=@GP}ÒÆÃÈÒÚä~æßØ̾¶Î/9¿´¹ÀÍW54Áj*),6?ê¾²µ»³°»ØiZSJDEELhþåóëÍæPJL`éâÜÌ»Ã5<º±³·¾ÞG/8µÑ,*/68_º³·µµ¾æKITN=FY\êòí×ÒÑÇÑéýæÛîoWÚÂ:4ô²¹ºÄN1+<¶f+,17Bĵ¯¯±»ÌêHU`NIGJLMQ^ÿÛÍÎÚechzÞÕ®°·Ã\4+.JºD*+-2Gŵ°¸¾ÔüW\kSS^Y]öÜÜçëÝÞùklOKPaÕÐ>Qµ¯°µ»ÊI324UµO-,-:d»´»ÊílVKJDDNYaiÿeSbßÐÚÔØ]Vn×Â[@¹«±¼Êf919/>¼?('+;qµ¬²»ÇÎËÞhYKDLùÞØÚ^RTgtcn^GBOÖÏ=I±ª¬³¿Ès=;@4[»<*(/EÓ³¯²½ÏÛÜÏÔÜ^QDFjbncXWmÖÓÔØqD>ZÍÛ<í«©°¼ËóI7:?8~¼;((0HÒ´®¹¿ÅÖÑÚdUJDLïÐ×mSQ[nni]L>?dÍû>È©ª®¸ÊÛO:=?7tÇ7))7Qη¯²½ÄË×Ùìg^OFQâÔçcY^oêügNGIïÅi>È®¯³ÁÙöH:CC;ÝÛ1*-@pÅ´¯¶ÄÌÑÙÙãñíVIaÕÜ`SLUZfÝÜkVCBpÇ|J¿¯¯¶ÇíU>7?DMÂó0+/Kݽ¯³¿ÈÕþjYSKBBVâÞkNIHSêÚò]NFQξãõ²«¬³¿Ø\>7;8GÜ?)'0Hâ¼°¯¹ÈÍÛ~ôæßþVUêÎÊÝ[LHS{æ÷SHBKÖÍK󳯲½ÏñS@AGQÌÛ:+*7S˵®¯½Îâ`[UT_ZLNaÐËmNGJZíÔèøiR|ÂÚS»¬®¶ÅåO>89;OÝG/(,Aܹ¬±ÁØù_]_}ÞîX\yÒÕZIEGOvx\THHâÝM몯ºÈÞZHA<Cç];-(2Pɵ¯²¾Øp[SLM[øúmîÛÍÞhQO]näøb]b×Y;Ϭ«±ÁÝVE@IC@^mB3+0M͸¬¸Êæ^]ZX\^cmíêìzYJBHWf}ZYçÖ>8º§§®¼Ï]BARKE[Z>1.5I×¾²³ÀàTMONayíÞàÖÍËÍÙkNHLTV^{ÓJ1U³©ª³ÇsC<AHDFQN=59Kç˹¯µÃîY\_Y\chgjhlÖÌÒéL?ACNåÊE9Õ·¯¯µ½ÎYSéõULOMC=>HQOTÜÉÍùNQ^gojÿÝÕá}òÜÆ¿ÌõTDGÙá;Y·®°¿ùjSJ}ùQE>>?=BgÌÂÉÕÛÒÒ÷ZUXYZ[TQïÎÜäuæÏÍÕVGTW5;į¬±¿âJ?h¼¼×O@;57FêÇÅÕ|jQIXjleZ^rtmâÕËÍæôéæïkíÒúJxÉÖÛÔçõoRùÆÂÈäM?<AWâ×ÛèßßgZ[foWKMPShÛÒØæßÓÖâëæÝíNKóɾ¾ÒcS`ÝÊÌ÷f]KA?NbejaëÌÉÏøQQSMOW`÷ßÚÏÎÓÍÌÖmQH=@Ï°®»m?;=HwÎÌêRIHNeÒ½»ÀÑa_ojfq^MHGJP^joý{üàÓÓúZV]ÿÑÄÿÄÏéub\[WSNKEGWèÑÍ×o`ZRSWW^êÛßêquîáÝÚÎÔÜâþqUFLÜ¿·ºÏZEAJ]kUJLRZiÜÉÄÃÄÉÑæ]KEEJkmd{TV[ROXmô×ÌÖZCV¼³ÆTC?BVó|VKIGYßÉÀÃÑbKHOZ^\T]kgfðÛÜääßàáåñoJ59Ô°¬´ÊuH:<TÐÏYQU^óɾÃÌãMACK\kéÙÛÝÛÚîYJHNhÙÆ@%9µª³ðUK>f¶°ÌMOC@NõÁÇhxgUI=;<DhèÏÈÇ¿ÃÏåsâòçÇ`67Hûîfrf?I½±ºÊëkiJBUáð`Ó¾Ëëå[fìwÛÛßÔÈÎîúõQIBMb,)=e×çîZBZ¸¯¶ÍPlØØÌÆÃÒÞÀººÃåhK>?EBCK[àÇÄÖ_>6A@>FVôdäâGDÌ°¬·ç[àoKïÅËfM庸Éêj^OLL=@FMýÓÐ×÷QøE7±ºK<;NI=M¼´¾ÊÔÞÞUMzÏÎÔÀ¶´Å]HBHCCHFHNüÕÉ¿Ç^BK,.§®RJAFEDþµ¶ËÕÛãòú{úÚpõÊÆÊ×}_MKMHB:B_âÏ¿¶ºÞPL(*©ªyJ@FEUǯ´×e`_ZIGOVlÓÄÀÇßOJO\p_@<KÿÓËÁ¹¼Õâ> -¦£ÛD>>=Q¼¯¼ÝßÓéN]ø_TShmr_NNSeîÞkA=Hhââ˸¹ÆÃ9#1«½G>:8Z´®¹âWfM?XÜÙùqéx`KCGCJV^L=EkÏÄÉĹ½ÁÅ5*9¯½C<7:g³®¼gMQJ>NêïíêþTTaNORW_bI=D_ÑÆÉÈÁ¿ºÇ1.:¹º>=9:hµ¯»öNa`LZçíïåjQNJAFIOgmNENxÛÛâä×ŶÁ66H¼JE=?n»·Æ[MWUMXí÷ÚÜfN<<>EHC\iKL]ÙÇÃÅÍÓʹ¿<6FÉ ªGA@Gõ¼»ÍIBSWXS^qèãßb?=BGII]iVRZÛÈÅÈ×á̸¸L5@쥥[?=?ZƾÑWGNSRQ\ijîÜ|D>EHLMY\]^öÊÅÆÈØãʹ¸ñ95T¦§aA?EhÈ¿ÎN>ELOdíwYWbeI@CDLMZmìÛÒž¿ÊìpλºÌR=A¾«»YD:@íÆÍbGCCFQhô|qmnN?EptrMonitorPortEntry 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 }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 } -- -- 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 }-- 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." ::= 1rptrGroupChange 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." ::= 2rptrResetEvent 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 END -
5. Acknowledgments
-
This document is the work of the IETF Hub MIB Working Group. It is
based on drafts of the IEEE 802.3 Repeater Management Task Force.
Members of the working group included: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.net
6. References
-
[1] 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. [2] 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. [3] 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. [4] 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. [5] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [6] 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. [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [8] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [9] 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.[10] 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
-
Security issues are not discussed in this memo.
8. Authors' Addresses
-
Donna McMaster
SynOptics Communications, Inc.
4401 Great America Parkway
P.O. Box 58185
Santa Clara, CA 95052-8185EMail:
mcmaster@synoptics.com
Keith McCloghrie
Hughes LAN Systems, Inc.
1225 Charleston Road
Mountain View, CA 94043Phone: (415) 966-7934 EMail: kzm@hls.com