LBHUB-MSH-MIB: View SNMP OID List / Download MIB

A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. It is mandatory that this only contain printable ASCII characters.

The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred Router'.

The time (in hundredths of a second) since the network management portion of the system was last re-initialized.

The textual identification of the contact person for this managed node, together with information on how to contact this person.

An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name.

The physical location of this node (e.g., `telephone closet, 3rd floor').

A value which indicates the set of services that this entity primarily offers. The value is a sum. This sum initially takes the value zero, Then, for each layer, L, in the range 1 through 7, that this node performs transactions for, 2 raised to (L - 1) is added to the sum. For example, a node which performs primarily routing functions would have a value of 4 (2^(3-1)). In contrast, a node which is a host offering application services would have a value of 72 (2^(4-1) + 2^(7-1)). Note that in the context of the Internet suite of protocols, values should be calculated accordingly: layer functionality 1 physical (e.g., repeaters) 2 datalink/subnetwork (e.g., bridges) 3 internet (e.g., IP gateways) 4 end-to-end (e.g., IP hosts) 7 applications (e.g., mail relays) For systems including OSI protocols, layers 5 and 6 may also be counted.

The number of network interfaces (regardless of their current state) present on this system.

A list of interface entries. The number of entries is given by the value of ifNumber.

An interface entry containing objects at the subnetwork layer and below for a particular interface.

A unique value for each interface. Its value ranges between 1 and the value of ifNumber. The value for each interface must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization.

A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the hardware interface.

The type of interface, distinguished according to the physical/link protocol(s) immediately `below' the network layer in the protocol stack. Enumeration: 'propPointToPointSerial': 22, 'frame-relay': 32, 'softwareLoopback': 24, 'rfc877-x25': 5, 'ds3': 30, 'ppp': 23, 'ddn-x25': 4, 'slip': 28, 'proteon-10Mbit': 12, 'ethernet-3Mbit': 26, 'sip': 31, 'iso88023-csmacd': 7, 'other': 1, 'sdlc': 17, 'lapb': 16, 'iso88024-tokenBus': 8, 'hyperchannel': 14, 'basicISDN': 20, 'ethernet-csmacd': 6, 'primaryISDN': 21, 'e1': 19, 'fddi': 15, 'proteon-80Mbit': 13, 'starLan': 11, 'eon': 25, 'iso88025-tokenRing': 9, 'ds1': 18, 'hdh1822': 3, 'nsip': 27, 'regular1822': 2, 'iso88026-man': 10, 'ultra': 29.

The size of the largest datagram which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface.

An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth.

The interface's address at the protocol layer immediately `below' the network layer in the protocol stack. For interfaces which do not have such an address (e.g., a serial line), this object should contain an octet string of zero length.

The desired state of the interface. The testing(3) state indicates that no operational packets can be passed. Enumeration: 'down': 2, 'testing': 3, 'up': 1.

The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed. Enumeration: 'down': 2, 'testing': 3, 'up': 1.

The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re- initialization of the local network management subsystem, then this object contains a zero value.

The total number of octets received on the interface, including framing characters.

The number of subnetwork-unicast packets delivered to a higher-layer protocol.

The number of non-unicast (i.e., subnetwork- broadcast or subnetwork-multicast) packets delivered to a higher-layer protocol.

The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.

The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol.

The number of packets received via the interface which were discarded because of an unknown or unsupported protocol.

The total number of octets transmitted out of the interface, including framing characters.

The total number of packets that higher-level protocols requested be transmitted to a subnetwork-unicast address, including those that were discarded or not sent.

The total number of packets that higher-level protocols requested be transmitted to a non- unicast (i.e., a subnetwork-broadcast or subnetwork-multicast) address, including those that were discarded or not sent.

The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.

The number of outbound packets that could not be transmitted because of errors.

The length of the output packet queue (in packets).

A reference to MIB definitions specific to the particular media being used to realize the interface. For example, if the interface is realized by an ethernet, then the value of this object refers to a document defining objects specific to ethernet. If this information is not present, its value should be set to the OBJECT object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value.

The indication of whether this entity is acting as an IP gateway in respect to the forwarding of datagrams received by, but not addressed to, this entity. IP gateways forward datagrams. IP hosts do not (except those source-routed via the host). Note that for some managed nodes, this object may take on only a subset of the values possible. Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to change this object to an inappropriate value. Enumeration: 'forwarding': 1, 'not-forwarding': 2.

The default value inserted into the Time-To-Live field of the IP header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol.

The total number of input datagrams received from interfaces, including those received in error.

The number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc.

The number of input datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IP Gateways and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address.

The number of input datagrams for which this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities which do not act as IP Gateways, this counter will include only those packets which were Source-Routed via this entity, and the Source- Route option processing was successful.

The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol.

The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly.

The total number of input datagrams successfully delivered to IP user-protocols (including ICMP).

The total number of IP datagrams which local IP user-protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipForwDatagrams.

The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this (discretionary) discard criterion.

The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this `no-route' criterion. Note that this includes any datagrams which a host cannot route because all of its default gateways are down.

The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity.

The number of IP fragments received which needed to be reassembled at this entity.

The number of IP datagrams successfully re- assembled.

The number of failures detected by the IP re- assembly algorithm (for whatever reason: timed out, errors, etc). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received.

The number of IP datagrams that have been successfully fragmented at this entity.

The number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their Don't Fragment flag was set.

The number of IP datagram fragments that have been generated as a result of fragmentation at this entity.

The table of addressing information relevant to this entity's IP addresses.

The addressing information for one of this entity's IP addresses.

The IP address to which this entry's addressing information pertains.

The index value which uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex.

The subnet mask associated with the IP address of this entry. The value of the mask is an IP address with all the network bits set to 1 and all the hosts bits set to 0.

The value of the least-significant bit in the IP broadcast address used for sending datagrams on the (logical) interface associated with the IP address of this entry. For example, when the Internet standard all-ones broadcast address is used, the value will be 1. This value applies to both the subnet and network broadcasts addresses used by the entity on this (logical) interface.

The size of the largest IP datagram which this entity can re-assemble from incoming IP fragmented datagrams received on this interface.

This entity's IP Routing table.

A route to a particular destination.

The destination IP address of this route. An entry with a value of 0.0.0.0 is considered a default route. Multiple routes to a single destination can appear in the table, but access to such multiple entries is dependent on the table- access mechanisms defined by the network management protocol in use.

The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex.

The primary routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1.

An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1.

An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1.

An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1.

The IP address of the next hop of this route. (In the case of a route bound to an interface which is realized via a broadcast media, the value of this field is the agent's IP address on that interface.)

The type of route. Note that the values direct(3) and indirect(4) refer to the notion of direct and indirect routing in the IP architecture. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipRouteTable object. That is, it effectively disassociates the destination identified with said entry from the route identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipRouteType object. Enumeration: 'indirect': 4, 'other': 1, 'direct': 3, 'invalid': 2.

The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols. Enumeration: 'bgp': 14, 'bbnSpfIgp': 12, 'ggp': 6, 'ospf': 13, 'egp': 5, 'rip': 8, 'es-is': 10, 'ciscoIgrp': 11, 'other': 1, 'is-is': 9, 'icmp': 4, 'local': 2, 'hello': 7, 'netmgmt': 3.

The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the routing protocol by which the route was learned.

Indicate the mask to be logical-ANDed with the destination address before being compared to the value in the ipRouteDest field. For those systems that do not support arbitrary subnet masks, an agent constructs the value of the ipRouteMask by determining whether the value of the correspondent ipRouteDest field belong to a class-A, B, or C network, and then using one of: mask network 255.0.0.0 class-A 255.255.0.0 class-B 255.255.255.0 class-C If the value of the ipRouteDest is 0.0.0.0 (a default route), then the mask value is also 0.0.0.0. It should be noted that all IP routing subsystems implicitly use this mechanism.

An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1.

A reference to MIB definitions specific to the particular routing protocol which is responsible for this route, as determined by the value specified in the route's ipRouteProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntactically valid object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value.

The IP Address Translation table used for mapping from IP addresses to physical addresses.

Each entry contains one IpAddress to `physical' address equivalence.

The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex.

The media-dependent `physical' address.

The IpAddress corresponding to the media- dependent `physical' address.

The type of mapping. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipNetToMediaTable. That is, it effectively disassociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipNetToMediaType object. Enumeration: 'static': 4, 'other': 1, 'dynamic': 3, 'invalid': 2.

The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries.

The total number of ICMP messages which the entity received. Note that this counter includes all those counted by icmpInErrors.

The number of ICMP messages which the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.).

The number of ICMP Destination Unreachable messages received.

The number of ICMP Time Exceeded messages received.

The number of ICMP Parameter Problem messages received.

The number of ICMP Source Quench messages received.

The number of ICMP Redirect messages received.

The number of ICMP Echo (request) messages received.

The number of ICMP Echo Reply messages received.

The number of ICMP Timestamp (request) messages received.

The number of ICMP Timestamp Reply messages received.

The number of ICMP Address Mask Request messages received.

The number of ICMP Address Mask Reply messages received.

The total number of ICMP messages which this entity attempted to send. Note that this counter includes all those counted by icmpOutErrors.

The number of ICMP messages which this entity did not send due to problems discovered within ICMP such as a lack of buffers. This value should not include errors discovered outside the ICMP layer such as the inability of IP to route the resultant datagram. In some implementations there may be no types of error which contribute to this counter's value.

The number of ICMP Destination Unreachable messages sent.

The number of ICMP Time Exceeded messages sent.

The number of ICMP Parameter Problem messages sent.

The number of ICMP Source Quench Messages Sent.

The number of ICMP Redirect messages sent. For a host, this object will always be zero, since hosts do not send redirects.

The number of ICMP Echo (request) messages sent.

The number of ICMP Echo Reply messages sent.

The number of ICMP Timestamp (request) messages sent.

The number of ICMP Timestamp Reply messages sent.

The number of ICMP Address Mask Request messages sent.

The number of ICMP Address Mask Reply messages sent.

The algorithm used to determine the timeout value used for retransmitting unacknowledged octets. Enumeration: 'vanj': 4, 'other': 1, 'constant': 2, 'rsre': 3.

The minimum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout. In particular, when the timeout algorithm is rsre(3), an object of this type has the semantics of the LBOUND quantity described in RFC 793.

The maximum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout. In particular, when the timeout algorithm is rsre(3), an object of this type has the semantics of the UBOUND quantity described in RFC 793.

The limit on the total number of TCP connections the entity can support. In entities where the maximum number of connections is dynamic, this object should contain the value -1.

The number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state.

The number of times TCP connections have made a direct transition to the SYN-RCVD state from the LISTEN state.

The number of times TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state.

The number of times TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state.

The number of TCP connections for which the current state is either ESTABLISHED or CLOSE- WAIT.

The total number of segments received, including those received in error. This count includes segments received on currently established connections.

The total number of segments sent, including those on current connections but excluding those containing only retransmitted octets.

The total number of segments retransmitted - that is, the number of TCP segments transmitted containing one or more previously transmitted octets.

A table containing TCP connection-specific information.

Information about a particular current TCP connection. An object of this type is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state.

The state of this TCP connection. The only value which may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to set this object to any other value. If a management station sets this object to the value deleteTCB(12), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection. As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP endpoint (note however that RST segments are not sent reliably). Enumeration: 'synReceived': 4, 'established': 5, 'finWait2': 7, 'timeWait': 11, 'finWait1': 6, 'lastAck': 9, 'closeWait': 8, 'deleteTCB': 12, 'closed': 1, 'closing': 10, 'listen': 2, 'synSent': 3.

The local IP address for this TCP connection. In the case of a connection in the listen state which is willing to accept connections for any IP interface associated with the node, the value 0.0.0.0 is used.

The local port number for this TCP connection.

The remote IP address for this TCP connection.

The remote port number for this TCP connection.

The total number of segments received in error (e.g., bad TCP checksums).

The number of TCP segments sent containing the RST flag.

The total number of UDP datagrams delivered to UDP users.

The total number of received UDP datagrams for which there was no application at the destination port.

The number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port.

The total number of UDP datagrams sent from this entity.

A table containing UDP listener information.

Information about a particular current UDP listener.

The local IP address for this UDP listener. In the case of a UDP listener which is willing to accept datagrams for any IP interface associated with the node, the value 0.0.0.0 is used.

The local port number for this UDP listener.

The total number of Messages delivered to the SNMP entity from the transport service.

The total number of SNMP Messages which were passed from the SNMP protocol entity to the transport service.

The total number of SNMP Messages which were delivered to the SNMP protocol entity and were for an unsupported SNMP version.

The total number of SNMP Messages delivered to the SNMP protocol entity which used a SNMP community name not known to said entity.

The total number of SNMP Messages delivered to the SNMP protocol entity which represented an SNMP operation which was not allowed by the SNMP community named in the Message.

The total number of ASN.1 or BER errors encountered by the SNMP protocol entity when decoding received SNMP Messages.

The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `tooBig'.

The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `noSuchName'.

The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `badValue'.

The total number valid SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `readOnly'. It should be noted that it is a protocol error to generate an SNMP PDU which contains the value `readOnly' in the error-status field, as such this object is provided as a means of detecting incorrect implementations of the SNMP.

The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `genErr'.

The total number of MIB objects which have been retrieved successfully by the SNMP protocol entity as the result of receiving valid SNMP Get-Request and Get-Next PDUs.

The total number of MIB objects which have been altered successfully by the SNMP protocol entity as the result of receiving valid SNMP Set-Request PDUs.

The total number of SNMP Get-Request PDUs which have been accepted and processed by the SNMP protocol entity.

The total number of SNMP Get-Next PDUs which have been accepted and processed by the SNMP protocol entity.

The total number of SNMP Set-Request PDUs which have been accepted and processed by the SNMP protocol entity.

The total number of SNMP Get-Response PDUs which have been accepted and processed by the SNMP protocol entity.

The total number of SNMP Trap PDUs which have been accepted and processed by the SNMP protocol entity.

The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field is `tooBig.'

The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status is `noSuchName'.

The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field is `badValue'.

