-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Joshua Baker-LePain Sent: Monday, April 25, 2005 7:59 AM To: CentOS mailing list Subject: RE: [CentOS] losing NFS connection
On Sun, 24 Apr 2005 at 2:53pm, Marc Powell wrote
Anyone any idea what is wrong here?
Just a thought but have you hard-coded speed and duplex all the way through? Don't trust auto-negotiation.
Just a dissenting opinion here on that last bit. No less a source
than
Donald Becker often advises *strongly* against disabling
auto-negotiation.
Yes, some switches *cough*Cisco*cough* historically did it very badly. But that was then, not now. And, AIUI, it's actually part of the gbe standard.
Sure, let me rephrase my original wording -- "I don't trust auto-negitiation." =) I say that for two reasons --
I work with a very large network consisting of tens of thousands of machines connecting to a hodge-podge of switches and routers from many different vendors. It is my personal experience that auto-negotiation does not result in optimum or even compatible speed/duplex settings often enough to be trustworthy. I've experienced this as recently as last week with brand new Cisco equipment and Dell computers running CentOS 3.4 (100/Full on one end, 100/Half on the other). I've seen the problem with Alteon and Foundry equipment recently as well. It may be part of the standard but as anyone who's been around a while knows, each vendor's interpretation of a standard can vary enough to be problematic.
Second, as an administrator I want to do everything in my power to make sure the devices I manage are going to run smoothly. Why leave something as simple but as problematic as speed/duplex settings to chance or trust when it is a simple task to force it to be that which works best in the networking environment that the device lives in? For example, if auto-negotiation comes up with 100/half, 10/full or 10/half and every other local device is 100/full or vice-versa, the network is operating at less than peak efficiency and that can also result in odd problems.
-- Marc