Re: NFS inconsistent behaviour

On Wed, Oct 18, 2006 at 01:57:09PM -0400, Trond Myklebust wrote:
On Wed, 2006-10-18 at 08:39 +0200, Frank van Maarseveen wrote:
On Wed, Oct 18, 2006 at 10:22:44AM +0900, Mohit Katiyar wrote:
I checked it today and when i issued the netstat -t ,I could see a lot
of tcp connections in TIME_WAIT state.
Is this a normal behaviour?

yes... but see below

So we cannot mount and umount infinitely
with tcp option? Why there are so many connections in waiting state?

I think it's called the 2MSL wait: there may be TCP segments on the
wire which (in theory) could disrupt new connections which reuse local
and remote port so the ports stay in use for a few minutes. This is
standard TCP behavior but only occurs when connections are improperly
shutdown. Apparently this happens when umounting a tcp NFS mount but
also for a lot of other tcp based RPC (showmount, rpcinfo). I'm not
sure who's to blame but it might be the rpc functions inside glibc.

I'd switch to NFS over udp if this is problem.

Just out of interest. Why does anyone actually _want_ to keep
mount/umounting to the point where they run out of ports? That is going
to kill performance in all sorts of unhealthy ways, not least by
completely screwing over any caching.

I ran out of privileged ports due to treemounting on /net from about 50
servers. The autofs program map for this uses the "showmount" command and
that one apparently uses privileged ports too (buried inside RPC client
libs part of glibc IIRC). The combination broke autofs and a number of
other services because there were no privileged ports left anymore.

So it can happen in practice.

Note also that you _can_ change the range of ports used by the NFS
client itself at least. Just edit /proc/sys/sunrpc/{min,max}_resvport.
On the server side, you can use the 'insecure' option in order to allow
mounts that originate from non-privileged ports (i.e. port > 1024).

Increasing the privileged port range in the kernel might be doable in
some cases. It might be useful to extend it to include port 2049 too.

--
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: NFS inconsistent behaviour
    ... of tcp connections in TIME_WAIT state. ... Why there are so many connections in waiting state? ... and remote port so the ports stay in use for a few minutes. ... I'd switch to NFS over udp if this is problem. ...
    (Linux-Kernel)
  • Re: can I use keep-state for icmp rules?
    ... if you're like me and allow incoming established connections to any port, ... unless he connects withough sending a "connect" packet first - ie ... >> the impression that ipfwactually tracks the state of TCP ... > internal tcp ports that might not normally have external access available? ...
    (FreeBSD-Security)
  • Re: Confused newbie
    ... TCP 192.168.1.3:1045 64.12.25.84:5190 ESTABLISHED ... and configuring zone alarm to make sure my home network is secure. ... > are protected and my ports dont exist and are in stealth mode. ... > listening and some have established connections to ip's/ports. ...
    (alt.computer.security)
  • Re: R2 in-place upgrade bug ? ..HELP
    ... Application protocol Protocol Ports ... Global Catalog Server TCP 3269 ... The upgraded R2 DC does not accept incoming connections, ...
    (microsoft.public.windows.server.active_directory)
  • RE: IM Programs
    ... want to block these ports. ... you don't need an explicit deny for the other ports. ... Access-list 101 deny any tcp any any eq 5000 ... >Now, when applying these to your firewall, make sure the number ...
    (Security-Basics)