The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field is `genErr'.

The total number of SNMP Get-Request PDUs which have been generated by the SNMP protocol entity.

The total number of SNMP Get-Next PDUs which have been generated by the SNMP protocol entity.

The total number of SNMP Set-Request PDUs which have been generated by the SNMP protocol entity.

The total number of SNMP Get-Response PDUs which have been generated by the SNMP protocol entity.

The total number of SNMP Trap PDUs which have been generated by the SNMP protocol entity.

Indicates whether the SNMP agent process is permitted to generate authentication-failure traps. The value of this object overrides any configuration information; as such, it provides a means whereby all authentication-failure traps may be disabled. Note that it is strongly recommended that this object be stored in non-volatile memory so that it remains constant between re-initializations of the network management system. Enumeration: 'disabled': 2, 'enabled': 1.

A list of alarm entries.

A list of parameters that set up a periodic checking for alarm conditions.

An index that uniquely identifies an entry in the alarm table. Each such entry defines a diagnostic sample at a particular interval for an object on the device.

The interval in seconds over which the data is sampled and compared with the rising and falling thresholds. When setting this variable, care should be given to ensure that the variable being monitored will not exceed 2^31 - 1 and roll over the alarmValue object during the interval. This object may not be modified if the associated alarmStatus object is equal to valid(1).

The object identifier of the particular variable to be sampled. Only variables that resolve to an ASN.1 primitive type of INTEGER (INTEGER, Counter, Gauge, or TimeTicks) may be sampled. Because SNMP access control is articulated entirely in terms of the contents of MIB views, no access control mechanism exists that can restrict the value of this object to identify only those objects that exist in a particular MIB view. Because there is thus no acceptable means of restricting the read access that could be obtained through the alarm mechanism, the probe must only grant write access to this object in those views that have read access to all objects on the probe. During a set operation, if the supplied variable name is not available in the selected MIB view, a badValue error must be returned. If at any time the variable name of an established alarmEntry is no longer available in the selected MIB view, the probe must change the status of this alarmEntry to invalid(4). This object may not be modified if the associated alarmStatus object is equal to valid(1).

The method of sampling the selected variable and calculating the value to be compared against the thresholds. If the value of this object is absoluteValue(1), the value of the selected variable will be compared directly with the thresholds at the end of the sampling interval. If the value of this object is deltaValue(2), the value of the selected variable at the last sample will be subtracted from the current value, and the difference compared with the thresholds. This object may not be modified if the associated alarmStatus object is equal to valid(1). Enumeration: 'absoluteValue': 1, 'deltaValue': 2.

The value of the statistic during the last sampling period. The value during the current sampling period is not made available until the period is completed.

The alarm that may be sent when this entry is first set to valid. If the first sample after this entry becomes valid is greater than or equal to the risingThreshold and alarmStartupAlarm is equal to risingAlarm(1) or risingOrFallingAlarm(3), then a single rising alarm will be generated. If the first sample after this entry becomes valid is less than or equal to the fallingThreshold and alarmStartupAlarm is equal to fallingAlarm(2) or risingOrFallingAlarm(3), then a single falling alarm will be generated. This object may not be modified if the associated alarmStatus object is equal to valid(1). Enumeration: 'fallingAlarm': 2, 'risingAlarm': 1, 'risingOrFallingAlarm': 3.

A threshold for the sampled statistic. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes valid is greater than or equal to this threshold and the associated alarmStartupAlarm is equal to risingAlarm(1) or risingOrFallingAlarm(3). After a rising event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches the alarmFallingThreshold. This object may not be modified if the associated alarmStatus object is equal to valid(1).

A threshold for the sampled statistic. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes valid is less than or equal to this threshold and the associated alarmStartupAlarm is equal to fallingAlarm(2) or risingOrFallingAlarm(3). After a falling event is generated, another such event will not be generated until the sampled value rises above this threshold and reaches the alarmRisingThreshold. This object may not be modified if the associated alarmStatus object is equal to valid(1).

The index of the eventEntry that is used when a rising threshold is crossed. The eventEntry identified by a particular value of this index is the same as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In particular, if this value is zero, no associated event will be generated, as zero is not a valid event index. This object may not be modified if the associated alarmStatus object is equal to valid(1).

The index of the eventEntry that is used when a falling threshold is crossed. The eventEntry identified by a particular value of this index is the same as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In particular, if this value is zero, no associated event will be generated, as zero is not a valid event index. This object may not be modified if the associated alarmStatus object is equal to valid(1).

The entity that configured this entry and is therefore using the resources assigned to it.

The status of this alarm entry. Enumeration: 'underCreation': 3, 'createRequest': 2, 'valid': 1, 'invalid': 4.

A list of events to be generated.

A set of parameters that describe an event to be generated when certain conditions are met.

An index that uniquely identifies an entry in the event table. Each such entry defines one event that is to be generated when the appropriate conditions occur.

A comment describing this event entry.

The type of notification that the probe will make about this event. In the case of log, an entry is made in the log table for each event. In the case of snmp-trap, an SNMP trap is sent to one or more management stations. Enumeration: 'snmp-trap': 3, 'none': 1, 'log': 2, 'log-and-trap': 4.

If an SNMP trap is to be sent, it will be sent to the SNMP community specified by this octet string. In the future this table will be extended to include the party security mechanism. This object shall be set to a string of length zero if it is intended that that mechanism be used to specify the destination of the trap.

The value of sysUpTime at the time this event entry last generated an event. If this entry has not generated any events, this value will be zero.

The entity that configured this entry and is therefore using the resources assigned to it. If this object contains a string starting with 'monitor' and has associated entries in the log table, all connected management stations should retrieve those log entries, as they may have significance to all management stations connected to this device

The status of this event entry. If this object is not equal to valid(1), all associated log entries shall be deleted by the agent. Enumeration: 'underCreation': 3, 'createRequest': 2, 'valid': 1, 'invalid': 4.

A list of events that have been logged.

A set of data describing an event that has been logged.

The event entry that generated this log entry. The log identified by a particular value of this index is associated with the same eventEntry as identified by the same value of eventIndex.

An index that uniquely identifies an entry in the log table amongst those generated by the same eventEntries. These indexes are assigned beginning with 1 and increase by one with each new log entry. The association between values of logIndex and logEntries is fixed for the lifetime of each logEntry. The agent may choose to delete the oldest instances of logEntry as required because of lack of memory. It is an implementation-specific matter as to when this deletion may occur.

The value of sysUpTime when this log entry was created.

An implementation dependent description of the event that activated this log entry.

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. Some groups may not be present in a given repeater instance, 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.

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) Enumeration: 'generalFailure': 6, 'ok': 2, 'groupFailure': 4, 'portFailure': 5, 'other': 1, 'rptrFailure': 3.

The health text object is a text string that provides information relevant to the operational state of the repeater. Agents may use this mechanism to provide detailed failure information or instructions for problem resolution. The contents are agent-specific.

Setting this variable to reset(2) causes a transition to the START state of Fig 9-2 in section 9 [11]. Setting this variable to noReset(1) has no effect. The agent will always return the value noReset(1) when this variable is read. This action does not reset the management counters defined in this document nor does it affect the portAdminState parameters. Included in this action is the execution of a disruptive Self-Test. As a result of this action a rptrReset trap may be sent. Note: This action may result in the loss of packets. Enumeration: 'reset': 2, 'noReset': 1.

Setting this variable to selfTest(2) causes the repeater to perform a agent-specific, non- disruptive self-test that has the following characteristics: (1) The nature of the tests is not specified. (2) The test does not change the state of the repeater or management information about the repeater. (3) The test does not inject packets onto any segment. (4) The test does not prevent the relay of any packets. (5) The test does not interfere with management functions. After performing this test the agent will update the repeater health information. If a change in the repeater health has occurred, the agent will send a rptrHealth trap. Setting this variable to noSelfTest(1) has no effect. The agent will always return the value noSelfTest(1) when this variable is read. Enumeration: 'noSelfTest': 1, 'selfTest': 2.

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).

Table of descriptive and status information about the groups of ports.

An entry in the table, containing information about a single group of ports.

This variable identifies the group within the repeater for which this entry contains information. This value is never greater than rptrGroupCapacity.

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. 'Wilma Flintstone 6-Port FOIRL Plug-in Module, Rev A' or 'Barney Rubble 10BASE-T 4-port SIMM socket V. 2.1' are examples of valid group descriptions. It is mandatory that this only contain printable ASCII characters.

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 variable 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.'

An object that indicates the operational status of the group. A status of notPresent(4) indicates that the group has been physically removed from the repeater. 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. Enumeration: 'underTest': 5, 'malfunctioning': 3, 'resetInProgress': 6, 'operational': 2, 'other': 1, 'notPresent': 4.

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 operational status has not changed since the agent last restarted.

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.

Table of descriptive and status information about the ports.

An entry in the table, containing information about a single port.

This variable identifies the group containing the port for which this entry contains information.

This variable identifies the port within the group within the repeater for which this entry contains management information. This value can never be greater than rptrGroupPortCapacity for the associated group.

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.) Enumeration: 'disabled': 2, 'enabled': 1.

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 Sect. 9 [11]. They are not differentiated here. Enumeration: 'notAutoPartitioned': 1, 'autoPartitioned': 2.

This object indicates the port's operational state. The notPresent(3) state indicates the port is physically removed (note this may or may not be possible depending on the type of port.) The operational(1) state indicates that the port is enabled (see rptrPortAdminStatus) and working, even though it might be auto-partitioned (see rptrPortAutoPartitionState). Enumeration: 'notPresent': 3, 'notOperational': 2, 'operational': 1.

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) [11]. Note: The approximate minimum time for counter rollover is 16 hours.

Table of performance and error statistics for the groups.

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.

This object identifies the group within the repeater for which this entry contains information.

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.

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.

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.

Table of performance and error statistics for the ports.

An entry in the table, containing performance and error statistics for a single port.

This object identifies the group containing the port for which this entry contains information.

This object identifies the port within the group for which this entry contains information.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Table of address mapping information about the ports.

An entry in the table, containing address mapping information about a single port.

This object identifies the group containing the port for which this entry contains information.

This object identifies the port within the group for which this entry contains information.

This object is the SourceAddress of the last readable frame (i.e., counted by rptrMonitorPortReadableFrames) received by this port.

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.

The SNMP trap that is generated when an alarm entry crosses its rising threshold and generates an event that is configured for sending SNMP traps.

The SNMP trap that is generated when an alarm entry crosses its falling threshold and generates an event that is configured for sending SNMP traps.

The rptrHealth trap conveys information related to the operational state of the repeater. This trap is sent only when the operational status of the repeater changes. The rptrHealth trap must contain the rptrOperStatus variable. The agent may optionally include the rptrHealthText variable 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.

This trap is sent when a change occurs in the group structure of a repeater. This occurs only when a group is logically 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.

The IPX System Table - basic information.

Each entry corresponds to one instance of IPX running on the system.

The unique identifier of the instance of IPX to which this row corresponds. This value may be written only when creating a new entry in the table.

The validity of this entry in the IPX system table. Setting this field to off indicates that this entry may be deleted from the system table at the IPX implementation's discretion. Enumeration: 'on': 2, 'off': 1.

The network number portion of the IPX address of this system.

The node number portion of the IPX address of this system.

The readable name for this system.

The total number of IPX packets received, including those received in error.

The number of IPX packets discarded due to errors in their headers, including any IPX packets with a size less than the minimum of 30 bytes.

The number of IPX packets discarded because the destination socket was not open.

The number of IPX packets received but discarded due to reasons other than those accounted for by ipxBasicSysInHdrErrors, ipxBasicSysInUnknownSockets, ipxAdvSysInDiscards, and ipxAdvSysInCompressDiscards.

The number of IPX packets received with incorrect checksums.

The total number of IPX packets delivered locally, including packets from local applications.

The number of times no route to a destination was found.

The number of IPX packets supplied locally for transmission, not including any packets counted in ipxAdvForwPackets.

The number of IPX packets supplied locally that contained errors in their structure.

The number of outgoing IPX packets discarded due to reasons other than those accounted for in ipxBasicSysOutMalformedDiscards, ipxAdvSysOutFiltered, and ipxAdvSysOutCompressDiscards.

The total number of IPX packets transmitted.

The configured maximum number of IPX sockets that may be open at one time.

The number of IPX socket open calls which failed.

The IPX System Table - advanced information.

Each entry corresponds to one instance of IPX running on the system.

The unique identifer of the instance of IPX to which this row corresponds. This value may be written only when creating a new entry in the table.

The maximum number of paths with equal routing metric value which this instance of the IPX my split between when forwarding packets.

The maximum number of hops a packet may take.

The number of IPX packets discarded due to exceeding the maximum hop count.

The number of incoming IPX packets discarded due to filtering.

The number of incoming IPX packets discarded due to decompression errors.

The number of NETBIOS packets received.

The number of IPX packets forwarded.

The number of outgoing IPX packets discarded due to filtering.

The number of outgoing IPX packets discarded due to compression errors.

The number of circuits known to this instance of IPX.

The number of currently reachable destinations known to this instance of IPX.

The number of services known to this instance of IPX.

Mounted on the Management card is a temperature sensing device. This device provides three output levels : OK, WARM and DANGER. Enumeration: 'warm': 2, 'ok': 1, 'danger': 3.

This table provides information about and allows configuration of the 4 general purpose inputs provided by the MSH management card.

This entry describes one of the status inputs provided by the MSH management card.

Identify one of the status inputs provided by the MSH card.

Each of the MSH management general purpose input lines is actually a pair of wires. In order to use one of the lines the two wires of a particular pair must be connected to some kind of external switch. The switch could for example be a relay or micro-switch. If the two wires of a pair are shorted together by closing the switch the value of this object will be 'closed'. If the switch is open then the value of this object is 'open'. The MSH can be configured to generate an SNMP trap if the state of this object changes. Enumeration: 'open': 1, 'closed': 2.

By setting the value of this object to enable, the MSH will monitor the value of statusInputState for changes. If a change from open to close or from close to open occurs then an SNMP trap is generated. Note that the value of the object is de-bounced by the agent to prevent multiple closures of a 'bouncing' relay causing multiple SNMP traps! Enumeration: 'enable': 1, 'disable': 2.

This is a writable string associated with one of the status inputs. By default the string will initialise to 'Status Input #x' where x is 1, 2, 3 or 4. The user can choose to write a more descriptive string to this object that better describes the use of a particular input. For example if input line 2 is connected to a switch which changes state when a cabinet is opened or closed then the statusName may be set to 'Door Status ' The value of this object is sent to attached management stations in the state change trap.

The chassis management card contains an 802.3 MAC and physical layer that can be used for management traffic. In some situations this interface may be inappropriate. For example in a Token Ring only environment it is appropriate to transmit management traffic directly onto the token ring network. The MSH chassis provides the ability for the management card to use either its own MAC or to share the MAC provided by another card in the chassis. There may be a number of MACs available at any particular time from which the management card can choose. This table provides a summary of the available MACs and allows the manager to select one of those for current use. Note: The table also includes the MAC actually present on the management card!

This entry describes the abilities and the state of one of the MACs available for management use in the chassis.

Index into the table. This is identifies the card on which the MAC that this conceptual row describes.

Index into the table. This object distinguishes the MAC described by this row in the conceptual table from the potentially many MACs supported by this card.

This is an informational field. It describes the capability of the MAC represented by this conceptual row to receive and transmit a 'broadcast' packet. Note that the shared MAC is currently used to transmit and receive SNMP frames. If an attempt is made to use a MAC with insufficient capability that request will be rejected. Enumeration: 'false': 2, 'true': 1.

This is an informational field. It describes the capability of the MAC represented by this conceptual row to directly filter packets based on the contents of the LSAP field locally to that card. This can improve performance but is not required for protocol operation. The management card will automatically make best use of this feature if present. Enumeration: 'false': 2, 'true': 1.

This is an informational field. It describes the capability of the MAC represented by this conceptual row to directly filter packets based on type field locally to that card. The type field is held in a SNAP header in IEEE networks or in the Ethernet type field. This can improve performance but is not required for protocol operation. The management card will automatically make best use of this feature if present.

This is an informational field. It indicates the maximum number of data octets that can be transmitted or received using the shared MAC. When used for SNMP it is likely that a larger PDU size will increase the performance of some management operations. Note that a minimum size of 474 octets is required for SNMPv1

The physical MAC address of this specific MAC.

This object is used to enable or disable a shared MAC for SNMP protocol usage. Note that if a shared MAC has insufficient capabilities to run the SNMP stack then an attempt to set the status to active will fail. This object has three values: available, unavailable and snmpMac. The meaning of each of these is: available: This MAC is currently available to run SNMP on behalf of the management card. unavailable: MAC cannot be selected to carry SNMP on behalf of the management card. The MAC may be in this state for a number of reasons. Examples are insufficient resource on the card, shared MAC already in use for something other than SNMP. snmpMac: This MAC is currently being used as the physical interface for management card SNMP traffic. To select a MAC write snmpMac to this object. If the MAC is suitable and available then the current snmpMac will become unavailable and the selected MAC will become available. Enumeration: 'available': 1, 'unavailable': 2, 'snmpMac': 3.

This table contains configuration information for each of the card specific LEDs on the front panel module. There is one LED for each card location.

This entry describes the abilities and the state of one of the MACs available for management use in the chassis.

Identifies which LED this row describes.

Read the current colour of the LED. This is intended for use by FullView type applications. Enumeration: 'green': 2, 'off': 1, 'red': 3.

Writing 'attention' to this object will cause the LED above that card to become RED. This is intended to be used to aid maintenance of a large system. Enumeration: 'attention': 2, 'ok': 1.

In order to ensure a clean read of the Fault table this flag should be set to clean_read when commencing to read the table and should be examined after reading the entire table. If still set to clean_read then the table read is okay, if not the table should be re-read as it has been modified during the read process. Enumeration: 'clean-read': 1, 'modified': 2.

The Fault Table.

Information relating to a single fault.

The index into the Fault table. The initial read from the table should be read as the next, from an index of 0; subsequent reads should read the next from the index returned by the previous read.

This error number for this fault log entry.

The time since startup, in milliseconds, when the fault occurred.

The number of restarts at time of fault.

The time, in seconds, between successive heartbeat events sent to the management station. An interval of 0 indicates that no heartbeat events are to be generated.

This table shows the IP address and network mask to be used to initialise ipAddrTable on each network interface after the next system restart. There is one entry per network interface and the index is equivalent to the index for the ifTable in the MIB-II interfaces group.

The default information relating to a single IP interface.

The index value which uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex (for ifTable).

The IP address to be used for this interface.

The IP network mask to be used for this interface.

This is the IP address of the default router to be used for sending IP datagrams to remote destinations which have no suitable entry in the routing table. This corresponds to an entry in the MIB-II ipRouteTable with an ipRouteDest field of '0.0.0.0' (the default router) which is set up from this value after a system restart. Changes to this value do not affect the IP routing table until after the next system restart. (To change the default router without a restart, the IP routing table should be changed directly, with an equivalent change to setIpIfRouter only if the change is required to be made permanently.)

The PROM software version number.

The number of restarts the box has undergone, either power on or reset switch or watchdog expiries.

The reason for the last system restart. This may be due to management command; watchdog timeout expiry; power interruption; the reset switch was pressed or system error. It is not possible to differentiate between the latter two causes. Enumeration: 'watchdog': 3, 'power-reset': 4, 'other': 1, 'command': 2, 'system-error': 5.

Reset the device with manufacturers default configuration if the manDefaultReset value is written to this item. Enumeration: 'nochange': 1, 'manDefaultReset': 2.

The last System Error experienced by the system. This is set equal to the last system error code recorded in non-volatile memory on startup. When the system issues a TRAP indicating the last system error number, the value in non-volatile memory is set to zero. Hence after the next restart this attribute will also have the value zero.

Restart the device with it's current configuration if the restart value is written to this item. Enumeration: 'nochange': 1, 'restart': 2.

This object contains the value of 'sysUpTime' for this agent at which the last configuration state change took place. For the purpose of this object the definition of a system configuration state change includes: 1) ANY change to the agent, or the device which the agent provides a management view affected through management (SNMP, telnet etc); 2) ANY internal change resulting in the attempt to generate a trap; 3) certain other device specific conditions which are significant but that which in themselves do not cause the generation of a trap.

A table which is used to control the loading of new software images to the devices controlled by the management agent. By convention the first entry in the table (device type = system(1), instance = 1) controls the loading of the device containing the management agent itself. Agents which have no subsidiary devices will have only this one entry in the table. If the Agent does control subsidiary devices, the other entries control the loading of software into subsidiary devices.

An entry containing the objects for controlling the loading of a software image to a device controlled by the agent.

The type of the device to load. Simple agents only contain one device type, which is always `system'. More complex agents, probably containing multiple processors, may contain subsidiary devices denoted (for the purposes of the system loader) as `component'. In general, a `system' device is one which monitors and/or manages the operation of `component' devices. Enumeration: 'component': 2, 'system': 1.

