I'm with Michael that it points to network, but if everything matches up for speed and duplex (I simply force everything to 100/Full, unless it's GigE), you're not out of options. NetApps are well optimized for local networks, but WANs are a different story. Have a look at the follow page, which discusses things like correct TCP window sizes and things like that:
http://www.internet2.edu/~shalunov/writing/tcp-perf.html
It's got a lot of good information on optimizing TCP for WANs, relative to bandwidth and RTT. I don't know if NetApp supports window sizes greater than 64K (never needed it personally.)
Jason
On Aug 4, 2004, at 5:03 PM, Michael Schipp wrote:
Hi Geoff, The following KB article tells you what can cause this error. (it also tells you how to disable the redirector - do not do this).
Microsoft Knowledge Base Article - 163401 - http://support.microsoft.com/default.aspx?scid=kb;EN-US;q163401
Anyway this points it to a networking issue.
Some things to check: 1 Network card Auto/full/half 2 Switch/hub (I hope they do not have a hub :)) set to auto/full/half
You should also run a netdaig from the filer as this may tell where the misconfigured network device may be.
Thank you,
Michael A Schipp M.I.S Network Administrator ASI SOLUTIONS 8 Lord Street Botany NSW 2019 Phone: 02 9384 8000 Direct: 02 9384 8095 Email: mschipp@asi.com.au Web: http://www.asi.com.au
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Geoff Hardin Sent: Thursday, 5 August 2004 6:24 AM To: toasters Subject: CIFS problems
I have two filers in a remote office (the Philippines, while we are located in Dallas). One of these filers, FILER1, authenticates to the local domain, let's call it LOCAL, and the other, FILER2, authenticates back to our domain, let's call it CENTRAL. There is a trust between the
LOCAL and the CENTRAL domains so users from either domain can log in and
authenticate to their domain. (I'm not an NT admin, so I don't know how
this works; this is just my simple understanding). Both filers are running the same (very old I know) version of ONTAP: NetApp Release 6.1.1R2P1D12. Of course, these are also very old filers, too: F720s with about 70 GB useable.
Now, the plan was to move both filers to the LOCAL domain, so that CIFS users would not need to authenticate against a domain controller on the other side of the planet. The problem is, the filer in the LOCAL domain
keeps running into problems with users from both locations having trouble accessing the filer via CIFS. The filer reports "FILER1 unreachable. An unexpected network error occurred." Today I had the NT
admins check, and they found errors in the log files on the LOCAL PDC.
8/4/04 11:45:39 Event ID: 3013 Description: The redirector has timed out to FILER1 8/4/04 11:31:29 Event ID: 3013 Description: The redirector has timed out to FILER1 8/4/04 11:17:09 Event ID: 3013 Description: The redirector has timed out to FILER1 8/4/04 11:10:04 Event ID: 3013 Description: The redirector has timed out to FILER1
I would have thought that if there were going to be problems, it would have been with the filer that is authenticating back to our CENTRAL domain controllers, but it has yet to have this problem.
As I stated at the top, I am not an NT admin. The NT admins here do not
know anything about filers and insist that the problem lies there. My experience tells me differently; the filers are very simple appliances that just plain work. I checked the configuration options between the two filers and only found one option that was set differently; cifs.oplocks.enable was disabled on FILER1. I enabled that option but I
have still run into the problem.
Can someone point me in the right direction of where to look? I have tried looking at the output from the `cifs stat` command, but I do not know what to look for. Has anyone else run into this problem? What solutions are available? We are considering upgrading these in the near
future, but our customers are (rightly) concerned that throwing money at
this problem will not solve it. Is this simply a case of old hardware being overwhelmed?
Thanks in advance for any help and ideas,
Geoff Hardin UNIX System Administrator Dallas Semiconductor / Maxim Integrated Products geoff.hardin@dalsemi.com Nothing is foolproof because fools are so ingenious.