Jeffrey Hartwigsen wrote: > After resetting the UDP timeouts on both of our NAT boxes to 11 minutes, > things are much improved. We are still experiencing some problems with > timeouts though. (Windows claims "The network path cannot be found" when > trying to access filespace)
And what about when trying to reach \\afs\all\ ? If you get the same error, then this with the Windows CIFS client deciding that the "AFS" SMB server is unreachable. The Windows CIFS client gets very confused when the AFS SMB server is unable to send responses promptly. The CIFS client keeps track of the average response time and when the response must wait for the AFS file server, then the CIFS client begins to time out and break the connection to the AFS SMB server. It then begins a series of retries to read the same data. > What does this line in the Filelog mean? > > Wed Apr 26 16:12:12 2006 SAFS_FetchStatus, Fid = 536870918.10604.5870, > Host 192.188.163.112:12096, Id 6 > Wed Apr 26 16:12:12 2006 SAFS_FetchStatus, Fid = 536870918.10602.5869, > Host 192.188.163.112:12096, Id 6 > Wed Apr 26 16:12:12 2006 SAFS_FetchStatus, Fid = 536870918.10600.5868, > Host 192.188.163.112:12096, Id 6 > > I had 939 entries like this seemingly from the same client (port number) > within 2 seconds. I'm also still getting some ProbeUuid failures. I can > send the context of those along to if it would be helpful. It means that the file server has received a Fetch Status call from the client at 192.188.163.112:12096 Now the question is whether or not on the file server you can rxdebug 192.188.163.112 12096 -ver and get a response. If not, then the NAT is blocking the file server from sending to the client. 939 requests in two seconds is very high. I would need to see what else is going on at the same time. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
