CRC errors with Cisco 3548

[Cerdito]

Hi there,

I recently installed a couple of 3548 switches in my environment. After a couple of days users were complainging about errors when saving large spreadsheets etc. I noticed there were multiple CRC errors on the interfaces.

The interfaces were all set to full-100. The NICs of the PCs were set to Auto. Setting the NICs to full-100 stopped these errors.

My question is: Is this a known error with these switches? I thought that a NIC set to Auto would have no problems with a port hardcoded to full-100. Am I wrong?

 

[RookThis]

Sounds like the two devices are not negotiating correctly. I recall reading a paper where Cisco recommended forcing the ports to a particular speed for servers, but I don't recall anything for client machines. It could be a driver issue that may require an updated one.

Here is a link that discusses negotiation:

http://www.cisco.com/warp/public/473/103.html#auto_neg

 

[RookThis]

Just out of curiosity what version of code are you running?

 

[jneiberger]

Never....ever!....hard-set one side of a link and set the other side to auto. You've almost guaranteed that the link is going to have a duplex mismatch, as you're experiencing.

Set both sides to AUTO and they should correctly negotiate to 100/Full. I do *not* recommend hard-setting speed and duplex. It is unreliable, depending on the equipment involved. You will have far better luck in the long run by setting both sides to auto, which is what Cisco now recommends, as well.

HTH,
John

 

[KiscoKid]

If you set the switch port to a speed and duplex, you are effectively disabling that port's ability to autonegotiate with the remote device. Therefore the negotiating device can quite often select a sub-optimal duplex setting.

Per the IEEE 802.3u specification, it is not possible to manually configure one link partner for 100 Mbps full duplex and still autonegotiate to full duplex with the other link partner. In all cases, both ends of the link must be set to the same value or the link may not connect or may result in duplex mismatc. Typically you can expect that setting a port to 100 full and a NIC set to autonegotiate will result in the NIC negotiating 100 half duplex.

Even though the standard allows the ability to disable autonegotiation on FastEthernet 802.3u and Gigabit Ethernet 802.3z (fiber) technologies, it is neither required nor recommended. Do not disable autonegotiation between switches or NICs unless absolutely required, as physical layer problems may go undetected and result in spanning tree loops. Disabling autonegotiation should only be used as a troubleshooting aid or temporary workaround until the autonegotiation problem is resolved.

 

[vipergg]

Yup as previous posters said , you are "wrong" in your understanding of autonegotiation . A switchport or a nic card can only autonegotiate if both sides are set as auto , if you hardcode one side and leave the other as auto then you have a speed/duplex mismatch and this causes all kinds of errors and slow response, retransmissions etcc. You have to match each end , if one end is auto then the other end has to be auto , if you hardcode one end then you have to hardcode the other end . Of course their are exceptions if you hardcoded a nic to say 100/half then the switch would negotiate this correctly because it can always sense the speed correctly but cannot sense the duplex so it would default itself to half duplex so each side would be 100/half . Best practice though is to keep each side the same.

 

[Cerdito]

Thanks guys...that's cleared it up for me, appreciate the input