The instance of the device type specified by slDeviceType. By convention instance 1 of the system devices is the one containing the management agent, and always exists. Many systems will contain only the one instance of the system device type.

The status of the last system load operation requested for this device. If the value of this object is in the range 1 to 19 inclusive, or 200 or more, the download failed, and the value is an error code indicating the reason why. Codes 1 to 7 are a direct mapping from the TFTP error codes defined in RFC-783. The possible status values and their meanings are as follows:- fileNotFound(1) the server cannot find the requested file; accessViolation(2) the file system security mechanism does not permit TFTP to access the requested file; illegalOperation(4) TFTP protocol error; unknownTransferID(5) TFTP protocol error; noSuchUser(7) user number not recognised; noResponse(8) load server failed to respond; noResource(9) the download could not be started because of a lack of resources; recLenMismatch(10) the record length differs from that implied by the value of the record length field; invalidRecType(11) the record type is not recognised; checksumError(12) record checksum error; wrongDevice(13) the device type in the file is incorrect; wrongHardwareVersion(14) the software image is not suitable for this version of the hardware; noFileHeader(15) the first record in the file was not a file header; byteCountError(16) the byte count reported in the file trailer record differed from the number of bytes actually received; invalidProgAddress(17) the load file contained a load address which was outside the valid range of memory; eraseFailed(18) unable to erase the program memory; progFailed(19) hardware error programming the memory. The meanings of the remaining values are as follows:- loadPending(20) a load has been requested but has not yet begun; loadActive(21) the device is currently being downloaded; success(22) the device has been downloaded successfully; paused(23) the device could not complete the download at this time, it will request that the load be restarted when it is ready. The following status values may result from downloading a subsidiary module:- modInvalidAdress(200) the load file contained a load address which was outside the valid range of memory; modChecksumError(201) the load data was corrupted as it was transferred from the management agent to the subsidiary module; modTimeout(202) the management agent timed out while waiting for a response from the subsidiary module; modBusy(203) the subsidiary module was unable to accept a command from the management agent; modRemoved(204) the subsidiary module was removed during the download; modNoResource(205) the download could not continue because of a lack of resources; modFailure(255) the subsidiary module failed during the download. Enumeration: 'wrongHardwareVersion': 14, 'byteCountError': 16, 'modFailure': 255, 'modTimeout': 202, 'noFileHeader': 15, 'checksumError': 12, 'progFailed': 19, 'invalidRecType': 11, 'loadPending': 20, 'invalidProgAddress': 17, 'accessViolation': 2, 'modInvalidAdress': 200, 'wrongDevice': 13, 'unknownTransferID': 5, 'modNoResource': 205, 'noResponse': 8, 'recLenMismatch': 10, 'paused': 23, 'noResource': 9, 'illegalOperation': 4, 'success': 22, 'eraseFailed': 18, 'loadActive': 21, 'noSuchUser': 7, 'modChecksumError': 201, 'modRemoved': 204, 'fileNotFound': 1, 'modBusy': 203.

The version identifier of the software running in the device.

The version number identifying the revision level of the hardware of the device

The name of the file which contains the software image to load, or which was the last loaded to the device.

The IP address of the host containing the software image to load, or from which the last image loaded was read. This object has been deprecated in favour of writing the IP address into slServerAddress.

Writing 2 to this object causes the agent to attempt to load a new software image to the corresponding device. The file to load and the address of the server to load it from are specified in the other objects in the same row of the table. Enumeration: 'startDownload': 2, 'noAction': 1.

The address of the server containing the software image to load, or from which the last image was loaded. This is either an IP address in standard dotted notation, or an IPX address in the format aabbccdd:112233445566. An error is returned if the agent does not support the download protocol implied by the address format.

This is the protocol to use when downloading the software from the server specified in slServerAddress. At present, this value is determined by the value of slServerAddress which is currently un-ambiguous and so this object is read-only. Enumeration: 'unknown': 1, 'tftp-ip': 2, 'tftp-ipx': 3.

A table of permissions for access to the managed device from each of its interfaces, at each security access level. The table is fixed at 5 rows, indexed by the access level.

This table allows individual interfaces to be enabled or disabled separately for each security level.

Index to the security enable table. Enumeration: 'manager': 3, 'specialist': 4, 'secureMonitor': 2, 'security': 5, 'monitor': 1.

Community SNMP access permission Enumeration: 'permanentlyEnabled': 3, 'enable': 1, 'permanentlyDisabled': 4, 'disable': 2.

Secure SNMP access permission Enumeration: 'permanentlyEnabled': 3, 'enable': 1, 'permanentlyDisabled': 4, 'disable': 2.

Local Terminal access permission Enumeration: 'permanentlyEnabled': 3, 'enable': 1, 'permanentlyDisabled': 4, 'disable': 2.

Telnet access permission Enumeration: 'permanentlyEnabled': 3, 'enable': 1, 'permanentlyDisabled': 4, 'disable': 2.

Front Panel access permission Enumeration: 'permanentlyEnabled': 3, 'enable': 1, 'permanentlyDisabled': 4, 'disable': 2.

A table used to define Users. Users can be created/modified or deleted, with the exception of the default Users which cannot be deleted.

1. Creating a new user is done by using the username as a qualifier and SETting any of the items in the row - defaults will be used for the remaining values. 2. Deleting a user is by writing 'invalid' to the status column. 3. There must always be users called 'monitor', 'manager' and 'security' - these cannot be deleted.

User Status. `invalid' is used to indicate this user is no longer allowed to access this device, and the table entry may subsequently be re-used. Note that the Status of default Users cannot be set to invalid. Enumeration: 'valid': 1, 'invalid': 2.

An ASCII string for the User Name. Empty strings are not allowed. The index column for the User Table.

User Access Level defining the scope of management allowed for this user. Note that the access level of default Users cannot be changed. Enumeration: 'manager': 3, 'specialist': 4, 'secureMonitor': 2, 'security': 5, 'monitor': 1.

The password required for user confirmation, when access is made via the local serial port, the front panel, or via Telnet.

The community string identifying this user, when access is made via the original community-based SNMP (RFC1157).

The local party identity of this user, when access is made via secure SNMP.

The manager party identity for this user, when access is made via secure SNMP.

The audit log is a circular table recording all updates to the managed database on the device. The log must be read regularly by a management device, to maintain a more permanent record of the management history.

Each entry contains the time an update was made, by whom, the item referenced, the new value and the result of this request.

Audit Log Index. A monotonically increasing value to uniquely identify an entry in the audit log. This value wraps around (to 1) after reaching the maximum value (65535).

The time, in hundredths of a second since the last system restart, of the update request.

The name of the user making the request.

The object identifier of the item being updated. This includes any qualifier for the item.

The new value for the item.

The result of the update request may indicate that it was applied successfully, that it failed (for one of a number of reasons) or that it is still in progress. Enumeration: 'locked': 4, 'success': 255, 'no-such-function': 6, 'no-such-item': 7, 'too-big': 2, 'failed': 3, 'security-violation': 5, 'pending': 1.

A table used to define Alarms.

This table allows Alarms to be set-up on items in the MIB.

Unique identifier for a row in the Alarm Table. Allocated by the Alarms Subsystem. An integer in the range 1..gaugeTableSize.

The object Id and qualifier of the item to be monitored by this alarm.

A 'counter', by definition will always be a positive number. 'Meters' can be signed or unsigned. Enumeration: 'signedMeter': 2, 'unsignedMeter': 3, 'counter': 1.

The number of samples used to calculate the Alarm Value. The default number of samples is four. If a SamplesPerAverage value of one is used, no average is calculated and the GaugeValue will be the most recent sample. Enumeration: 'maxSamples': 4, 'twoSamples': 2, 'threeSamples': 3, 'nonAveraging': 1.

Number of seconds between samples. The total averaging period is given by (gaugeSamplesPerAverage * gaugeSamplePeiod) secs.

The most recently computed average of the item being monitored. For a `meter' alarm, this is the simple average of the samples. For a 'counter' alarm, this is the average of the differences between successive samples. Counters and unsignedMeters are unsigned 32-bit values and have a maximum value of 4294967295. signedMeters are signed 32-bit values and have a maximum value of +-2147483647 divided by the value of gaugeSamplesPerAverage .

