Sounds like it is possibly different, but in the end once I knew what to
look for, we could test for it quite easily:
# nmap -p 512-1023 172.20.12.5
623/tcp filtered unknown
664/tcp filtered unknown
(The IP in this case in NFS client, but I ran nmap against both to look
for other stolen ports)
Ok. I got a matching snoop (from the server) and tcpdump (from the linux
client) and the replies seen leaving the server are definitely not seen
by the client:
From the server:
releng1.RelEng.Egenera.COM -> Galileo.RelEng.Egenera.COM NFS C ACCESS3
FH=6C39 (read,lookup,modify,extend,delete)
Ga
I'm having a similiar problem from a linux client to a sNV_b103 server.
For me though the mount works fine, it's the NFS accesses that hang.
Here's a snoop that shows what the server is seeing:
releng1.RelEng.Egenera.COM -> Galileo.RelEng.Egenera.COM NFS C GETATTR3
FH=6C39
Galileo.RelEng.Egener
I stumbled across this entry:
http://blogs.sun.com/shepler/entry/port_623_or_the_mount
and even though we do not see this issue with port 623, but rather 664.
But sure enough, it was sending SYN/ACK, then timeout until RST.
I waited for the port to the released, told inetd to listen on port 66
ely? There
> are no v4 clients in your env? If the clients are exclusively ro, have you
> tried mointing with ro flag?
>
> -rob
>
>
> -Original Message-
> From: Jorgen Lundman [mailto:lundman at gmo.jp]
> Sent: Monday, February 16, 2009 12:11 AM Eas
You make it sounds like it might still hang, even using the real IP. ;)
The www, ssl, cgi and navi clusters experience the NFS problem the most,
about 2-3 times a day, so I have remounted those servers to use the real
IP. This should tell if it makes any difference to not use the alias.
If any
Ok, a server was already hung when I got to work today.
**
x4500-04: NFS Server, Sol 10 5/08
Server IP (real) 172.20.12.226 netmask ff00
NFS IP (alias) 172.20.12.227 netmask ff00
x4500-04:~# netstat -in ; netstat -rn
Name Mtu Net/Dest Addr
It's good that you now have a work-around without rebooting the client
or server.
IP alias might, or might not, be a problem. However the real problem is
why the
hang occurs after it has been working for awhile with the server
configured with
IP alias.
I think the mount with the real IP worked
Jorgen Lundman wrote:
>
>
> Which works without issue. So it is not an NFS problem, it seems to be
> related to alias IPs.
>
> Do you know a way around this? Or perhaps you can suggest a place
> where I can go to ask. As a quick solution we will just forgo the
> Alias IP and mount directly on th
Thank you for your reply,
The x4500s uses a real IP, and an IP alias. The NFS mounts are connected
to the alias, so it would be "easier" to fail-over to a different x4500
should there be a need. We have not yet got that far as we are exploring
ways to replicate the data from the active x4500 t
The problem seems to be on the TCP connection between the client and the
nfsd on
the server. The portmap and mount requests used UDP and they went OK.
There are a number TCP RST packets sent from both the client and server,
this indicated
there might be problem with packets lost causing both sid
(Resent due to wrong sender, sorry)
Hello list!
*** NFS Servers:
x4500-01 to x4500-05
: Solaris 10 5/08, ZFS and "UFS on ZVOL" exported.
: NFSD_SERVER=1024, LOCKD_SERVER=128 average use about 900 / 20 threads.
: "bufhwm_pct,maxusers,ndquot,ncsize,ufs_ninode,clnt_max_conns,
: rpcmod:cotsmaxdupre
12 matches
Mail list logo
