Symptoms:
Facts:
Causes: lengthErrs (length errors) can increment in the CB3500 as a result of collisions occurring on half-duplex point-to-point links. If a repeater is inserted between the 2 devices (thus, not a point-to-point link), lengthErrs will be less likely to increment due to collisions.
In our experience and testing, you will no longer see length errors as a result of collisions if a repeater is inserted between the 2 devices. lengthErrs are a receive event.
That is, if a CB3500 ethernet port receives a packet which is less than 64 bytes in length (runts), or greater than 1518 bytes in length (giants), it will count a lengthErr. Collisions are a transmit event. If a device is transmitting, and detects that another device is transmitting at the same time, this is a collision.
When a transmitting device detects a collision, it will stop transmitting, and back off for a random time interval and try again. On a point to point link, when the cable or fiber is relatively short, it is probable that the collision will be detected early. For example, a transmitting device starts sending a frame.
The preamble, start delimiter, destination and source MAC addresses make it to the wire, and then it detects a collision and stops transmitting. The receiving device will begin receiving the frame, but since the frame is too short, it will count it as a lengthErr.
To verify whether the lengthErrs are a result of collisions, baseline the stats on the CB3500 and on the device it is connected to (reboot both if necessary to clear the counters. The reason this is important is that if you are looking at accumulated counts, you are not sure if any counters have wrapped.
Most counters are 32 bits in size, and will wrap at about 4.2 billion). Once you have the counters cleared or baselined, let things run for a while and check to see that the lengthErr count on the CB3500 matches (or is at least close) to the collision count on the attached device.
If the lengthErr count on the CB3500 is significantly more than the collision count on the attached device, then the attached device may be transmitting runts or giants. If the lengthErr count on the CB3500 is significantly less than the attached device's collision count, then check the fcsError and alignmentError counts on the CB3500.
These would increment for collisions that did not result in runts. On longer cables, and larger packets, a collision may occur after the device has transmitted at least 64 bytes of the packet. In these cases, the receiving device will have received more than a minimum packet size. Since the packet will have been stopped mid-stream, the receiving device will fail it's FCS check, and would in this case increment it's fcsError or alignmentError count rather than lengthErr.
When inserting a repeater (hub) in between the 2 devices, the timing changes. Also, the repeater will detect collisions and generate a jam signal out all of it's ports when it detects a collision. This changes the dynamics of the signal received by the CB3500, and it has been shown in testing (and at customer sites) to prevent lengthErrs from incrementing on collisions.
The actual reason for this has not been proven, but it is theorized to be that the ASIC on the receiving CB3500 recognizes that the runt is a result of a collisions because of the jam signal produced by the repeater. Thus, it will not increment lengthErrs.
Fixes: Functions as designed
Workaround:This error is benign in the case where it results from collisions. However, if you'd like to prevent it from incrementing, you have 2 solutions:
— David Gonzalez 2021/04/14 09:36