The highest recorded Alarm Value. This will be either a signed or unsigned 32 bit value depending on the gaugeItemType

The threshold value of the the Alarm which causes the ThresholdState to move from the 'ready' state to the 'fired' state and also causes the the ThresholdAction to be taken. It will be either a signed or unsigned 32-bit integer depending on the gaugeItemType.

The threshold value of the the Alarm which causes the ThresholdState to move from the `fired' state to the `ready' state and also causes the the RecoveryAction to be taken. This value will be either a signed or unsigned 32-bit integer depending on the gaugeItemType.

This object identifies the action to be taken when an Alarm crosses the Threshold Level. The default action will be to send a trigger event (sendTrap). The other actions are device specific and may not be available on all devices. See the RMON Event Table for the actions supported by this device. Enumeration: 'notifyAndBlipCardOff': 6, 'notifyPollFailed': 22, 'enable': 4, 'blipPortOff': 12, 'disablePort': 14, 'notifyAndDisablePort': 8, 'notifyAndResilientSwitch': 18, 'noAction': 1, 'blipCardOff': 13, 'notifyBandwidthExceeded': 19, 'disable': 3, 'notifyAndDisableCard': 9, 'notifyAndBlipPortOff': 5, 'sendTrap': 2, 'notifyFilterBridgePort': 23, 'disableCard': 15, 'notifyErrorsExceeded': 20.

This object identifies the action to be taken when a 'fired' Alarm crosses the Recovery Level. The default action will be to send a recovery event (sendTrap). The actions for 'disable' and 'enable' are device specific. Enumeration: 'notifyAndEnableCard': 11, 'enable': 4, 'notifyPollSuccess': 21, 'notifyUnfilterBridgePort': 24, 'noAction': 1, 'enablePort': 16, 'disable': 3, 'notifyAndEnablePort': 10, 'sendTrap': 2, 'enableCard': 17.

onTriggersEnabled - This is the normal active state of a alarm. The gaugeValue is updated on every sample and if it crosses the Threshold or Recovery Levels, the corresponding Action will be taken. onTriggersDisabled - This is used when a new device, or alarm is set up and the Threshold and Recovery Levels have not been calibrated. The Alarm runs as normal and the gaugeValue and peakValue are updated. However, if the gaugeValue crosses the Threshold or Recovery Levels, no action is taken. off - This de-activates the alarm, allowing it to be configured safely . Before updating any of the Alarm fields the alarm SHOULD be turned off. Turning the alarm 'off' and then 'on' will not lose any of the sampling data, gaugeValue, peakValue, or thresholdStatus. Updates to the index fields will fail since they are read-only. deleted - An alarm is invalidated by setting it to 'deleted'. A 'deleted' alarm will not be returned by a 'GetNext' request. autoCalibrate - Updates the Threshold and Recovery values according to the current peak value. The gaugeState will then be set to 'onTriggersEnabled'. This can be done when the gaugeState is in states (1), (2), or (3). After this operation: thresholdLevel = peakValue * %gaugeThresholdLevelScaler recoveryLevel = peakValue * %gaugeRecoveryLevelScaler gaugeState = onTriggersEnabled When the gaugeState is set to either of the 'on' states, all the fields for the Alarm are validated. If any of the fields are invalid, the operation will fail. The sampling data, gaugeValue, peakValue and thresholdState can be reset by writing 'onTriggersEnabled', 'onTriggers- Disabled' , or 'autoCalibrate' to the gaugeState when it is already in either of the 'on' states. Enumeration: 'deleted': 4, 'autoCalibrate': 5, 'off': 3, 'onTriggersDisabled': 2, 'onTriggersEnabled': 1.

The entity that configured this entry and is therefore using the resources assigned to it.

Number of entries in Alarm Table. The size of the Alarm Table depends on the requirements and available resources of the device. The actual maximum will probably be around 1000.

The ThresholdLevel is set to this percentage of the peakValue when the Alarm is auto-calibrated. e.g gaugeThresholdLevelScaler = 120 gaugePeakValue = 360 After writing 'calibrateTriggers' to the gaugeState: ThresholdLevel = 120/100 * 360 = 432

The RecoveryLevel is set to this percentage of the peakValue when the Alarm is auto-calibrated. e.g gaugeRecoveryLevelScaler = 90 gaugePeakValue = 360 After writing 'calibrateTriggers' to the gaugeState: RecoveryLevel = 90/100 * 360 = 324

Performs the specified operation on every Alarm in the table. Enumeration: 'deleteAll': 1.

Object Id and qualifier of alarm(s) to be updated.

Alarm Table Column to be updated. Enumeration: 'recoveryLevel': 5, 'thresholdAction': 6, 'itemType': 1, 'gaugeState': 8, 'samplesPerAverage': 2, 'samplePeriod': 3, 'recoveryAction': 7, 'thresholdLevel': 4.

Value to be written to the 'gaugeConfigureColumn' of the Alarms which match the 'gaugeConfigureObjId'. Writing to this value initiates the operation.

Indicates the gaugeIndex which must be used to create the next alarm. Index is set to GAUGE_TABLE_FULL (zero) if there are no free rows in the table.

Time in hundredths of a second when the last Login was attempted. Note, that only the ASCII Agent can write to this parameter. A write operation from any other agent will result in an ERROR

An ASCII string used when attempted login. Empty string is NOT valid. Note, that only the ASCII Agent can write to this parameter. A write operation from any other agent will result in an ERROR

Status of last attempted login. The value 'loginOKFromTelnet' or 'loginOKFromSerialPort' is used to show that the user was allowed access via Telnet or Serial Port. 'DeniedAccessFromTelnet' indicates that a user was denied access via Telnet. The value 'unknownUserFromTelnet' is used to show that a user attempted to login with an invalid user name from a Telnet session and 'incorrectPasswordFromTelnet' is used to show that an invalid password was entered having supplied a valid user name. The value 'securityViolationFromTelnet' is used to indicate that a user has entered the password incorrectly three time consecutively from a Telnet session. Note that only the ASCII Agent can write to this parameter. A write operation from any other agent will result in an ERROR Enumeration: 'incorrectPasswordFromSerialPort': 8, 'unknownUserFromTelnet': 5, 'incorrectPasswordFromTelnet': 7, 'securityViolationFromSerialPort': 10, 'nologin': 11, 'securityViolationFromTelnet': 9, 'unknownUserFromSerialPort': 6, 'deniedAccessFromTelnet': 3, 'deniedAccessFromSerialPort': 4, 'loginOKFromTelnet': 1, 'loginOKFromSerialPort': 2.

An ASCII string describing the Banner to appear on the FIRST screen of the Local Management Terminal. The string of 490 characters defines a region in the centre of the screen which is 7 Rows by 70 Columns

This object identifies the serial port which SLIP can use to send/receive packets. If this object is set to 0xFFFF, then SLIP cannot send/receive packets.

Configuration parameters for all the V.24 ports in a system.

Configuration parameters for a V.24 port in the system.

This attribute uniquely identifies this V.24 port, it is the index for the V.24 table.

This determines if the V.24 port is to be connected locally to a terminal or terminal emulator in which case no interface signals need to be asserted unless requested by other management options below or if the V.24 port is to be connected to a modem when at least DSR is required to be asserted. Enumeration: 'remote': 2, 'local': 1.

This determines if the configuration parameters for the V.24 port, speed, parity, stop bits, character size, are to be determined automatically from an initial character sequence entered by the user or they will be defined by the management options below. Enumeration: 'disabled': 1, 'enabled': 2.

This determines the receive and transmit speed of the V.24 port unless the autoconfigure attribute is enabled when the data rates are determined from the line. Split rx and tx speeds are not possible. Enumeration: 'speed4800': 6, 'speed19200': 8, 'speed9600': 7, 'speed38400': 9, 'speed1200': 4, 'speed2400': 5.

This determines the character size, unless the autoconfigure attribute is enabled when character size is determined automatically from the line, it may be set to either 7 or 8 bits. Enumeration: 'size7': 3, 'size8': 4.

This determines the number of stop bits. Enumeration: 'stopTwo': 3, 'stopOne': 1, 'stopOneDotFive': 2.

This determines the parity option to be used, unless the autoconfigure attribute is enabled when parity is determined automatically from the line, it may be set to either no parity, space (parity bit always 0), mark (parity bit always 1), odd or even. Enumeration: 'evenParity': 5, 'markParity': 3, 'spaceParity': 2, 'noParity': 1, 'oddParity': 4.

This attribute is only applicable to local connection types. It determines if DSR need be asserted for a local connection to be made and if the connection need be released if DSR is seen deasserted. Enumeration: 'disabled': 1, 'enabled': 2.

This attribute is only applicable to local connection types. It determines if DCD need be asserted for a local connection to be made and if the connection should be release if DCD is seen deasserted. Enumeration: 'disabled': 1, 'enabled': 2.

This determines the flow control protocol to be used, either no flow control, xon-xoff, rts-cts full duplex or rts-cts. Full duplex rts/cts uses the rts and cts lines as two independent signals. The DTE signals to the DCE that it is prepared to accept more data by asserting RTS, the DCE signals to the DTE that is is prepared to accept more data by asserting CTS. Half duplex rts/cts (the conventional way) uses CTS as a response to RTS, the DCE flow controls the DTE by only returning CTS is response to a RTS from the DTE when the DCE can accept more data. The DTE can flow control the DCE by raising RTS when it does not want to receive any more input and dropping it when it is ready to receive more. Enumeration: 'noFlowControl': 1, 'rtsCtsHalfDplx': 4, 'rtsCtsFullDplx': 3, 'xonXoff': 2.

This attribute may be written to to force the operational V.24 port parameters to be updated. Enumeration: 'nochange': 1, 'update': 2.

A table which allows management of the secure Repeater Ports.

This table allows repeater ports to be configured on a per port basis. It is index using the objects mrmSecRepIndex, mrmSecSlotIndex and mrmSecPortIndex.

The secure port repeater index. This is the first of three indexes into the mrmSecurePortTable.

The secure port slot index. This is the second of three indexes into the mrmSecurePortTable.

The secure port port index. This is the third of three indexes into the mrmSecurePortTable.

Attribute to determine the current security status of a port. This attribute is used by the security trap to identify the reason for the trap. The range of values returned by this object is 1 other 2 unauthorised-station-seen 3 unauthorised-station-port-disabled 4 authorised-station-learnt Enumeration: 'unauthorised-station-seen': 2, 'other': 1, 'authorised-station-learnt': 4, 'unauthorised-station-port-disabled': 3.

Attribute to determine whether the Need to Know feature is enabled on the secure Repeater Line Card. The range of values that are valid for this object are 1 other 2 Need to Know is disabled 3 Need to know is enabled It is only valid to write the values 2 and 3. Enumeration: 'disabled': 2, 'other': 1, 'enabled': 3.

Attribute to determine whether broadcasts are allowed or not allowed to be transmitted. 1 other 2 Broadcasts are not allowed 3 Broadcasts are allowed It is only valid to write the values 2 and 3. Enumeration: 'disabled': 2, 'other': 1, 'enabled': 3.

Attribute to determine whether multicasts are allowed or not allowed to be transmitted. 1 other 2 Multicasts are not allowed 3 Multicasts are allowed It is only valid to write the values 2 and 3. Enumeration: 'disabled': 2, 'other': 1, 'enabled': 3.

Attribute to determine the learning mode of the secure repeater line card. The range of values that are valid for this object are 1 no learning, the address is managed 2 the address of the first incoming packet is learnt 3 the address is continually learning Enumeration: 'continual': 3, 'single': 2, 'off': 1.

Attribute to determine the reporting mode of the secure repeater port. The range of values that are valid for this object are 1 Not in applicable learn state 2 Report only 3 Disconnect and Report Enumeration: 'disconnectandreport': 3, 'off': 1, 'reportonly': 2.

The MAC address in use by the secure repeater port.

This parameter must be set to under-modification before any changes are made to an existing configuration. Changes are not applied until this parameter is set to stable. Enumeration: 'under-modification': 1, 'stable': 2.

This parameter is normally set to 'NO-CHANGE'. When any change is made to the database the value of this parameter becomes 'MODIFIED'. It will remain in this state until a manager sets it back to NO-CHANGE. Enumeration: 'noChange': 1, 'modified': 2.

This parameter clears the End Station Database Enumeration: 'flush': 1.

End Station Table

The end station database maintains information concerning end-station address information against device port for 802.3 repeater type devices. This table provides one of three views on that database. The view provided by this particular table is indexed firstly on address type and then on address and so can be used to read the entire contents of the database in end-station address order. Additionally one can read all addresses of a certain type from the database, e.g. all IP addresses known. There are some points to note when reading the contents of the end station table. Firstly the repeater number reported will change if a unit is moved from one repeater within a device to another or if a unit is isolated. Secondly an address will only appear in the table once. If an address which is already present in the database is found on another port then the original record is changed and the 'modified' flag set for that entry.

The end station database is capable of storing information for a number of different protocols. Each protocol has it's own addressing format. This parameter allows access to the end station database indexed on address type. For example to read all IEE8021 addresses simply start with a get-next operation on IEEE8021.0 and read until the type changes. Enumeration: 'ipx': 3, 'internet': 2, 'ieee8021': 1.

