-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Angelo Machils Sent: Sunday, April 24, 2005 1:28 PM To: centos@centos.org Subject: [CentOS] losing NFS connection
Hello there!
Perhaps this is a little off-topic, but I notice this only on the
Centos
box. I'm running Centos 4 on an AMD64 which has the following entries in
the
fstab to connect to NFS shares on a Fedora3 box: 192.168.1.12:/home/angelo/ /home/angelo/NFS_share1 nfs rw,addr=192.168.1.12 0 0 192.168.1.12:/home/angelo/data /home/angelo/NFS_share2 nfs rw,addr=192.168.1.12 0 0 192.168.1.12:/home/angelo/data2 /home/angelo/NFS_share3 nfs rw,addr=192.168.1.12 0 0 I have opened ports 111 (TCP), 648 (TCP), 651 (TCP) and 2049 (TCP and UDP) in iptables on the FC3 box and I can connect to them, but after a while I seem to loose the connection to the shares.
[snip]
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.
-- Marc
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.
Joshua Baker-LePain wrote:
Yes, some switches *cough*Cisco*cough* historically did it very badly.
And some ethernet cards *cough*Sun hme*cough*, but that was fixed long time ago in device drivers (circa Solaris 2.5 or 2.5.1?). But all that was when FastEthernet was relatively new stuff. All those problems are more or less history nowdays.
Just a thought but have you hard-coded speed and duplex all the way through? Don't trust auto-negotiation.
Sorry for the slow post -- trying to get caught up on my list reading after a hectic week. :-)
My understanding from the IEEE 802.3u specs is that the key to the "hard code vs auto-negotiate" debate boils down to: with the auto setting of switch & NIC ports, SPEED can be DETECTED (based on the speed of link pulses), DUPLEX must be actively NEGOTIATED. IOW, if one end has duplex hard coded, then the other end has nothing to negotiate with and must DEFAULT TO HALF DUPLEX.
This results in 3 compatible combinations:
1) Leave both ends at auto.
2) If you are in a shop that is very meticulous about duplex settings on both switches AND servers (hard to do in most large organizations because different groups usually manage servers and switches), then you can hard both ends to full duplex.
3) If you are in a shop where duplex misconfigurations are are common (or left at the default) and going auto/auto everywhere is not desirable, its best to hard-code to HALF duplex -- that way if the other end is left at auto things still work.
So, while hard coding both ends to 100/Full provides maximum throughput, forgetting to hard code one of the two ends will always result in a duplex mismatch (and EXTREMELY low throughput).
HTH, Kennedy
On Sat, 2005-04-30 at 14:11, Kennedy Clark wrote:
- If you are in a shop where duplex misconfigurations are are common
(or left at the default) and going auto/auto everywhere is not desirable, its best to hard-code to HALF duplex -- that way if the other end is left at auto things still work.
Most desirable: leave everything at auto and replace any equipment that can't be made to negotiate correctly with software or flash updates. Otherwise you are hurting performance or setting up a situation where the next port/equipment swap is likely to have a mismatch. Or you need a degree of management that is probably more expensive than equipment that works properly.
-
Aleksandar Milivojevic -
Joshua Baker-LePain -
Kennedy Clark -
Les Mikesell -
Marc Powell