Speed 100 / Duplex Full Packets - FCS-Err Rcv-Err

xq1xq1xq1 · ‎02-25-2011

Hi Everyone,

I just passed my BCMSN exam and I am trying implement a network at my church using 2960 lanlite switches.

One of my PCs in the network was having FCS-Errs - I ended up fixing the PC NIC to 100/Full and set the switch port to speed 100 / duplex full.

This seemed to fix my problem.

I then thought that this should be good for the entire network so I fixed all ports to 100 / Full.

This is where my confusion comes in.

I majority of the other PCs started getting FCS-Errs - and by the boatload.

I work for an ISP and in general we nail up our switch to switch links to 100 Full.

Can anyone shed some light as to why nailing up the ports to 100/Full is causing FCS-Errs??? Help!

My little brain is stumped.

Thanx so much!

-John

lgijssel · ‎02-25-2011

Classical problem! Either leave both sides at auto-neg or fix them both.

When one side has fixed speed/duplex and the other side does auto/auto, the latter will end up in half duplex mode.

http://www.cisco.com/en/US/tech/tk389/tk214/technologies_tech_note09186a0080094781.shtml

Congrats with your BCMSN!

regards,

Leo

glen.grant · ‎02-26-2011

As Leo said if you only changed the switch side to 100/full you now have speed/duplex mismatches on any pc nic that was set to auto. This cause all kind of fcs errors as the pc nic will now negotiate to half duplex . As a rule unless you are having a specific problem leave things as auto/auto , its pretty reliable nowadays even between cisco gear though hardcoding interswitch links is fine as long as you do both sides.

Peter Paluch · ‎02-26-2011

Hello,

To add to great Leo's and Glen's answers, you have to be aware of a non-obvious problem: when you hardcode both the speed and duplex, many (but not all - that's where the great deal of the confusion comes in!) NIC controllers deactivate the autonegotiation altogether, instead of advertising only the hardcoded speed and duplex as the only available operating mode. The result is that the opposite device can sense the speed because the link coding is distinct for each speed, but the duplex setting cannot be sensed and thus the opposite device falls back to half duplex. And voilá - here you have the duplex mismatch if you hardcoded the port to the full duplex.

The Catalyst switches themselves differ in this behavior. For example, on 3560, with hardcoded speed and duplex, the autonegotiation is turned off. On 3560V2, the autonegotiation remains on and advertises only the hardcoded speed and duplex.

This all boils down to the recommendation both Leo and Glen gave you - either leave both ends of a link on auto/auto, or set both speed and duplex on both ends statically. Doing any other combination is calling for trouble - as you have experienced yourself.

Best regards,

Peter

xq1xq1xq1 · ‎02-26-2011

Hi All,

Thank you so much for the fantastic advice.

In my situation what I had done was to fix the PC NIC to 100/FULL as well as the 2960 switch port to 100/FULL as was suggested above. This is what I figured was the correct method of doing this.

It was not until that I had fixed both sides (PC and Switch Port) to 100/FULL that these boat loads of FCS-ERRs started coming out.

Some PCs ran error free but some others started generating, in spurts, FCS-ERRs and RCS-ERRs.

It was only after I set the PC and the Switch port to Auto that the FCS-ERRs on the troublesome PCs that the FCS-ERRs stopped.

I should mention that the reason that I hardcoded the Speed and Duplex to 100/FULL was do to one mission critical computer runing FCS-ERRs until I locked the PC NIC and Switch Port to 100/FULL. I then figured that this should be the 'standard' setting to use except for the fact that some PCs started generating the FCS-ERRs.

Am I missing something else that could be causing this behaviour?

Any suggestions would be greatly appreciated!

Thanx,

John

Message was edited by: jp jp

Peter Paluch · ‎02-26-2011

John,

If I understand you correctly then you are saying that:

When you set both the PC and the switchport to 100/FullDuplex statically, you had transmission errors
When you set them both to autonegotiation, the transmission errors stopped appearing

Is this correct? Now, I wonder: with the autonegotiation on both ends of the link, what was the resulting negotiated operating speed and duplex of the link?

Best regards,

Peter

xq1xq1xq1 · ‎02-26-2011

Hi Peter,

You got it!

For some PCs with both sides fixed to 100/FULL running clean,

but,

For other PCs with both sides fixed to 100/FULL, they are running major FCS-ERRs and RCV-ERRs.

With AutoNegotiation, the Cisco Switch is reporting 100/FULL.

The one PC that started me going down this path (see my edited note in my last post) is also reporting 100/FULL on the Cisco Switch.

I really appreciate you helping me try and narrow down this issue.

Thanx,

John

Message was edited by: jp jp

Peter Paluch · ‎02-26-2011

Hi John,

Well, this is strange. What you are telling me is that when the 100/FD was autonegotiated, the link was working fine, but when the 100/FD was set statically on both ends of the link, transmission errors occured.

What confuses me here is that despite the method of arriving at the operational mode of 100/FD - either by autonegotiation or by static setting - the actual process of communication is identical afterwards. I do not see how a static 100/FD setting on both ends could result in FCS errors while the same 100/FD setting negotiated automatically produces an error-free link.

Nevertheless, how would you personally describe the status of your cabling? Do you believe it is cabled and connected correctly, upholding the existing regulations about structured cabling of Cat5e or higher? Was the network tested using a certificating cable tester to prove that it meets the requirements of Cat5e or higher? Perhaps we are hunting down sporadic issues that are more related to the physical layer than to the negotiation.

Best regards,

Pete