The address information held in this entry of the database. The length and format of the string depends on the address type. For example a MAC address will be a 6 byte OCTET STRING, an IP address a 4 byte OCTET STRING.

Number of unit on which this address was learnt.

Port number of unit on which this address was learnt.

End Station Table ( Modified )

The end station database maintains information concerning end-station address information against device port for 802.3 repeater type devices. This table provides one of three views on that database. The view provided by this particular table is indexed firstly on address type and then on address. The view is restricted to include only those entries in the database which have the MODIFIED flag set, i.e. that have been changed since the database was last viewed by the manager. This table can be used to read all the modified entries in the table. This is the table generally used to update the contents of a station map in a management station. Note that it can take a reasonable time to read the contents of the table and in that time other changes may occur. To detect this an additional MIB parameter is specified 'esDatabaseState'. This parameter is normally set to 'NO-CHANGE'. When any change is made to the database the value of this parameter becomes 'MODIFIED'. It will remain in this state until a manager sets it back to NO-CHANGE. The recommended access for this table is as follows: do { write 'NO-CHANGE' to esDatabaseState read modified table read esDatabaseState } while esDatabaseState is MODIFIED There are some points to note when reading the contents of the end station table. Firstly the repeater number reported will change if a unit is moved from one repeater within a device to another or if a unit is isolated. Secondly an address will only appear in the table once. If an address which is already present in the database is found on another port then the original record is changed and the 'modified' flag set for that entry.

The end station database is capable of storing information for a number of different protocols. Each protocol has it's own addressing format. This parameter allows access to the end station database indexed on address type. For example to read all IEE8021 addresses simply start with a get-next operation on IEEE8021.0 and read until the type changes. Enumeration: 'ipx': 3, 'internet': 2, 'ieee8021': 1.

The address information held in this entry of the database. The length and format of the string depends on the address type. For example a MAC address will be a 6 byte OCTET STRING, an IP address a 4 byte OCTET STRING.

Unit number on which this address was learnt.

Port number of unit on which this address was learnt.

End Station Table ( Port Access )

The end station database maintains information concerning end-station address information against device port for 802.3 repeater type devices. This table provides one of three views on that database. The view provided by this particular table allows one to determine the addresses learnt against a particular port.

Unit part of the identifier for this port.

Port number on unit of port for which end station information is required.

Each port may have a number of addresses against it. This index allows these various addresses to be distinguished. The only stipulation on this number is that it will be unique for the any combination of unit and port. The numbers will be returned in numerically ascending order for a particular unit.port combination but will not be contiguous. For example the following sequence could be seen: Unit Port Index 1 1 211 1 1 231 1 1 438 1 1 672 1 2 120 etc

The end station database is capable of storing information for a number of different protocols. Each protocol has it's own addressing format. This parameter identifies the type of address in this entry of the table. Enumeration: 'ipx': 3, 'internet': 2, 'ieee8021': 1.

The address information held in this entry of the database. The length and format of the string depends on the address type. For example a MAC address will be a 6 byte OCTET STRING, an IP address a 4 byte OCTET STRING.

The snmp Trap database

A single snmp Trap entry

The Status of the Entry valid(1) or invalid(2), writing invalid(2) will delete the entry from the table Enumeration: 'valid': 1, 'invalid': 2.

The Destination IP Address

SNMP Community to be used to send traps to destination trapDestination

SNMP Subject Party used to generate traps to destination trapDestination

32 Bit Mask indicating which Trap categories that the snmpTrapDestination is interested in. '00000001'h - High Priority Configuration Traps '00000002'h - Low Priority Configuration Traps '00000004'h - High Priority Security Traps '00000008'h - Low Priority Security Traps '00000010'h - Alarms & Polling Traps '00000020'h - Regular Heartbeat Traps '00000040'h - End Station Table Traps '00000080'h - reserved '00000100'h - Physical Entity Traps '00000200'h - Facility Traps '00000400'h - Service Related Traps A value of 0xFFFFFFFF enables all traps.

The Maximum rate at which that trapDestination is willing to receive traps, specified as the minimum interval in milliseconds between traps. A value of zero indicates that no trap throttling is required.

This table can store the destination addresses of SNMP managers that wish to receive traps from this device.

This table can store the destination addresses of SNMP managers that wish to receive traps from this device.

This is the unique identifier for this row in the snmpTrapTable. When creating a new row, a manager can read the value of the snmpTrapNextFreeIndex object and (if non-zero) can use this value as the index of the new row to be created. The actual number of rows that can be created on any particular device depends on the memory and processing resources available at the time.

This DisplayString is the network address of the device to which SNMP traps will be sent. This is an IP or IPX address. The following formats can be used. IP nnn.nnn.nnn.nnn - dotted format IPX AABBCCDD:AABBCCDDEEFF - network : node Destination addresses must be unique within this table. An error is returned if an attempt is made to add a duplicate address.

This defines the transport protocol to use when sending an SNMP trap. At present, this value is determined by the format/value of snmpTrapDestionation which is currently un-ambiguous and so this object is read-only. Enumeration: 'unknown': 1, 'ipx': 3, 'ip': 2.

SNMP Community String to be used when sending Traps to this destination.

32 Bit Mask indicating which Trap categories that the snmpTrapDestination is interested in. '00000001'h - High Priority Configuration Traps '00000002'h - Low Priority Configuration Traps '00000004'h - High Priority Security Traps '00000008'h - Low Priority Security Traps '00000010'h - Alarms & Polling Traps '00000020'h - Regular Heartbeat Traps '00000040'h - End Station Table Traps '00000080'h - reserved '00000100'h - Physical Entity Traps '00000200'h - Facility Traps '00000400'h - Service Related Traps A value of 0xFFFFFFFF enables all traps.

The maximum rate at which that snmpTrapDestination is willing to receive traps, specified as the minimum interval in milliseconds between traps. For example, a value of 2000 will limit traps sent to this destination to one trap every 2 seconds. A value of zero indicates that no trap throttling is required.

The SNMPv2 RowStatus convention. Notes: Because this is such a simple table:- 1) Writing any data to a destroyed row, changes its state to active. 2) There is no notReady or notInService state. Each row is either active or destroyed. Enumeration: 'createAndWait': 5, 'notInService': 2, 'notReady': 3, 'createAndGo': 4, 'active': 1, 'destroy': 6.

Indicates the the next value of snmpTrapIndex which can be used to create a new trap destination entry. This value is zero if there are no free rows in the table.

A text string describing the chassis that this MIB describes.

An OBJECT IDENTIFIER specific to this type of this chassis.

The hardware version number of the chassis. This is a string which includes the major and minor revision levels of the hardware.

This table specifies the current physical configuration of the chassis. This table defines a chassis to contain a number of physical entities. Each such entity has some position that distinguishes it from other potentially similar entities. Examples of entities are cards, power supplies etc. Note that this table only contains information on a location that is currently occupied by some entity.

This is one entry in the Physical Configuration Table. It is indexed by physical location.

A chassis contains a number of physical entities such as power supplies and cards. Each physical entity resides at some location. A chassis can contain a number of types of location. Each type of location is specialised to a different purpose. Currently there are four types of location defined. This list can be extended for a particular application: modular-slot: A location of this type can take a number of different entities. They are general purpose and are often the purpose of the device. power-supply-bay: Locations of this type can only contain an instance of a power supply. fan-position: This location can only hold a fan. backplane-position: A position of this type can only contain a backplane. Enumeration: 'backplane': 4, 'power-supply': 2, 'fan': 3, 'module': 1.

A chassis contains a number of physical entities such as power supplies and cards. Each physical entity resides at some location. Some locations are known and have special purposes, others are general and can contain one of a number of different physical entities. The location type defines a 'kind' of location. Within each category there may be one or more instances of that kind of location. For example in a 10 slot modular hub there are potentially 10 instances of card locations occupied at any time.

This object is the OBJECT ID of the entity at this location.

This object identifies what kind of entity is present at this location. The value represents a category of entity, for example '802.3 Repeater' or 'power supply'. It does not identify the specific kind of entity within that category, for this refer to the entity type. Enumeration: 'extendedBackplane': 13, 'ieee8023Repeater': 2, 'displayPanel': 14, 'fddiLinkSwitch': 25, 'dumb8023Repeater': 1, 'standardBackplane': 12, 'ieee8025Ringbuilder': 4, 'terminalServer': 21, 'fan': 17, 'notAllocated': 24, 'fddiMIC': 23, 'ieee8025MauModule': 3, 'bridgePerPort': 20, 'remoteBridge': 22, 'fddiConcentrator': 5, 'managementModule': 6, 'standardBridge': 19, 'powerSupply': 18.

This object is read in conjunction with service type to uniquely identify the specific physical entity. For example the service type may indicate '802.3 Repeater' while the entity type then says within this category this card is a 12 port UTP card. Below are the values currently allocated: smart8023Repeater 1: 4 Port RLC Coax (ECS Variant) 2: 8 Port UTP (ECS Variant) 3: 4 Port Fibre (ECS Variant) 4: 8 Port STP (ECS Variant) 6: 4 Port Fanout (ECS Variant) 7: 12 Port UTP (ECS Variant) 8: 12 Port STP (ECS Variant) 9: 12 Port Secure UTP (ECS Variant) 10: 12 Port Secure STP (ECS Variant) 11: 6 Port Fibre (ECS Variant) 12: 4 Port Coax (ECS Variant) 32: 6 Port Resilient Fibre (ECS Variant) 65: 12 Port UTP, RJ45 Connector 66: 12 Port UTP, RJ45 Connector (Expandable) 67: 13 Port UTP, Telco + Module 68: 24 Port UTP, 2xTelco 69: 6 Port fibre, ST Connector (Expandable) 70: 6 Port fibre, SMA Connector (Expandable) 71: 6 Port Coax (Expandable) 72: 4 Port Fanout ieee8025MauModule 1: 12 Port UTP, RJ45 Connector 2: 12 Port STP, RJ45 Connector 3: 12 Port UTP/STP Advanced MAU ieee8025Ringbuilder 1: Ring Builder. STP Rin/Rout. RJ45 Connectors 2: Ring Builder. Fiber (ST) and STP Rin/Rout. fddiConcentrator 1: FDDI RingBuilder managementModule 1: Standard Management Module 2: Enhanced Management Module standardBackplane 1: Standard Backplane extendedBackplane 1: High Speed Backplane displayPanel 1: First release front panel fan 1: Standard Fan Tray powerSupply 2: Standard Power Supply standardBridge 1: 2 Port Local Token Ring Bridge 2: 4 Port Local Ethernet Bridge fddiMIC 1: FDDI 4 Port MIC 2: FDDI 6 Port UTP/STP fddiLinkSwitch 1: LinkSwitch

This string identifies the major and minor revision level of the entity at this location.

If the entity at this location contains a processor there will be some programme code present. This parameter specifies the version number of that code. The version number is a string. If an entity has no software then the value of this parameter will be 'None'.

Every chassis is considered as a collection of services. Each service is implemented using the resources of one or more physical entities within the rack. For example a repeater may be implemented using 2x12 port UTP cards. A power supply by 3 modular power supply entities. The service table contains an entry for each service present in the MSH at any point in time. This object provides a valid index into the service table. By reading the service table and specifying the value of this object one can determine to which service this card belongs.

This item is a text string describing the entity at this location.

This item takes the +5V and +12V current requirements of the entity and uses the values to obtain a power consumption requirement for the entity. A power supply will specify a negative value indicating a source of power. The value is in Watts. Note that the value returned from this object is the simple arithmetic addition of the all power rail requirements. Note that a power supply may be overloaded even if this value is within the spec of the power supplies. Such a situation can occur if the power supplies can source, say X5 Watts at 5V and X12 Watts at 12V. The total power by this definition is X5 + X12. Now a card could draw Y5 and Y12 from the two supplies. If Y12 is X12+1 and Y5 is X5-2, total supply exceeds total consumption but the 12V rail is overloaded!

This object contains the number of physical, external ports this entity is known to have. Note this value only applies to entities that communicate with the management card. For other cards a value of -1 indicates 'unknown'. A value of zero indicates that this entity has no external ports.

This object allows a visual test to be performed on entities contained in the rack. The state will be recorded against the card even if that entity does not actually do anything different in this state. Enumeration: 'test-off': 1, 'test-on': 2.

Each entity in the chassis has a basic state independent of what function that entity performs within the chassis. If the agent cannot determine the state of a particular entity then the value of this object is 'unknown'. Enumeration: 'initialising': 2, 'unknown': 1, 'failure': 4, 'operational': 3.

This parameter allows a number of actions to be defined for cards in a chassis. Currently only one action is defined: reset. Invoking this operation will reset the specified card. Enumeration: 'reset': 1.

The physical config table describes the chassis as a number of physical entities, each of which has some physical location. This table defines the number of physical locations of each type that actually exists within an instance of the chassis.

This entry provides information on the number of physical locations present in this chassis for the specified type of location. Practically this is interpreted as the 'number of power supplies' or 'number of slots' etc.

A chassis contains a number of physical entities such as power supplies and cards. Each physical entity resides at some location. A chassis can contain a number of types of location. For each particular type of location there is a limit to the number that may be present in the chassis. Enumeration: 'backplane': 4, 'power-supply': 2, 'fan': 3, 'module': 1.

A chassis contains a number of physical entities such as power supplies and cards. Each physical entity resides at some location. A chassis can contain a number of types of location. For each particular type of location there is a limit to the number that may be present in the chassis. This object identifies the actual number of locations in this chassis that exist for the specified type. Practically this is interpreted as the 'number of power supplies' or 'number of slots' etc.

This is a string which may be user-defined for display on the lower line of the front panel display.

An MSH chassis is logically comprised of a number of services, e.g. a repeater, bridge etc. Each service is implemented by one or more physical entities. This table contains an entry for each service, providing a name for that service type. Note that every entry in the physical configuration table MUST belong to a service. For example there may NOT be an entry in the phyConfigTable for which the value of phyServiceId does not provide an index into this table of an existent row.

This is an entry in the Service Table which is indexed by the Service Index for that service.

