HP

HP Management Agents for Servers (NIC component)

English
  NIC Subsystem  |  Token Ring Statistics   

Token Ring Statistics

»Table of Contents
»Index
»NIC Subsystem
»NIC Controller Information
»NIC Interface Information
»Ethernet Statistics
Token Ring Statistics
»Printable version
»Glossary
»Using Help
» Token Ring Statistics
» Related Topics

Token Ring Statistics

The following Token Ring Statistics are displayed in this window. Information that cannot be obtained from the hardware or support software is indicated by N/A.

  • Lost Frame Errors - indicates that a sending station was unable to complete the transmission because the frame that was sent never returned to the originator. When a station sends a frame, that frame normally returns after completing the circuit. If the frame does not return intact, this error will increment.

    These errors may occur if another station inserts itself into a ring or removes itself from the ring, interrupting the clock cycle. Large noise spikes, such as lightning, could also cause these errors.

    If you see excessive Lost Frame errors, there may be a problem with the Multi-Access Unit (MAU) or hub. Use a network analyzer to isolate the problem area.

    OID: 1.3.6.1.2.1.10.9.2.1.7 - dot5StatsLostFrameErrors

  • Internal Errors - indicate that the NIC has detected a problem with itself. Run the diagnostics from the NIC manufacturer to verify that a problem exists. You may need to replace the NIC.

    OID: 1.3.6.1.2.1.10.9.2.1.6 - dot5StatsInternalErrors

  • Receive Congestion - increments when a station receives a frame, but cannot copy the data for some reason. The station may not have enough buffer space to copy the data.

    Excessive traffic to a specific station may cause Receive Congestion Errors. If certain stations continue to experience Receive Congestion Errors, check the network design. It is also possible that the software on the PC is not running efficiently enough to handle interrupts from the network.

    OID: 1.3.6.1.2.1.10.9.2.1.8 - dot5StatsReceiveCongestions

  • Token Errors are reported by the active monitor for one of the following reasons:

    • The active monitor detects that a frame has gone around the ring more than once, either because the sender removed itself from the ring before stripping the frame, or because there are two active monitors present on the network. The active monitor will purge the network and clear the condition in either case.

    • A station reserved a token at a high priority and then removed itself from the network. The active monitor will detect the token traversing the ring more than once as it searches for the station that requested the high priority. The active monitor will purge the ring.

    • The active monitor detects that no token or frame is received for 10 milliseconds. When several stations insert or remove themselves from the ring at the same time the counter will escalate rapidly. This condition could occur when the power is off temporarily and then returned. In this example, several stations would try to insert themselves onto the ring at the same time, disrupting the signal. If this condition appears to occur for no known reason, however, check your Multi-Access Unit (MAU). Use a network analyzer to isolate the problem area.

    • The active monitor detected a token that was returned to it containing a token violation. In this case, you will also see line errors along the ring. The active monitor will purge the ring, but also check for the following:

      • Failing cable - Packet data traveling through shorted or damaged cabling may become corrupt before reaching the destination station and cause line errors and token errors.

      • Segment not grounded properly - Improper grounding of a segment may allow ground-induced noise to corrupt data flow and cause line errors and token errors.

      • Noisy cable - Interference or noise produced by motors or other devices can distort the signals and cause CRC/Alignment errors, which will increment the line error count and may cause token errors.

    If you cannot find the problem after checking the above conditions, use a network analyzer to isolate the station corrupting the frame. The analyzer should indicate which station is causing the problem and let you know if the NIC should be replaced.

    OID: 1.3.6.1.2.1.10.9.2.1.10 - dot5StatsTokenErrors

  • Frame Copy Errors - occurs when a NIC receives a frame that is destined exclusively for itself, but the NIC detects that a station upstream has set the address recognize bit and copied the frame. This means that you have two NICs with the same network physical address, and you must change one of the addresses. Each NIC must have a unique network physical address.

    OID: 1.3.6.1.2.1.10.9.2.1.9 - dot5StatsFrameCopiedErrors

  • Transmit Beacons - increments when there is a break on the Token Ring or you have a defective NIC on the ring. If you see even one transmit beacon, investigate the problem immediately.

    The break is detected by the station immediately downstream of the break when that station stops receiving tokens or frames. This station then sends a series of beacon frames around the ring to notify the ring that a break has occurred immediately upstream.

    A network analyzer will help to pinpoint the station that is sending the beacon frames and identify which station is directly upstream of the station sending the beacon.

    OID: 1.3.6.1.2.1.10.9.2.1.14 - dot5StatsTransmitBeacons

  • Abort Transmit Errors - increments when a station transmits an abort delimiter while transmitting.

    An aborted transmit occurs if the NIC is unable to complete the transmission of a frame that it has already started onto the network. For example, if the NIC was unable to access its packet buffer memory fast enough to keep pace with sending the data stream onto the wire, the NIC will abort the transmit. When a NIC aborts the transmit, it places a special bits sequence on the wire known as an abort delimiter, which signals to other stations on the Token Ring that the packet data is invalid.

    Many NICs do not support aborting transmits, preferring instead to shut down with a fatal error and remove the NIC from the ring. Those NICs that support aborting transmits will report this error.

    If this error is reported, run the diagnostics from the NIC manufacturer to see if there is a problem.

    OID: 1.3.6.1.2.1.10.9.2.1.5 - dot5StatsAbortTransErrors

  • Removes - increments when the manager station issues a "Remove station from the ring" command. See your network administrator to determine why the station was removed from the ring.

    OID: 1.3.6.1.2.1.10.9.2.1.17 - dot5StatsRemoves

  • Soft Errors - increments when the NIC detects recoverable errors. These errors are typically reported when nodes enter and exit the Token Ring. These are considered normal, nonfatal errors. The NIC will correct the error, but the error will be reported to the LAN management station and counted. Check other error counts to determine if a serious error has occurred.

    OID: 1.3.6.1.2.1.10.9.2.1.1 - dot5StatsSoftErrors

  • Recoveries - increments any time the active monitor changes from one station to another. The active monitor changes when the current active monitor removes itself from the network or has detected a problem with itself. If this item increments excessively, check the other error counts to see if a problem exists.

    OID: 1.3.6.1.2.1.10.9.2.1.15 - dot5StatsRecoverys

  • Hard Errors - usually happen in conjunction with transmitted beacons. It increments each time a station receives or sends a beacon, thus occurring numerous times when a beacon is being transmitted.

    If the Transmit Beacons count is incrementing as well, then this interface is sending beacons on the network. If Transmit Beacons is not incrementing, then this interface is not transmitting beacons, but detecting beacons being sent.

    A network analyzer will help to pinpoint the station that is sending the beacon frames and identify which station is directly upstream of the station sending the beacon.

    Perform the following steps:

    1. Check the station immediately upstream from the station that is sending the beacon. Swap out the transceiver, transceiver cable, and transceiver attachment point, one at a time. If you find a faulty component, replace it.

    2. Check the receiver on the station that sent out the beacon frames to ensure that it is capable of receiving frames. If the receiver is not working properly, the NIC may have erroneously assumed that there were no frames or tokens. Run diagnostics from the NIC manufacturer to help you pinpoint the problem.

    3. Check the cabling for breaks or disruptions.

    4. Your Multi-Access Unit (MAU) or hub may be at fault. Use the diagnostics from the MAU manufacturer to determine if a problem exists.

    OID: 1.3.6.1.2.1.10.9.2.1.12 - dot5StatsHardErrors

  • Lobe Faults - are caused when the network is in test mode and finds a problem with one of the lobe wires running from the Multi-Access Unit (MAU) to each station. The network enters test mode under two conditions:

    • When a station powers on and attempts to insert itself onto the network, the test on the lobe wire will begin. If the test fails, a lobe wire fault occurs.

    • If hard errors occur, the NIC will enter test mode. If the self-test fails, a lobe wire fault will occur.

    If a Lobe Wire Fault occurs, check for the following:

    • Failing cable - Make sure that your lobe wire is working and intact.

    • Failing repeater, transceiver, or controller card - Repeaters, transceivers, and controller cards can disrupt the network signal, transmit erroneous signals on the wire, or ignore incoming packets. Perform the following steps:

      1. If your NIC is continuously transmitting, it will cause erroneous signals or "jabber." Replace a jabbering receiver to ensure proper network performance.

      2. Swap out the transceiver, transceiver cable, and transceiver attachment point, one at a time. If you find a faulty component, replace it.

      3. Your Multi-Access Unit (MAU) or hub may be at fault. Use the diagnostics from the MAU manufacturer to determine if a problem exists.

    OID: 1.3.6.1.2.1.10.9.2.1.16 - dot5StatsLobeWires

  • Line Errors - increments each time a station detects a line error. Each station either repeats or copies a frame and checks the frame for validation. If the data in the frame is corrupted, each station that detects the corrupted frame increments its own line error count.

    OID: 1.3.6.1.2.1.10.9.2.1.2 - dot5StatsLineErrors

  • Signal Loss - usually happens in conjunction with other errors, such as burst errors, token errors, line errors, and transmitted beacons. This error indicates that the station temporarily or permanently lost the clock signal on the Token Ring. Check other error conditions to determine if a serious error has occurred.

    OID: 1.3.6.1.2.1.10.9.2.1.13 - dot5StatsSignalLoss

  • Burst Errors - increments every time the adapter detects the absence of clock transitions. Burst errors occur in Token Ring networks when the signal is momentarily disrupted. Each time a station inserts itself into the ring or removes itself from the ring, a burst error may occur.

    If you detect that one station has an abnormally high burst error count compared to other stations, you may need to replace the NIC. For example, if most stations average 2 burst errors per day, and one station shows 27, that station may have a faulty NIC. The station that is directly downstream of the device causing the problem usually detects the burst error. Use the Upstream Address of the station detecting Burst Errors to determine the faulty NIC.

    If excessive burst errors continue to occur on the ring, you may need to replace the Multi-Access Unit (MAU) or hub. Use a network analyzer to isolate the problem area.

    OID: 1.3.6.1.2.1.10.9.2.1.3 - dot5StatsBurstErrors

  • Frequency Errors - occur when a station detects that the active monitor is not working in the proper frequency. Ring Recovery will occur and another active monitor will be chosen.

    The active monitor generates a clock signal, which it passes to each standby monitor. The standby monitor compares this signal to its own reference clock. If the signal is not within the proper frequency boundaries, a frequency error occurs.

    Not all stations will report this error because not all NIC manufacturers support this feature. A frequency error is not common. If there is a problem with the active monitor, other errors usually occur that help you determine the station that is at fault.

    If you see frequency errors, use a network analyzer to determine which station was the active monitor causing the problem. Remember when you use your analyzer that the station with the problem is not the current active monitor the active monitor experiencing the problem was replaced when the problem was detected.

    OID: 1.3.6.1.2.1.10.9.2.1.19 - dot5StatsFreqErrors

  • AC Errors - are also referred to as Address Recognized Indication/Frame Copied Indicator (ARI/FCI) errors. This error occurs when a station detects that an upstream station did not correctly set the bits on a frame.

    If an AC error occurs, perform the following steps during your next planned maintenance:

    1. Ensure that the NIC is compliant with the protocol in use. The NIC that did not set the bit (the station directly upstream of the station that reported the problem) is not participating in the low level protocol and may not be completely compliant with 802.5 protocol.

    2. Replace the NIC to see if the problem still occurs.

    OID: 1.3.6.1.2.1.10.9.2.1.4 - dot5StatsACErrors

  • Single Station - increments when the interface senses that it is the only station on the ring. This will happen if the interface is the first one up on a ring, or if there is a hardware problem. Check for the following:

    • Your Multi-Access Unit (MAU) or hub may be at fault. Use the diagnostics from the MAU manufacturer to determine if a problem exists.

    • Check the cable between the NIC and the MAU. Replace the cable if necessary.

    • Run the diagnostics from the NIC manufacturer to determine if there is a problem with the NIC. Replace the NIC if necessary.

    OID: 1.3.6.1.2.1.10.9.2.1.18 - dot5StatsSingles

Related Topics

» NIC Subsystem - NIC Controller Information