|
Token Ring Soft Error Types The ten soft error types are as follows:
Internal errorTroubleshoot the addresses in the assigned fault domain by going to page 2 . Keep in mind that the reporting station NIC may be the failure cause.These errors signify that the reporting RS has encountered a recoverable internal error. If this particular error is recorded frequently, the reporting station NIC may be operating in marginal condition. Any available diagnostics should be run on the particular RS, and to be conclusive you can remove the station from the ring and rerun a protocol analysis session. If one internal error is encountered the NIC may have failed and should be troubleshot. Burst error. Keep in mind that burst errors can occur when ring stations leave or enter the ring, causing ring reconfigurations, which are not of a serious nature. Check the protocol analysis session trace for ring reconfigurations occurring directly before the burst error. If no ring reconfigurations are occurring, troubleshoot the addresses in the assigned fault domain by going to page 2. Remember, these errors signify that the reporting RS encountered a signal error transition that has been detected in the Token Ring cabling medium. Again, normally, these errors occur when RSes leave or enter the ring, which causes ring reconfigurations. If the error is due to a ring reconfiguration, you can check the protocol analysis session trace for the Neighbor Notification process occurring directly before the burst error; for example, you should see a Report NAUN Change MAC frame present before the error. If the burst error count exceeds the level of 20 in one error packet and no stations have entered or left the ring, this may indicate a bad lobe cable which should be checked with a Time Domain Reflectometer. Basically, if this particular error is recorded frequently and no ring reconfigurations are occurring, it is possible that the cabling medium has a problem. In this case, troubleshoot the fault domain involved. Line error. These errors can occur when ring stations leave or enter the ring, which causes ring reconfigurations, or because of simple ring recoveries. Check the protocol analysis session trace for the ring reconfigurations occurring directly before the line error. If no ring reconfigurations or ring recover ies are occurring, troubleshoot the addresses in the assigned fault domain by going to page 2 . Keep in mind that the presence of a line error can be due to a failure cause located in the reporting station's NAUN. These errors signify that the reporting RS checksum process has detected a checksum error in a specific received data frame or token, after transmission of the respective token or data frame. When this error occurs, it usually is related to ring recoveries or simple ring reconfiguration. Again, sometimes the presence of a line error can be due to a failure cause located in the reporting station's NAUN. If the line error count exceeds the level of 20 in one error packet and no stations have entered or left the ring, this may indicate a bad NIC which should be troubleshot. If line errors arise often, test the reporting station's NAUN. This can be done with diagnostics or by removing the station from the ring and rerunning a protocol analysis session. Abort delimiter transmitted error. Troubleshoot the addresses in the assigned fault domain by going to page 2. Keep in mind that the reporting station NIC may be the failure cause. This error signifies that the reporting RS has encountered a recoverable internal error that forced it to transmit an Abort Delimiter frame. If this error is recurrent at rates of more than 10 in one error packet or just is continuously being generated from one ring station, the reporting station NIC may be operating in marginal condition. Again, diagnostics should be run on the particular RS. Also to be conclusive, the suspected station can be removed from the ring and a protocol analysis session run. AC error. Troubleshoot the addresses in the assigned fault domain by going to page 2 . Keep in mind that the presence of an AC error can be due to a failure cause l ocated in the reporting station's NAUN. This error indicates that the reporting RS's NAUN could not successfully set the address recognized or frame copied bits in the newly transmitted frame, even though it has actually completed the copy of the bits on its last frame received. If this error happens often, it is possible that the reporting station's NAUN has a failure. It is also possible that a common destination station is returning the frame improperly to the source. If this error is captured at counts of even one in an error packet, the NAUN and destination devices of the reporting station should be tested with diagnostics or by removing the stations from the ring and rerunning a protocol analysis session. On router and bridge based networks if a large group of ring stations are experiencing this problem on one common ring, check the router and bridge NICs through diagnostics. Lost frame error. Troubleshoot the addresses in the assigned fault domain by going to page 2 . This error indicates that an originating RS generated a frame onto the ring to a speific address and did not receive the frame back. This error may be detected by either the active monitor or the originating RS. Because the RS did not receive the frame back, it can-not release the token, which causes the active monitor to initiate ring recovery and issue a new token. Also because the station did not receive the frame back, the source that may have caused the frame to become lost is not directly identifiable. If this type of error occurs frequently, attempt to troubleshoot the fault domain surrounding the reporting RS, and also continue to rerun the protocol analysis session to identify any repetitive patterns of this error. Receiver congestion error. Troubleshoot the addresses in the assigned fault domain by going to page 2 . Keep in mind that a receiver congestion e rror usually occurs because of lack of buffer space within the NIC on the destination ring station. This error indicates that the reporting RS could not receive a frame addressed to its address. This usually occurs because of lack of buffer space within the NIC on the destination RS. The destination station NIC may be at fault, but this error normally occurs because a specific network software application is causing the particular destination RS to be flooded with data too frequently. Receiver congestion errors occur often on certain network file servers. If the cause is related to the flooding of data and is a frequent occurrence, and something is not eventually done to alleviate the problem, the NOS may have operational failures. This problem usually can be remedied in either of two ways: the network software application access can be redesigned, or an NIC with larger buffer space can be installed in the particular destination RS. Frame copied error. Check the ring for duplicate address as related to the reporting ring station's adapter. If no duplicate address is found, troubleshoot the addresses in the assigned fault domain by going to page 2. This error signifies that the reporting RS has copied a frame that may have the same address as its own (a duplicate address.) It also is possible that the frame was corrupted on the ring. If this error occurs frequently, and there is not an assigned duplicate Token Ring address on the ring, check the reporting RS's adapter. Frequency error Troubleshoot the ring station assigned the active monitor role and the reporting ring station's NAUN for a possible failure by going to page 6. This error signifies that the reporting RS is attempting to receive a frame that does not contain the proper ring-clock frequency. Because the active monitor is responsible for maintaining the Ring Master Clock, it is possible that t he active monitor has encountered an error. If this error occurs frequently, check the active monitor and the reporting RS's respective NAUN. It is also possible that a power problem or MRP with bad grounding can induce intermittent frequency errors. Again, run any available diagnostics, remove any suspected RS from the ring, and rerun a protocol analysis session. Token error. Troubleshoot the addresses in the assigned fault domain by going to page 2. A token error is generated only by the active monitor in the event that it does not detect a token on the ring. Because the active monitor cannot pinpoint the reason for the token being lost, the cause cannot directly be associated with any particular network component. The active monitor initiates ring recovery and issues a new token. Also, when a token error occurs because of the ring recovery process, it is highly possible that other RSes will detect and generate burst, line, and lost frame errors onto the ring. If token errors occur frequently, continue to run a protocol analysis session to identify any repetitive patterns of this error. November 15, 1996 |