Ethernet errors tracked by Observer
Observer tracks many Ethernet errors, including alignment errors, CRC errors, collisions, runts, and jabbers.
Alignment Errors
Ethernet Alignment errors are detected when a packet is not "aligned" on a phase boundary.
For timing purposes, the network adapter card assembles and sends a "preamble" for Ethernet packets. Then timers on both Ethernet adapters (sending and receiving) synchronize (agree) on phase timing, and calculate a phase position to begin the actual packet. This phase position is used so that the receiving adapter can know when the packet begins, and how the packet should correspond to the actual signal wave.
Alignment errors can be caused by a number of factors. Typically, they are caused by a previous collision. When a collision occurs, either a CRC error or an Alignment error almost always results. In the case of an Alignment error, if the collision occurs during a transmission after the preamble, the position of the resulting signal with respect to the phase of the wave is incorrect. The receiving adapter acknowledges this, and the packet is discarded.
MAC Frame CRC Errors
These CRC errors are the most common, and are what most devices and analyzers are referring to when they claim a CRC error has occurred.
Ethernet packets are encapsulated in a MAC frame that contains a preamble, and a post-envelope CRC check. The Ethernet adapter on the sending station is responsible for creation of the preamble, the insertion of the packet data (addressing, protocol, data, etc.) and then calculating a CRC checksum and inserting this at the end of the packet. The receiving station uses the checksum to make a quick judgment if the packet was received intact. If the checksum is not correct, the packet is assumed to be bogus and is discarded.
MAC frame CRC errors can be caused by a number of factors. Typically they are caused by either faulty cabling, or as the result of a collision. If the cabling connecting an Ethernet Adapter or hub is faulty the electric connection may be on and off many times during a transmission. This “on and off” state can interrupt parts of a transmission, and “damage” the signal.
If a collision happens during packet transmission, the signal for the specific packet will be interrupted, and the resulting received packet will be damaged.
If the signal is interrupted partially during transmission, the CRC checksum that was calculated by the network adapter will no longer be valid and the packet will be flagged as a CRC error and discarded.
CRC errors are common on a busy network, and a small percentage does not reflect a network problem. When the percentage is large, or when a single station shows a larger percent CRC errors there is probably a problem that needs to be addressed.
Protocol CRC Checksums
Some protocols (TCP/IP for example), have a second (in addition to the MAC frame CRC checksum) checksum for data integrity purposes. This checksum is calculated on only a portion of the internal data of each packet, and can give a second and independent check for the validity of the packet's contents.
Observer calculates this checksum independent of the MAC layer CRC and displays the results in the decode display. These CRC errors are very rare and can be caused by malfunctioning software or protocol drivers.
Collisions happen when two Ethernet adapters send a signal on the Ethernet simultaneously. Ethernet networks operate under a principle known as Carrier Sense, Multiple Access with Collision Detection (CSMA/CD).
In a nutshell, this means that a station (prior to sending a packet) listens to the wire for any other traffic (it senses the wire for a carrier), if no other stations are sending, the station may proceed with sending the packet. Otherwise it must wait and repeat the carrier sensing later. During periods of heavy traffic, several stations may be waiting to send data. If two (or more) of these stations carrier sense at the same time, they may each decide that it is O.K. to send. If this occurs, a collision will result. Depending on the timing this may also cause an Alignment error, a CRC error, both or neither. Collisions also become self-perpetuating. As they begin to occur, bandwidth is wasted, and more stations must wait to use the wire, thus causing more collisions.
Collisions are a natural (at reasonable levels) and acceptable part of any Ethernet network and the busier the network, the more collisions you may see. Collisions are acceptable to a point, but after that collisions can bring your network to a virtual standstill.
Collisions are caused by either a faulty network adapter (the “sensor” is failing), or a congested network segment. If the adapter is faulty, replacement is the only option. For a congested network, segmentation is usually the best option.
Packets Too Small (Runts)
The Ethernet specification requires that all packets be at least 64 bytes long. 64 bytes is the total length, including checksum. Any packet on the wire that is less than 64 bytes is considered a “Packet Too Small”. Unfortunately, not all vendors adhere to this rule, and many send valid packets smaller than 64 bytes.
Packets Too Big (Jabbers)
The Ethernet specification requires that no packets be larger than 1518 bytes (including checksum). Any packet that is larger than this is flagged as an error and discarded. These packets are also sometimes referred to as “Jabbers”.
Packets too big are almost always caused by faulty hardware. The network adapter card in a station showing a high rate of packets too big should be replaced.