This is a number representing the service in the rack. This id can be used to reference the service elsewhere in the MIB. There are several conventions used to allocate a service Id. Firstly if a card forms a service by itself, for example a bridge card, which uses none of the backplane 802.3 or token ring lines, then the service id is the same as the slot position of that card within the rack. If a service is constructed using one of the backplane 802.3 facilities then the service id is 101, 102 or 103 for the three backplane 802.3 paths. If a service is a token ring fragment then the service id for that service is 200 plus the ring fragment id. For example if Ring Builder builder builds a ring from MAU cards with ring fragment id 7, the corresponding service will be 207.

This is a text string describing the service at a particular Service Index.

This action will reset all the cards that belong to this service. Enumeration: 'reset': 1.

An MSH chassis contains a number of services. Each service is implemented by one or more cards. A number of services are 'intelligent' in that they communicate with the management station through their own communications stack. This table allows a manager to determine the addresses relevant to a particular service. The table will only have entries present for cards which have management addresses. The table is accessed by specifying a service Id and a sub-index value to distinguish between potentially multiple addresses for a service. NOTE: This table includes entries for the management card itself. The management card entries contain the physical address of the currently active MAC and the IP address of the SNMP stack.

text

Identifies the service for which this row provides address information.

Used to distinguish between multiple addresses for a service in the chassis.

A card in the chassis can have several addresses, either because of multiple stacks and/or for each relevant level in the stack(s). Each relevant address is represented in this table as a display string and a type. Note that ieee8023Address and ieee8025Address types differ from each other in the bit ordering of the physical address. Enumeration: 'ieee8023address': 1, 'slipaddress': 4, 'ieee8025address': 2, 'ipaddress': 3.

The address as block of bytes. An IP address would occupy 4 bytes and a MAC address 6 bytes.

The MSH chassis can simultaneously maintain a number of different sub-networks. Examples of these are the independent repeaters and a number of Token Rings. These fundamental services are referred to as facilities. Each card in the chassis can either provide or be connected to one or more of these facilities. This table provides a means of determining and changing the facilities used by a particular card. The number of entries per card depends on the type of card. For example an 802.3 repeater card can be expected to have a single entry while an 'n' port bridge would have 'n'. The number of entries for a particular card is fixed (can't insert into or delete from this table).

This is an entry in the Facility Table for a particular slot. There may be more than one entry per slot, each entry being distinguished by FacilityIndex.

Allows access to the table for a particular card. One can use this in conjunction with get-next to read all the facility associations for a particular card.

Each card may have multiple entries in the Facility Table. This object provides the means of uniquely identifying each of these entries. Note: It is a convention that the value of this index maps as closely as possible to the physical configuration of the entity represented. For example if a bridge has ports numbered 1, 2, 3 and 4 and all are switchable then this table will have four entries for that entity indexed 1, 2, 3 and 4. Entry with index 1 represents port 1 etc. Similarly if a bridge had two ports numbered, for some reason, 234 and 456 then these values would be used as the index to this table.

Each entry in the facility table represents an association between a physical module and one of the facilities provided by the particular configuration of this chassis. There are a number of different types of facilities the chassis can provide. This object identifies the particular type of the facility represented by this table entry. Note that the list of types in this object may be extended in future. Enumeration: 'atm': 6, 'ieee8025': 2, 'ieee8023': 1, 'ieee8023v3': 5, 'ieee8025rb': 4, 'smds': 7, 'fddi': 3.

This object identifies the current assignment of this attachment point in this card. The legal values of this object depends on the type card. Writing an illegal value to this object will cause an error. Generally the table following identifies the possible values, depending on type. Each card type will support a subset of these values. Type Possible Values IEEE8023 0 Isolated (i.e. this interface is not connected to anything). 1,2,3 One of the backplane 802.3 networks. IEEE8025 0 Isolated 1..0x7f A ring number. This must match the value of one of he ring builder cards or the request will be rejected. FDDI Unknown at the moment. Probably similar to IEEE8025 Note: Values greater than 0x7f are reserved to be private values for a particular card. The meaning of these values depend on the card type. A possible use of this is in a multiport 802.3 bridge. Consider such a bridge being capable of bridging between three sources and having two external 802.3 connections. Such a bridge would have three entries in the facility table, one for each bridge source. Each entry could be assigned to one of the backplane 802.3 paths or to one of the two external connections. In this case the possible values for each table entry would be: 0x00 : Not used (isolated) 0x01, 0x02, 0x03 : One of the backplanes 0x81, 0x82 : One of the external connections. The MSH agent will not allow two different entries in this table for the same card to be assigned to the same facility!

An MSH may be configured to contain a number of 'resilient pairs'. These are 802.3 point to point connections, e.g. UTP, that allow two repeaters to be connected together in a resilient configuration. In such a configuration one of the two ports is nominated the 'main' port while the other is the 'standby' port. One of these two ports is enabled and is the current active port. The other is present in case of failure of the active port. Such a failure is detected by the MSH and a switch performed. There are a couple of rules that must apply to a resilient pair definition before that definition becomes a valid resilient pair. Firstly both ports must be on the same repeater. Secondly the standby port must be configured to be 'disabled on boot'. That is it must recover from a power failure in a disabled state. This prevents loops in the network. Several tables control the resilient repeater configuration for the MSH. This is the first. This is the main table and allows the creation and deletion of pairs and provides status control and information. The information in this table is indexed on the repeater number and the slot/port location of the main port. To create a new resilient pair simply write any writeable object indexed on the main port. This will create a new entry in the table which has the state 'invalid' (read resPairState). Having created the row, write to the other parameters specifying valid information. When all the parameters are valid the resPairState will become 'operational'. In this state the pair will correctly operate as a resilient pair. If any of the attributes in the table change so that the pair in no linger valid this will be reflected in the resPortState parameter. To delete a resilient pair, write 'delete' to resPairAction.

A resilient pair must be attached to one of the repeaters in the chassis. This is part of the index value required to access this table.

This is the second key in the index to this table. This is the slot number of the main port in this pair.

This is the final, key used to index entries in this table. It is the port number of the main port in the pair.

Each port in a pair is constantly monitored for signs of failure. Failure information is used to automatically change the active port from main to standby or vice-versa. Each port may be in one of three states. Failed indicates there is a loss of signal on this port. A port in this state cannot be active. Secondly OK. This state indicates that the port is capable of carrying traffic but is at the moment acting in the role of backup link. The other port in this pair will be in the OK and Active state. OK and Active means what it says, this port is capable of carrying traffic and is so doing at the time this parameter has been read. Enumeration: 'failed': 1, 'ok-and-active': 3, 'ok': 2.

This is the slot number of the standby port for this pair. The port must be present on the same repeater as the main port and so this information is not duplicated.

This is the port number of the standby port.

Each port in a pair is constantly monitored for signs of failure. Failure information is used to automatically change the active port from main to standby or vice-versa. Each port may be in one of three states. Failed indicates there is a loss of signal on this port. A port in this state cannot be active. Secondly OK. This state indicates that the port is capable of carrying traffic but is at the moment acting in the role of backup link. The other port in this pair will be in the OK and Active state. OK and Active means what it says, this port is capable of carrying traffic and is so doing at the time this parameter has been read. Enumeration: 'failed': 1, 'ok-and-active': 3, 'ok': 2.

Each row in the table is in one of two states, 'invalid' or 'operational'. If the state is 'invalid', the resilient pair represented by this row is not active. There are several reasons why this may be the case. Firstly during the row creation process, not all information necessary may have been provided. Secondly an operational pair may become invalid because the resilient pair rules are no longer met because of a change in the MSH configuration. The rules are that both main and standby ports be on the same repeater and that the standby port be 'disable on boot'. Changing the standby card, moving one of the cards to a different repeater are two possible changes that can invalidate a pair configration. If the parameters in the row are all valid then the pair becomes 'operational'. Enumeration: 'invalid': 1, 'operational': 2.

This parameter must be set to under-modification before any changes are made to an existing configuration. Changes are not applied until this parameter is set to stable. Enumeration: 'under-modification': 1, 'stable': 2.

This is object allows the state of a resilient pair to be modified. The create operation configures the resilient port from this table entry. The delete operation removes the resilient definitions from this table and terminates operation of resilience on this pair of ports. The togglePort operation allows the current active port to be changed to the other port. This second operation will only take affect if the state of the currently non-active port is 'OK'. Enumeration: 'create': 1, 'togglePort': 3, 'delete': 2.

This parameter controls whether the resilient pair is enabled or not. In the disabled state , both ports of the resilient pair are disabled. The default value of this parameter is enable Enumeration: 'enable': 1, 'disable': 2.

This table is read-only. If provides shortcut information to allow for the translation of a port number to a corresponding main port number. This value can then be used to access the main resilience table. Each resilient pair has two entries in this table, one for the main port and one for the standby port. The entry for the main port returns the same port, the entry for the standby port returns the corresponding main port.

The repeater index of the port being accessed. This is the first of three indices on this table.

Second index on this table.

Third index on this table.

This attribute specifies whether the port indexed is a main or standby port in the resilient pair table. If the port is neither then there will not be a row in this table indexed for that port. Enumeration: 'standby': 2, 'main': 1.

This is the slot number of the main port for the pair in which the indexed port participates. NOTE if the index port is the main port of a pair (resSbType is 'main') this value will be the same as the index.

This is the port number of the main port for the pair in which the indexed port participates. NOTE if the index port is the main port of a pair (resSbType is 'main') this value will be the same as the index.

This parameter causes all entries in the resilience table to be flushed. Flushing the resilience table does not affect the state of any of the resilient links or ports. Once the table has been flushed , NO resilient links are configured. This parameter is used to ensure that the resilient link table is empty , before new resilient links are configured.

This table contains information about the ring configuration, such as ring speed and wrap state.

This row contains information about a specific ring

This parameter is used to select information about the ring from one of a number of logical devices within the same chassis. For devices that only contain a single device this index will be one (1).

Each ring has a ring number. This is only relevant in the case of a bridged network. When there are multiple bridged token ring segments the ring number is used to determine routing information through the network. If the device knows this information then it appears in this object. If the device is an active ring parameter server then this can be used to assign ring numbers to the ring. If the device is not a ring parameter server then a write request is ignored.

Token ring standards currently exist for 4 Mbps and 16 Mbps operation. This parameter reports the actual speed of the ring to the parent. If a device cannot determine the speed of the ring the value of this parameter will be 'unknown'. Enumeration: 'unknown': 1, 's16MegaBPS': 4, 's1MegaBPS': 2, 's4MegaBPS': 3.

This object reflects the operational mode of the main ring. The ring is either in 'normal' or some error state. In this list the highest numbered error 'wins'. The meaning of the various states is as follows: beacon: This is determined by listening for beacon frames on the network. soft-error: This indicates a high rate of soft errors with respect to the amount of traffic on the ring. For this state to appear requires that the device be able to monitor this error rate. fault: This device has detected a serious ring fault. The fault may have been patched by this device looping a main ring onto a backup ring. This state is used to indicate that the ring is in error and that the topology of the ring, as reported by any station on the ring, is NOT a reliable reflection of the normal topology. If a logical device is incapable of determining the state of the ring, this parameter will have value 'notAvailable'. Enumeration: 'notAvailable': 1, 'fault': 5, 'beacon': 3, 'soft-error': 4, 'normal': 2.

This object reflects the operational mode of the backup ring. The ring is either in 'normal' or some error state. In this list the highest numbered error 'wins'. The meaning of the various states is as follows: beacon: This can be determined by listening for beacon frames on the network. soft-error: This indicates a high rate of soft errors with respect to the amount of traffic on the ring. For this state to appear requires that the device be able to monitor this error rate. fault: This device has detected a serious ring fault. The fault may have been patched by this device looping a main ring onto a backup ring. This state is used to indicate that the ring is in error and that the topology of the ring, as reported by any station on the ring, is NOT a reliable reflection of the normal topology. If a logical device is incapable of determining the state of the ring, this parameter will have value 'notAvailable'. Enumeration: 'notAvailable': 1, 'fault': 5, 'beacon': 3, 'soft-error': 4, 'normal': 2.

This object indicates whether or not the main and backup rings are wrapped together. If the ring is wrapped it does not necessarily mean that it is wrapped at this ring builder, but may be at some other ring builder, an IBM CAU, or some other device with dual ring capabilities. If a logical device is incapable of determining whether the main and backup rings are wrapped, this parameter will have value 'notAvailable'. Enumeration: 'notAvailable': 3, 'ringNotWrapped': 1, 'ringWrapped': 2.

If the ring topology changes, because end stations join or leave the ring, a trap is generated and this variable is set to `true'. If the topology changes again and this variable is already true, no further trap is generated. By examining a3ComRingMapChangeTime a management station can determine when the ring has become stable for a reasonable time and then set this variable back to `false' again, after which another topology change will generate a trap. Enumeration: 'false': 2, 'true': 1.

This is the value of sysUpTime when the ring topology changed last, irrespective of whether or not a trap was generated.

Setting this object to clearRingCounters(2) causes all the counters in this table to be reset to zero. Alternatively, clearAllcounters(3) causes all the ring station statistics (table a3ComRingStat) to be cleared as well. Setting this variable to noAction(1) has no effect. The agent will always return the value noAction(1) when this variable is read. Enumeration: 'clearRingCounters': 2, 'clearAllCounters': 3, 'noAction': 1.

This table contains an entry per ring device within the physical device supporting this MIB. Two entries may refer to the same physical ring if two logical devices are on the same ring.

This row contains statistics about a ring

This parameter is used to select information about the ring from one of a number of logical devices within the same chassis. For devices that only contain a single device this index will be one (1).

This object counts the number of ring state transitions from normal operation to beacon mode. The higher the rate of transitions the worse the reliability of the network. A gauge can be applied to this variable to measure the reliability of the ring.

This is the total number of isolating soft errors reported by stations on the ring. If the rate of soft errors becomes high this is a good indicator of a faulty ring.

Every operational ring has exactly one active monitor. Due to errors it is possible that one of the standby monitors may fail to hear from the active monitor and attempt to become the active monitor itself. If this happens frequently it indicates a problem with the network. It is recommended that a local gauge be attached to this parameter to allow local monitoring of error conditions.

This table contains an ordered list of addresses currently present on the token ring. The table should start from some known MAC on the managed device.

This row contains information about a specific station currently present on the token ring.

This parameter is used to select topology information from one of a number of logical devices within the same chassis. For devices that only contain a single device this index will be one (1).

All token ring managed devices must learn the ring topology. Each logical token device has a concept of the ring topology from it's position within the ring. For example an MSH ring builder learns the ordering of all stations on the ring in which it's local ring section resides. This object provides a unique index within the ring topology.

This is the physical (MAC) address for the station at this position in the ring.

Each token ring segment contains an active monitor. Any station can become the active monitor, this is determined by a special active monitor protocol. The active monitor is responsible for checking the validity of tokens and general ring house keeping. All stations that are NOT the active monitor are standby monitors. Each standby monitor checks that an active monitor is present and is ready to become the active monitor if necessary. Enumeration: 'active-monitor': 1, 'standby-monitor': 2.

This table contains information about the configuration of stations on the ring. Stations are identified by their MAC address and the ring service identifier. NOTE: This table includes information about stations that have at some time been on the ring. The station need not be currently present on the ring. The only time entries should be automatically discarded from this table is to cope with insufficient resource for a new station. If a new station is detected that is not currently in this table and the table has reached it's capacity then some algorithm (e.g. least recently inserted) should be employed to remove a table row.

This entry contains information about a specific ring station.

This parameter is used to select topology information from one of a number of logical devices within the same chassis. For devices that only contain a single device this index will be one (1).

This is the physical (MAC) address of this station. Information in this table is keyed on the address.

This table includes information about stations that have at some time been present on the ring. A new entry is created in this table when a new station appears on the ring. If that station is subsequently removed then the entry in this table remains. This object indicates whether or not the station represented by this table entry is currently present on the ring. Enumeration: 'absent': 2, 'present': 1.

This is the token ring physical location parameter for the station.

This object allows actions to be performed either on the station or the entry in this table representing that station. Not every managed device will be capable of supporting all commands. Setting this variable to noAction(1) has no effect. The agent will always return the value noAction(1) when this variable is read. removeStation: Send a remove station request to the management station. clearCounters: All counters in this table entry are reset to zero. deleteEntry: Remove this entry from the table. This operation is only successful if the station represented by this entry is NOT currently active. forwardTest: This request causes the managed device to test the transmit and receive paths of this station. This is accomplished using the Transmit Forward MAC frame request. When the station test completes the managed device sends a test-response trap. This action only has an effect if the a3ComRingStatState is present. Enumeration: 'removeStation': 2, 'deleteEntry': 4, 'clearCounters': 3, 'forwardTest': 5, 'noAction': 1.

This table contains station statistics. Stations are identified by their MAC address and the ring service identifier. NOTE: This table includes information about stations that have at some time been on the ring. The station need not be currently present on the ring. The only time entries should be automatically discarded from this table is to cope with insufficient resource for a new station. If a new station is detected that is not currently in this table and the table has reached it's capacity then some algorithm (e.g. least recently inserted) should be employed to remove a table row.

This entry contains information about a specific ring station.

This parameter is used to select topology information from one of a number of logical devices within the same chassis. For devices that only contain a single device this index will be one (1).

This is the physical (MAC) address of this station. Information in this table is keyed on the address.

This object is the sum of Line Errors reported by the station. This is an Isolating error. This counter is incremented by a station when a frame or token is repeated by the station and an error bit in the frame is clear, but one of the following tests fails: A code violation occurs between the start and end of the packet; The Frame Check Sequence for a frame is incorrect. A station noticing this error sets the error bit in the packet and forwards to the next station. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and it's upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

This object is incremented when a station detects a recoverable internal error. This can be used to detect a ring station that may be error prone. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and it's upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

The token ring receiver portion of the station expects to see continuous signal transitions on the input. This counter is incremented if the station fails to see a transition for 5 half bit times. To prevent this error being recorded on subsequent stations the detecting station transmits idle after failing to detect a transition after 4 half bit times. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and it's upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

A token ring always includes an active monitor station. Periodically this station initiates an active monitor poll by sending an Active Monitor Present MAC frame. Every frame on a token ring contains an Address Recognised bit and a Frame Copied bit. These are collectively known as the AC bits. When a station processes a frame it must set either or both of these bits. A station that simply forwards a frame to the next station sets neither bit. Valid combinations of the bits are: AC Meaning 00 Frame repeated to next station. 10 The station recognised the address. That station did not however copy the frame. Generally this indicates a lack of resource in the station that recognised the address. 11 The station recognised and managed to copy the frame. These bits are used in an active monitor poll sequence. Each station obeys two rules. 1) When a standby monitor station receives an active or standby monitor present frame with the AC field set to 00 it sets the bits to 11 and starts a timer. When the timer expires it sends a standby monitor present frame. 2) When the active monitor receives any monitor present frame the active poll is considered complete. The Monitor Error counter is increased by a station if it receives either and active or standby monitor present frame with AC=00, then receives a standby monitor present frame also with AC=00. If such a situation occurs there is some error on the ring. This may only be a reconfiguration because the active monitor station has been removed from the ring. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and it's upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

In the token ring architecture a station that transmits a frame will eventually receive that frame after it has gone all the way around the ring. The station that sent the frame then removes that frame from the ring. Whenever a station places a frame onto the ring it starts a timer. It is expected that the frame will return to the station before that timer expires. If this does not happen then this error counter is incremented. Note that this is a non-isolating error and so it is not possible to determine where on the network the fault occurred. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and it's upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

Every frame on a token ring contains an Address Recognised bit and a Frame Copied bit. These are collectively known as the AC bits. When a station processes a frame it must set either or both of these bits. A station that simply forwards a frame to the next station sets neither bit. Valid combinations of the bits are: AC Meaning 00 Frame repeated to next station. 10 The station recognised the address. That station did not however copy the frame. Generally this indicates a lack of resource in the station that recognised the address. 11 The station recognised and managed to copy the frame. If a station receives a packet in which the AC bits are set to '11' and which has that station as the destination of the frame then there are probably two stations on the ring with same address. When a station detects this condition it increases the Frame Copy error counter. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and it's upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

A station increases this counter when it detects a packet addressed to itself but cannot copy that frame due to lack of resource. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and its upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

This counter is incremented whenever a station recognises an error condition resulting in the need to generate a token. This counter will only be incremented by an active monitor station. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and its upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

This counter is incremented whenever a station detects an error in the frequency of the received signal. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and its upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

This counter is the total of the isolating soft error counters in the station. The total does NOT include non- isolating errors because these do not localise an error condition on the ring. GENERAL: Soft Errors The token ring architecture includes an inherent error monitoring protocol. Each station records local errors. These errors are generically referred to as 'soft errors'. Soft errors represent intermittent faults that temporarily disrupt normal operation of the ring. Stations periodically transmit their soft error counters onto the ring where they can be received by any stations which have the ring error monitor functional address active. There are two categories of soft error. Isolating errors and Non-isolating errors. An isolating error will be reported by exactly one station on the ring and the error is known to have occurred between that station and its upstream neighbour. The second category are non-isolating. That is, errors of this nature may be seen and reported by more than one ring station. With these errors it is not possible to resolve the source of the error.

Table of descriptive and status information about the groups of ports.

An entry in the table, containing information about a single group of ports.

This identifies one of the repeaters within the chassis as the target of a request.

This object identifies the card within the repeater for which this entry contains information.

The mrmCardPortCapacity 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 mrmCardPortCapacity. 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.

An object that allows the user to test the operation of a card. Writing test(2) to this object forces the card to perform a disruptive test to determine if the card is functioning properly. Reading this object while the card is under test return the value testing(3). When the test is completed, reading this value will return either passed(4) or failed(5). Enumeration: 'test': 2, 'failed': 5, 'testing': 3, 'passed': 4, 'noTest': 1.

MSH Repeater Cards have the ability to disable ports at power up or reset. Ports configured in this way are useful for configuring resilient links because they prevent loops in the network from occurring at startup. The disable on boot feature is determined according to a hardware strap which cannot be changed via software. This parameter is a mask containing a single bit for each port on the card. Port 1 is represented by bit 0 and so-on. If a bit representing a particular port is 0 this port boots up disabled. If the bit is a 1 the port boots up enabled. This parameter allows the state of these parameters to be rapidly determined by a network management application.

10Base-T line cards are normally configured (mdi_disabled(2)) to link to an external network device ( internal crossover ). Port 1 may be configured ( mdi_enabled(3) ) to link to another 10Base-T line card ( with no internal crossover ). This parameter allows the configuration to be determined. Note ECS line cards show unknown(1) since the configuration cannot be accessed via the management interface. Enumeration: 'unknown': 1, 'mdiDisabled': 2, 'notApplicable': 4, 'mdiEnabled': 3.

Table of descriptive and status information about the ports.

An entry in the table, containing information about a single port.

This object identifies the repeater which this entry contains information.

This object identifies the group containing the port for which this entry contains information.

This object identifies the port within the group for which this entry contains information. This value can never be greater than mrmCardPortCapacity for the associated group.

This object specifies the type of electrical interface made available at the interface to the card for this port. The interface does not necessarily specify what the actual media to end station is. Enumeration: 'twistedPair': 5, 'fiber': 7, 'thinCoax': 4, 'unknown': 1, 'maleAUI': 2, 'unshieldedTP': 6, 'femaleAUI': 3.

This specifies the type of the physical connector through which one would attach to this card. This is distinct from the media type. For example UTP may be connected to the port via either an RJ45 or a Telco connector. Enumeration: 'dtype-15': 6, 'telco': 3, 'unknown': 1, 'st': 4, 'rj45': 2, 'bnc': 7, 'sma': 5.

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 mrmPortAutoPartitionState for that port is frozen until the port is next enabled. When the port becomes enabled, the mrmPortAutoPartitionState becomes notAutoPartitioned(2), regardless of its pre-disabling state.) Enumeration: 'disabled': 2, 'enabled': 1.

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. Enumeration: 'partitioned': 1, 'unpartitioned': 2.

This object reflects the presence or absence of signal on this port. The signal may be either light in the case of fiber, or general link present in the case of copper. The value of this parameter is correct regardless of the state the admin state or the partition state. Enumeration: 'absent': 2, 'present': 1.

A repeater port may be enabled or disabled after a reset. This parameter indicates the default for this port. Enumeration: 'enable': 2, 'disable': 1.

This attribute determines whether and which address information is extracted from packets received on a port and forwarded to the end station database. It is recommended that this attribute be disabled for inter-repeater links to prevent the database being filled with remote information. To disable this feature for all address types write the value forwardNone (128) to this variable. Enumeration: 'forwardNone': 128, 'forwardMAC': 1, 'forwardIP': 2, 'forwardAll': 127.

Specifies whether a trap should be sent if the port partition state changes. Enumeration: 'disabled': 2, 'enabled': 1.

Specifies whether a trap should be sent if the link state changes. Enumeration: 'disabled': 2, 'enabled': 1.

Specifies whether security is an available feature on this port. Only ports that have this feature available can have an entry in the repeater security table. Enumeration: 'available': 1, 'notAvailable': 2.

This attribute determines if link pulse generating and monitoring is enabled or disabled for a 10BaseT port. The attribute may take the values of enabled (standard) or disabled (non standard). Enumeration: 'disabled': 2, 'notApplicable': 3, 'enabled': 1.

Table of performance and error statistics for the ports.

This table provides statistical and control information concerning the entire repeater.

This parameter is used as the index in this table. A modular chassis contains potentially many repeater services. Each repeater service contains a number of cards (or groups). This parameter allows one of those repeaters to be selected.

This counter is incremented by one for each frame whose OctetCount is greater than or equal to minFrameSize and less than or equal to maxFrameSize and for which FCSError is not asserted that is received by the repeater. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This counter is incremented by one for each readable frame seen by the Repeater that is addressed to a unicast (non Card) address.

This counter is incremented by one for each readable frame seen by the Repeater that is addressed to a multicast (non broadcast) address.

This counter is incremented by one for each readable frame seen by the Repeater that is addressed to the broadcast address ffffffffffff.

This counter is incremented by the octet count for each readable frame received by the repeater. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This object is the number of octets contained in valid frames that have been received on this port in which the destination field was a unicast address. The approximate minimum time for rollover of this counter is 58 minutes.

This object is the number of octets contained in valid frames that have been received on this port in which the destination was a multicast address. The approximate minimum time for rollover of this counter is 58 minutes.

This object is the number of octets contained in valid frames that have been received on this port in which the destination was the broadcast address ffffffffffff. By attaching a gauge to this counter one can monitor the port for broadcast storms. Action can then be taken to automatically recover network normal operation. The approximate minimum time for rollover of this counter is 58 minutes.

This counter is incremented by one for each frame with an FCS error that does not have a framing error and which is of legal frame size received by the repeater. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This counter is incremented by one for each frame with an FCS error that does have a framing error and which is of legal frame size received by the repeater. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This counter is incremented by one for each frame whose octet count is greater than the max frame size that is received by the repeater. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This counter is incremented by one for each carrier event whose duration is less than short event max time that is detected by the repeater. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This counter is incremented by one for each carrier event whose duration is greater than short event max time and less than valid packet min time and which does not suffer a collision detected by the repeater. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This counter is incremented by one for any CarrierEvent signal on any port of this repeater for which the CollisionEvent signal on this port is asserted. The approximate minimum time for rollover of this counter is 16 hours.

This counter is incremented by one each time a collisions occurs after valid packet min time, a late event is counted as both a collision and as a late event. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This counter is incremented by one each time a carrier event occurs whose duration is greater than the MAU Jabber Lockup Protection time. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This counter is incremented by one each time a packet has been received by this repeater with the data rate detectably mismatched from the local frequency. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

This counter is incremented by one each time the repeater has automatically partitioned any port. NOTE: This counter does not really exist. It is calculated by adding together all the port counters within this repeater.

