from a previous thread:
FCS errors:
In the CMM all my BH are showing high number of FCS errors, 1-6million. All my AP’s are showing 0 or on the off case 1.
Below are 3 definitions for Alignment, FCS and CRC errors.
Alignment Errors:
An Alignment Error indicates a received frame in which both are true:
The number of bits received is an uneven byte count (that is, not an integral multiple of
The frame has a Frame Check Sequence (FCS) error.
Alignment Errors often result from MAC layer packet formation problems, cabling problems that cause corrupted or lost data, and packets that pass through more than two cascaded multiport transceivers. See “FCS Errors” for more information about interpreting Alignment Errors.
FCS Errors
Frame Check Sequence (FCS) Errors, a type of CRC, indicate that frames received by an interface are an integral number of octets long but do not pass the FCS check. The FCS is a mathematical way to ensure that all the frame’s bits are correct without having the system examine each bit and compare it to the original. Packets with Alignment Errors also generate FCS Errors.
Both Alignment Errors and FCS Errors can be caused by equipment powering up or down or by interference (noise) on unshielded twisted-pair (10BASE-T) segments. In a network that complies with the Ethernet standard, FCS or Alignment Errors indicate bit errors during a transmission or reception. A very low rate is acceptable. Although Ethernet allows a 1 in 108 bit error rate, typical Ethernet performance is 1 in 1012 or better
CRC Errors
A Cyclic Redundancy Check (CRC) Error is an RMON statistic that combines “FCS Errors” and “Alignment Errors”. These errors indicate that packets were received with:
A bad FCS and an integral number of octets (FCS Errors)
A bad FCS and a non-integral number of octets (Alignment Errors)
CRC Errors can cause an end station to freeze. If a large number of CRC Errors are attributed to a single station on the network, replace the station’s network interface board. Typically, a CRC Error rate of more than 1 percent of network traffic is considered excessive.
In my case it could me that the CRC errors are due to FCS errors as I am not seeing Alignment errors.
Our cables are shielded, does not affect AP’s, and kit is not be powere up and down. I will continue my investigations, but if anyone can help/advice I would greatly appreciate it.
I’m still looking into this… and what I find is that the BH that have more traffic are the ones showing higher number of errors…
I posted a similar thread on another forum for WISPs, and the feedback I got was that FCS errors can be caused by RF interference.
I guess this is a question for Canopy Support, is it possible that a packet to become corrupted in way that if passes the Canopy RF test but then fails the FCS test by the CMM, I know on a previous thread Support was adament that CRC errors can not be passed across from the RF.
At this stage the corruption on the RF or BH overload are my two strongest theories, but I am keeping an open mind and will be running some tests.
Can others users please check their FCS errros on their CMM and see if they are seeing anything.
thanks
Hey!
In my experience, these errors are most often the result of
A) Duplexing mismatches between the CMM Micro and whatever it’s plugged into (AP units, BH unit)
B) Induction over long wire runs, even on shielded cable.
Typically, the fix is to hard-code a duplexing mode into each end of the link (Don’t, as a for instance, hard-code one end to 10FD and leave the other end to auto-negotiate).
In particular, I solved a similar problem on a tower (big commercial job with all kinds of stuff on it) by hard-coding all the AP/CMM Micro connections to 10FD: Even though the links were auto-negotiating to 100FD, the collisons were ridiculous, and the service at the client end reflected that. After I made the switch to 10FD, all the errors went away, and my most tempermental customers off that tower called the next day to tell me how dramatically the service had improved overnight.
mmm… I will try that and see what happens… doesn’t explain why it only affects the BH, as the actuall hardware is the same as the AP’s…
thanks
Forcing a lower data rate usually corrected these errors on my system as well. Subsequent site inspection and re-termination usually permitted a return to higher rates.
well that didn’t work…
gonna try it on a few more BH’s… change the cable… and then see what happens