Problem with setting port to 100/full

[tschafer]

Hello to all,
We just had an interesting case. A user remarked he was having performance issues. Also the port show a high number of FCS-Errors,Rcv-Errors, and Runts. We switched his port and his performance improved no errors. The difference between the two ports was the offending port was set to 100/full. I set the offeneding port to auto/auto. Now life is good on both ports and no error are being seen.
My question is, anyone out there in forum land see this kind of issue before? Is this the kind of thing I should just live with or has someone found a root cause for this issue. Maybe something like device driver or software on the switch.
The switch is a 4006-2 running Software, Version NmpSW: 7.1(1) and System Bootstrap Version: 5.4(1).
The device hanging off the port was a IBM thinkpad a30.
Any help would be Appreciated
Thanks in advance.
Ted

 

[ecafracs]

auto negotiation is not recommended in a switched environment. Most of the time, the process will fail. It is better to set the port to full duplex on both ports so the devices will have a common config. In your case ,that's the same thing. By forcing the port to 100 Mbps Full, you disabled the auto-negotiation process and forced your devies to communicate using the same duplex operation.

 

[tschafer]

I think you got things turned around here a bit. I only had a problem when the switch is set to 100/full. Setting the port to auto/auto gave us error free operation. I've tried this a second time on my IBM T23 Thinkpad and another port. I also got FCS errors and RCV errors and runts with my port set to 100/full. The funny think is that with the port set to auto/auto the port neonates to 100/full anyway. I know this isn't what the books tell us, what I'm looking for is someone else that's seen this same scenario.
Thanks,

Ted

 

[bobchan]

Hi all,

That's true, auto negotiation cause a lot of error. Even in Cisco-to-Cisco (switch or router)case, auto never work good in my company network.

Most of the time, auto neg. give out CRC also.

 

[rborel]

I have seen this problem before. I think it had something to do with the NIC in the device that we were connecting, not really on the Cisco side (also a 4xxx). Once we upgraded the NIC drivers the issue was over. You may wish to try that.

I agree with the other two posts. Usually (especially with Sun equipment) having the Cisco in auto/auto does not work.


Good luck Ted,

Reese

 

[patrckb]

We've had major religious wars at our office over this Auto-negoiate vrs. set speed/duplex issue.

Cisco's official line says "Both sides of a link should have auto-negotiation on, or both sides should have it off. Our current recommendation is to leave auto-negotiation on for those devices compliant with 802.3u. (Re:

http://www.cisco.com/warp/public/473/3.html).

The big cavate here is does the other side's NIC fully comply with 802.3u? Cat 5 and 10/100 cards were out long before the auto negoiate standard was finalized.

Another big factor that gets ignored a lot is the cabling infrastructure. Just because Cat 5 wire was pulled doesn't necessarily mean that it will easily pass 100Mbps. Did they use Cat 5 punchdown techniques? Did they use Cat 5 connectors? Did they maintain the minimum turn radius? Did they maintain the twists to within 3/8" of the punchdown? I have actually seen a kink in a patch cable prevent a workstation from running 100Mbps. If the wiring isn't clean, you can get a lot of errors.

People forget that 100Mbps running with errors is significantly slower than 10Mbps running clean.

My experience has been that autonegoiate works about 90% of the time. That means that you have to go back and manually set the other 10% of the workstations.

So, bottom line, choose weather you will set the speed and duplex on BOTH sides or make BOTH sides autonegoiate. Choose one or the other.

Also, invest in a good line meter. Layer 2 problems NEVER look like a layer 2 problem, they masquarade themselves as all kinds of other problems.

Patrick, CCNP, CNX, SCM