The total number of errors which have occurred on all ports on all groups of this repeater. This counter is the summation of the values of the mrmMonCardTotalErrors counters for all of the cards in the repeater. It is the sum of the following: FCS, Alignment, Frames Too Long, Short Events, Late Events, Very Long Events and Data Rate Mismatches. As a general indicator the individual error counters are too detailed. This parameter gives a very good monitor type parameter.

This object is a summation of the number of frames (including error frames) with a length of 64 octets which were received by each port on every card of this repeater.

This object is a summation of the number of frames (including error frames) with a length of between 65 and 127 octets inclusive which were received by each port on every card of this repeater.

This object is a summation of the number of frames (including error frames) with a length of between 128 and 255 octets inclusive which were received by each port on every card of this repeater.

This object is a summation of the number of frames (including error frames) with a length of between 256 and 511 octets inclusive which were received by each port on every card of this repeater.

This object is a summation of the number of frames (including error frames) with a length of between 512 and 1023 octets inclusive which were received by each port on every card of this repeater.

This object is a summation of the number of frames (including error frames) with a length of between 1024 and 1518 octets inclusive which were received by each port on every card of this repeater.

This object allows repeater stats specific actions to be implemented. There is only one action currently defined, 'clearCounters'. Writing this value to a repeater entry will clear ALL counters in this repeater. That include port stats, card and repeater totals. Enumeration: 'clearCounters': 1.

This table contains parameters about the various repeater cards within the chassis. The table is indexed using the 'serviceIndex' for the repeater and the slot number within that repeater.

Status information and control variables for the ports on a single card.

This parameter is used as the first of two indices in this table. A modular chassis contains potentially many repeater services. Each repeater service contains a number of cards (or groups). In order to uniquely identify a port it is necessary to specify both the repeater service and the card within that repeater.

This is the second part of the key on this table. Having selected one of the repeaters within the chassis it is necessary to identify the card within that repeater.

This counter is incremented by one for each frame whose OctetCount is greater than or equal to minFrameSize and less than or equal to maxFrameSize and for which FCSError is not asserted that is received for any port on this card.

This counter is incremented by one for each readable frame seen by the Card that is addressed to a unicast (non Card) address.

This counter is incremented by one for each readable frame seen by the Card that is addressed to a multicast (non broadcast) address.

This counter is incremented by one for each readable frame seen by the Card that is addressed to the broadcast address ffffffffffff.

This counter is incremented by the octet count for each readable frame received by any port on this card.

This object is the number of octets contained in valid frames that have been received on this port in which the destination field was a unicast address. The approximate minimum time for rollover of this counter is 58 minutes.

This object is the number of octets contained in valid frames that have been received on this port in which the destination was a multicast address. The approximate minimum time for rollover of this counter is 58 minutes.

This object is the number of octets contained in valid frames that have been received on this port in which the destination was the broadcast address ffffffffffff. By attaching a gauge to this counter one can monitor the port for broadcast storms. Action can then be taken to automatically recover network normal operation. The approximate minimum time for rollover of this counter is 58 minutes.

This counter is incremented by one for each frame with an FCS error that does not have a framing error and which is of legal frame size.

This counter is incremented by one for each frame with an FCS error that does have a framing error and which is of legal frame size .

This counter is incremented by one for each frame whose octet count is greater than the max frame size that is received by the repeater.

This counter is incremented by one for each carrier event whose duration is less than short event max time that is detected.

This counter is incremented by one for each carrier event whose duration is greater than short event max time and less than valid packet min time and which does not suffer a collision.

This counter is incremented by one each time a collisions occurs after valid packet min time, a late event is counted as both a collision and as a late event.

This counter is incremented by one each time a carrier event occurs whose duration is greater than the MAU Jabber Lockup Protection time.

This counter is incremented by one each time a packet has been received with the data rate detectably mismatched from the local frequency.

This counter is incremented by one each time the repeater has automatically partitioned any port.

The total number of errors which have occurred on all ports of this card. This counter is the summation of the values of other error counters (for each port), namely: FCS Errors, Alignment Errors, Frames Too Long, Short Events, Late Events, Very Long Events, Data Rate Mismatches. 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.

This object is a summation of the number of frames (including error frames) with a length of 64 octets which were received by each port on this card.

This object is a summation of the number of frames (including error frames) with a length of between 65 and 127 octets inclusive which were received by each port on this card.

This object is a summation of the number of frames (including error frames) with a length of between 128 and 255 octets inclusive which were received by each port on this card.

This object is a summation of the number of frames (including error frames) with a length of between 256 and 511 octets inclusive which were received by each port on this card.

This object is a summation of the number of frames (including error frames) with a length of between 512 and 1023 octets inclusive which were received by each port on this card.

This object is a summation of the number of frames (including error frames) with a length of between 1024 and 1518 octets inclusive which were received by each port on this card.

This attribute allows all counters on this Card to be cleared. Enumeration: 'clearCounters': 2, 'noChangeCounters': 1.

Table of performance and error statistics for the ports.

Performance and error statistics for a single port.

This parameter selects one of the repeaters within the chassis. This forms the first, most significant index column. Having selected a repeater one must select a card then port within that repeater.

This attribute uniquely identifies this Card within the repeater, it is part of the index for the port table.

This attribute uniquely identifies this port within the Card, it is part of the index for the port table.

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.

This counter is incremented by one for each readable frame seen by the Card that is addressed to a unicast (non Card) address.

This counter is incremented by one for each readable frame seen by the Card that is addressed to a multicast (non broadcast) address.

This counter is incremented by one for each readable frame seen by the Card that is addressed to the broadcast address.

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.

This object is the number of octets contained in valid frames that have been received on this port in which the destination field was a unicast address. The approximate minimum time for rollover of this counter is 58 minutes.

This object is the number of octets contained in valid frames that have been received on this port in which the destination was a multicast address. The approximate minimum time for rollover of this counter is 58 minutes.

This object is the number of octets contained in valid frames that have been received on this port in which the destination was the broadcast address ffffffffffff. By attaching a gauge to this counter one can monitor the port for broadcast storms. Action can then be taken to automatically recover network normal operation. The approximate minimum time for rollover of this counter is 58 minutes.

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.

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.

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 this parameter is incremented then neither the alignment error nor the FCS error counters shall be incremented for the frame. The approximate minimum time for rollover of this counter is 61 days.

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. The approximate minimum time for rollover of this counter is 16 hours.

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.

This counter is incremented by one each time a collision is detected on this port or when the CollisionEvent signal is asserted on this port. The approximate minimum time for rollover of this counter is 16 hours.

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.

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.

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.

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.

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: FCS Errors, Alignment Errors, Frames Too Long, Short Events, Late Events, Very Long Events, Data Rate Mismatches. 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.

This object is the number of frames (including error frames) with a length of 64 octets which were received on this port.

This object is the number of frames (including error frames) with a length of between 65 and 127 octets inclusive which were received on this port.

This object is the number of frames (including error frames) with a length of between 128 and 255 octets inclusive which were received on this port.

This object is the number of frames (including error frames) with a length of between 256 and 511 octets inclusive which were received on this port.

This object is the number of frames (including error frames) with a length of between 512 and 1023 octets inclusive which were received on this port.

This object is the number of frames (including error frames) with a length of between 1024 and 1518 octets inclusive which were received on this port.

This is a high level 'smart MIB' object. This object provides a running average of the bandwidth in use. This value is calculated locally on the agent and so does not require processor bandwidth from the management station or occupy valuable network bandwidth communicating with that station. By default an agent supporting this parameter will exhibit the following characteristics: 1) The parameter will be recalculated at approx 15 second intervals 2) Every calculation period the device will read the value of mrmMonPortReadableOctets. 3) The calculation will be performed on the most recent 4 samples as follows: 4 Sum(sample(i)/(time(i) * K)) * 100/4 i=1 Sample(i) is mrmMonPortReadableOctets(i)-mrmMonPortReadableOctets(i-1) time(i) is the time between sample(i-1) and sample(i) K is the max bytes per unit time (i.e. the available bandwidth K depends on the ring speed. The value is expressed as a percentage. A default threshold exists on this average so that if a calculated average exceeds 15% a trap will be sent to the management station. Further traps will not be sent until the average drops to below 10%. A particular device may provide a means of changing the number of samples, the averaging period, threshold and threshold action if it so wishes.

This is a high level 'smart MIB' object. This object provides a running average of the bandwidth in use. The value of this value is calculated locally on the agent and so does not require processor bandwidth from a management station or occupy valuable network bandwidth communicating with that station. By default an agent supporting this parameter will exhibit the following behaviour: 1) The parameter will be recalculated at approx 15 second intervals. 2) Every calculation period the device will read the value of mrmMonPortTotalErrors and mrmMonPortReadableFrames. 3) The calculation will be performed on the most recent 4 samples as follows: 4 10000 * Sum(Errors(i)/Frames(i)) i=1 Errors(i) = mrmMonPortTotalErrors(i)-mrmMonPortTotalErrors(i-1) Frames(i) = mrmMonPortReadableFrames(i)-mrmMonPortReadableFrames(i-1) The value is an integer number of errors per 10,000 packets received by this repeater. A default threshold exists on this average so that if a calculated average exceeds 200 (i.e. 2% of frames are in error) a trap will be sent to the management station. Further traps will not be sent until the average drops to below 100 (i.e. 1% of frames are in error). A particular device may provide a means of changing the number of samples, the averaging period and threshold if it so wishes.

This attribute allows all counters on this Port to be cleared. Enumeration: 'clearCounters': 2, 'noChangeCounters': 1.

This is the last MAC address seen on this port.

This is a count of the number of times the MAC address on this port has changed. A high number of changes indicates this is either an inter-repeater link or a multi-drop segment.

This is a dummy 'smart MIB' object which is used internally by the agent to provide a running average of the bandwidth in use. It should not be accessed by a management station and is used by the logic which calculates the value of its associated object 'mrmMonPortBandwidthUsed'. See 'mrmMonPortBandwidthUsed' for a description of how the bandwidth used is calculated.

This is a dummy 'smart MIB' object which is used internally by the agent to provide a running average of the error rate. It should not be accessed by a management station and is used by the logic which calculates the value of its associated object 'mrmMonPortErrorsPer10000Packets'. See 'mrmMonPortErrorsPer10000Packets' for a description of how the error rate is calculated.

In order to ensure a clean read of the Fault table this flag should be set to clean_read when commencing to read the table and should be examined after reading the entire table. If still set to clean_read then the table read is okay, if not the table should be re-read as it has been modified during the read process. Enumeration: 'clean-read': 1, 'modified': 2.

The Fault Table.

Information relating to a single fault.

The index into the Fault table. The initial read from the table should be read as the next, from an index of 0; subsequent reads should read the next from the index returned by the previous read.

This error number for this fault log entry.

The time since startup, in milliseconds, when the fault occurred.

The number of restarts at time of fault.

This table is used to provide remote device monitoring facilities. This table allows a list of network devices to be set up and polled regularly (or only once) by a variety of protocols. The table can be configured to inform the management station(s) of devices that are not responding to polls or that have started to respond after a period of silence. The minimum effort required to do a single poll is 1. In one packet, Write the address, rate=once-only(1) and RowStatus=CreateAndGo. 2. In the next packet, read the roundTripTime. The minimum effort required to monitor a device is 1. In one packet, Write the address, rate=every-30-seconds(1) and RowStatus=CreateAndGo. 2. Wait for traps to come in.

A table used to define device monitoring.

Unique identifier of a row in the Poll Table. The actual number of rows that can be created on any particular device depends on the memory and processing resources available at the time.

This DisplayString is the network address of the device to monitor. Typically this is an IP, MAC or IPX address. The following formats can be used. IP nnn.nnn.nnn.nnn - dotted format IPX AABBCCDD:AABBCCDDEEFF - network : node

This defines the protocol to use with which to monitor the device. Writing an address to the pollAddress field causes a default pollProtocol value to be setup. The default value is derived from the format of the address - four bytes means ip(2), and 10 bytes means ipx(3) addresses. If the requested protocol is not supported or is not compatible with the pollAddress, then an error is returned when an attempt is made to set the RowStatus to active or notInService. Enumeration: 'llc': 5, 'unknown': 1, 'ipx': 3, 'learn': 4, 'ip': 2.

This defines how often a poll packet is sent to the device. If once-only(1) is chosen, then when the RowStatus is set to active, a single poll packet is to be sent. There are no re-transmissions and no traps are generated. The results of the operation can be read in the pollLastPollSent and pollRoundTripTime fields. When a reply to the poll is received, then the RowStatus is changed to notInService. For the other values, setting the RowStatus to active causes the device to be regularly polled. The operation of the poll can be monitored by reading the pollLastPollSent and pollRoundTripTime fields. After four un-successful polls a pollLostContact trap is generated. The next successful poll to the device causes a pollEstablishedContact trap to be generated. Changing RowStatus from the active state causes polling to stop - in particular changing RowStatus from active to notInService (and vice-versa) is a convenient way of stopping and starting the polls. A poll is said to have been un-successful, if no reply has been received by the time the device is due to be polled again - i.e. if the pollRoundTripTime is still zero. By convention, row 1 of the PollTable is only ever used for once-only(1) polls. The facilities of the RMON Alarm and RMON Event groups are used when regular polling is taking place. These groups perform the timing, threshold checking and trap generation. Enumeration: 'every-hour': 6, 'once-only': 1, 'every-30-minutes': 5, 'every-30-seconds': 2, 'every-5-minutes': 4, 'every-minute': 3.

This field is provided solely for the purpose of the Network Management station to allow extra information to be stored about this poll table entry. This value is not used by the device. Enumeration: 'file-server': 2, 'other': 1.

Reading this variable returns the sysUpTime at which the last poll was sent to the device. A value of 0 means that no polls have been sent or that the poll could not be sent e.g. protocol error.

This is the round trip time in milli-seconds of the most recent poll to the pollAddress device. A value of 0 means that no reply has been received from the last poll. Round trip times of less than one hundred of a second are reported with the value of 10 milli-seconds.

After each successful poll, this field is updated with some protocol specific information that was gleaned from the packet exchange. For the IPX protocol, this string contains the number of router hops made by the poll response packet. For the IP protocol, this string contains the value of Time-To-Live from the IP packet header.