FCS and beyond
6.2.8 This page will focus on additional errors that occur on an Ethernet network.
A received frame that has a bad Frame Check Sequence, also referred to as a checksum or CRC error, differs from the original transmission by at least one bit. In an FCS error frame the header information is probably correct, but the checksum calculated by the receiving station does not match the checksum appended to the end of the frame by the sending station. The frame is then discarded.
High numbers of FCS errors from a single station usually indicates a faulty NIC and/or faulty or corrupted software drivers, or a bad cable connecting that station to the network. If FCS errors are associated with many stations, they are generally traceable to bad cabling, a faulty version of the NIC driver, a faulty hub port, or induced noise in the cable system.
A message that does not end on an octet boundary is known as an alignment error. Instead of the correct number of binary bits forming complete octet groupings, there are additional bits left over (less than eight). Such a frame is truncated to the nearest octet boundary, and if the FCS checksum fails, then an alignment error is reported. This is often caused by bad software drivers, or a collision, and is frequently accompanied by a failure of the FCS checksum.
A frame with a valid value in the Length field but did not match the actual number of octets counted in the data field of the received frame is known as a range error. This error also appears when the length field value is less than the minimum legal unpadded size of the data field. A similar error, Out of Range, is reported when the value in the Length field indicates a data size that is too large to be legal.
Fluke Networks has coined the term ghost to mean energy (noise) detected on the cable that appears to be a frame, but is lacking a valid SFD. To qualify as a ghost, the frame must be at least 72 octets long, including the preamble. Otherwise, it is classified as a remote collision. Because of the peculiar nature of ghosts, it is important to note that test results are largely dependent upon where on the segment the measurement is made.
Ground loops and other wiring problems are usually the cause of ghosting. Most network monitoring tools do not recognize the existence of ghosts for the same reason that they do not recognize preamble collisions. The tools rely entirely on what the chipset tells them. Software-only protocol analyzers, many hardware-based protocol analyzers, hand held diagnostic tools, as well as most remote monitoring (RMON) probes do not report these events.
The next page will describe Auto-Negotiation.
Tuesday, January 26, 2010
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment