2524 freezing with excessive CRC/Alignment errors

[Gianluca_17]

Briefly my network layout: a 10Mb connection to router (port 1) and all other ports that connect only end-devices, are at 100Mb.
Traffic on port 1 is heavy and the switch logs "Excessive CRC/Alignment errors" (about one every 30 sec).
During heavy traffic, sometimes (about 3 or 5 times every day) the switch blocks traffic incoming and outcoming from port 1, while all others end-devices connected to the ports 2 to 24, can reach each others.
Only solution: switch reset!
Someone has any idea?
(I attache a screenshot of status overview of switch)
Thanks a lot in advance!
Gianluca

[Ralph Bean_2]

Hello Gianluca -

A very common reason for excessive CRC/alignment errors is a duplex mismatches. It is the nature of duplex mismatches that they do not significantly affect switching when the traffic levels are very low. At high levels of traffic, however, a very high percentage of traffic on a (duplex) mismatched port will be dropped due to CRC errors and late collisions.

My humble suggestion is that if you solve the root cause of the CRC errors this problem will go away.

Regards,
Ralph

[Klaus Horlbeck]

Hi Gianluca

Excessive CRC/Aligment errors have also as reason a duplex problem, you should have both sites of connection same konfiguration, nomal 10 full duplex or halv duplex an port 1 and on your router.

KH

[Carsten M]

it is possible that the traffic is to heavy.
more bandwidth to the router is a better answer for your problem (all clients 100 mb/ fullduplex).
1. way: make the routerport steady to speed 10 mb and to duplex full and so the switchport 1

2. way: take a router with a 100 mb port

good luck

[OLARU Dan]

1. "CRC/Alignment errors" are mainly due to noisy line between your router and switch. Chech the cable, connectors, wall jacks, improper/oxidized contacts. Also check that your cable passes at more than 1 meter away from fluorescent light, electrical transformers (including UPS), electrical motors, high-voltage power lines. "Late collisions" are mainly a sign of duplex mismatch.

2. If you're using a router such as Cisco 3600 series and you're linking your switch to an Ethernet port on the router, you NEED to set the switch at 10HDx, since the 10FDx will determine symptoms equivalent to what you're seeing. Also use "duplex half" on the Cisco Ethernet interface - just to make sure somebody before you did not use "duplex full". Although you will not see it in any "show" commands, the interface will work at 10HDx. For Cisco, "Ethernet" means "10Base-T". The original Ethernet specs DO NOT define duplex mode: this came with FastEthernet.

I personally tried 10FDx between 2 cisco routers: this worked FAR WORSE than 10HDx, believe it or not. So I use 10HDx now on both sides. Very strange things happen if you use FDx on one side and HDx on the other.

3. If you have a modular router and you have the possibility to purchase a 100Base-T module, put the router and the switch on 100FDx. You might want to do this if you have a fancy E3 (34.368 Mbps) WAN link to your ISP. But if you have a fractional E1 (0.064, 0.128, 0.512, 1.024 Mbps - like we mortals do :-) or a full E1 (2.048 Mbps) then you should know that your router-switch link of 10 Mbps is NOT your bottleneck. The link to your ISP is. So you might be perfectly happy with your original Ethernet link - if both ends of the link are setup correctly.

[OLARU Dan]

I also have a problem with an HP2524 switch. It is full (24 users on copper ports, mainly running 100 FDx) and is uplinked trough 100Base-FX to an HP4108GL. I did not have this problem when the switch served 23 or less people - it only appeared with a full switch.

The problem is like this: when I PuTTY on it on port 23, it won't listen to what I'm telling it to do: no Up-Down arrow, no numbers for options. It will erratically go wherever it wants: if I press 3563 to see VLAN ports, it will go to "General System Information" screen.

If I kill the PuTTY session and re-enter - all is OK.

Any ideeas?

[OLARU Dan]

It's 283 instead of 3563, which is for HP4000M.

[Ron Kinner]

While it is true that a CRC error can be caused by a noisy cable or a jabbering host the most common problem is a duplex mismatch.

The side set to Full duplex will happily transmit any time it has data. The other side set to Half duplex may be in the process of transmitting data when the other side sends and will panic and stop sending immediately since it thinks a collision is happening. That is exactly what it is supposed to do and it will report the problem as a high rate of collisions. (Actually it sends a short collision alert signal before shutting down for its random backoff time.) On a high traffic connection it may not be able to get a packet through without a collision in the maximum number of tries (16?) so will have to drop the packet.

The full duplex side will still receive the packet that the half duplex side had started but since the transmission was interrupted there will be some bits missing so the packet will not match the CRC checksum and will be discarded. Sometimes you will see these as FCS (Frame Check Sum) errors. If the collision occurs before 64 octets of data have been sent the packet will be too short to be legal and this is sometimes called a Runt.

The classic test for a duplex mismatch is to do an FTP put and get on a large file. If the times are much longer in one direction than the other then the odds of a duplex mismatch are very high.

Duplex mismatches usually happen because people do not understand how autonegotiate is required to work. They think that it will look at the other end and decide how to set up based on what it sees. This is ONLY true when the other side is also set on autonegotiate (and where the two systems are compatible - that used to be a big problem but is going away as more makers standardize). If the other side is not set to autonegotiate the setup is required by the standard to be HALF. It does not matter if the other end is FULL and we are able to detect it as such. The standard says Thou Shalt be HALF DUPLEX! I think the original idea was to avoid accidentally setting a link to FULL when everyone else was half which could kill everyone on the Hub (tho has only a locally limited effect on a switch which the standard predates).

Some switches will take a port out of service if it sees too many errors. I guess it's a way of getting your attention but it seems a bit drastic to me. Usually you can tell it not to do that if you don't want it to. Others will take it out of service for x seconds and then reset it.

If yours likes to just take an errored port out of service then you can probably get it back in service by:

config t
int e 1
disable
enable
exit

Tho if the duplex is wrong you would be better off doing:

config t
int e 1
disable
speed-duplex 10-half
enable
exit
write memory

Ron

[OLARU Dan]

Frames less than 64 bytes long (packet short) + CRC errors are most likely due to collisions. But the vast majority of the causes for CRC/Alignment errors are hardware related: bad cabling, bad NICs. Here are some web links about Ethernet errors:

http://www.synapse.de/ban/HTML/P_LAYER2/Eng/P_lay218.html
http://support.3com.com/infodeli/tools/netmgt/tncsunix/product/091500/c11ploss.htm


See this, about some problems with switches:

http://www.enterasys.com/support/techbltn/tb1297-9.html
http://www.geocrawler.com/archives/3/435/1999/7/0/2408231/
http://mail-index.netbsd.org/netbsd-bugs/1997/10/27/0002.html

This excerpt:
"
CRC/ Alignment Errors
Cyclic redundancy check (CRC)/ alignment errors generally indicate improper byte-alignment for Ethernet packets. CRC errors greater than two percent of overall traffic require attention. Most commonly CRC errors can be isolated to a particular workstation with a faulty network interface card. Alternatively, a faulty transceiver, cable, or hub port can be responsible for CRC errors.
If CRC errors cannot be isolated to a unique workstation address, cabling is the likely cause. Faulty connectors, improper grounding of thin coax wiring, or defective wiring concentrators could be the root problem.
"
was taken from here:

http://www.mug.jhmi.edu/mirrors/InfoAlley/0896/08/physical.html


I think all this supports what I posted earlier on this thread.

[OLARU Dan]

Giani,
There is a new firmware release for HP 2524 here:

http://ftp.hp.com/pub/networking/software/J4812522.zip

Ciao,
Dan