Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

soft errors on a token ring

Can anyone provide me with a reference for interpetating soft errors on a token ring interface?

New Member

Re: soft errors on a token ring

New Member

Re: soft errors on a token ring


The attached may help. This was taken from the help sections of Network Instruments Observer Product.

Type I Soft Errors

Line Errors - these are the Token Ring equivalent of Ethernet CRC errors. Every station performs a CRC check on incoming frames and, when it finds inconsistency between the frame checksum number and the checksum itself, it reports this error. Line Errors are often present on a busy network. However, if a station continuously reports Line Errors, it usually indicates a bad upstream neighbor’s adapter.

Internal Errors - this error will be seen when a station discovers a recoverable hardware error. If an adapter consistently reports Internal Errors, it may indicate that the adapter is beginning to fail.

ARI/FCI Set Error - this is reported when a station detects two "Standby Monitor Present" frames with the ARI/FCI bit set to zero without the intervention of the Active Monitor during a ring poll process. This error is rare.

Receive Congestion Errors - these are reported by a station which has an insufficient buffer to copy the packets addressed to it. If an adapter consistently reports Receive Congestion Errors, this can be an indication of: either a hardware or software problem on the reporting station, a defective (noisy) connection to the hub or MAU upstream of the station (this can overfill the receiving circuitry of the adapter).

Frame Copied Errors - these are reported when a ARI/FCI bit is already set in the frame addressed to the station. This indicates the presence of two network cards with the same address on the network. This can happen on bridged multi-ring networks with locally assigned Token Ring addresses.

Type II Soft Errors

Burst Errors - these are reported when a station detects a signal loss for at least five halfbyte cycles.

Burst Errors are encountered quite often during normal Token Ring operation and usually occur when a station joins or leaves the ring. If this error persists, it may indicate a hardware problem on an upstream neighbor of the reporting adapter or its MAU or hub relays. Burst errors are usually accompanied by Line, Lost Frame or Token errors.

Abort Delimiter Transmitted Error - this is transmitted when a station transmits an Abort Delimiter for any reason. Active Monitor in this case detects the interruption in the token protocol and purges the ring.

Lost Frame Errors - when a station transmits a frame trailer, it sets a timer which specifies how much time to wait for the frame trailer to return from upstream. When the frame returns, the station strips it from the network and takes an appropriate action depending on whether FCI bit is set or not. If the station does not receive the same frame trailer before the timer expires, it considers the frame lost and increases the lost frames count.

Token Errors - these are reported by the Active Monitor when it detects one of the following conditions:

Type III Soft Errors

Lost Monitor Errors -these occur when an Active Monitor (AM) leaves the ring or becomes inoperative. It is reported by the Standby Monitor which discovered the AM missing. Remaining Standby Monitors begin the Monitor Contention process to elect a new Active Monitor.

Frequency Errors - this is the result of a bad Active Monitor clock. This error is usually resolved by Monitor Contention during which a different Standby Monitor becomes the Active Monitor.


An adapter transmits Beacon frames when it detects silence on the cable (no tokens or data frames from the upstream neighbor).

The adapter sends beacons downstream to alert all other devices. If the upstream neighbor receives a beacon from it’s downstream neighbor and the Beaconing condition was caused by a temporary hardware fault, the downstream neighbor will eventually hear a signal from upstream. Otherwise, these two adapters remove themselves from the ring and try to reattach. In the case of a cable or hardware problem, one of the adapters will fail to reattach and the network will resume normal operation. This is called "resolved Beaconing condition". If the Beaconing condition fails to resolve itself, it may require identifying the parties at fault and taking manual recovery actions.

CreatePlease login to create content